45f070b0   
   From: vjs@calcite.rhyolite.com   
      
   In article <0f1ffd10-a215-4a7b-82b9-f83d55e666a7@x38g2000yqj.googlegroups.com>,   
   Jorge   wrote:   
      
   >To clarify, the chunks are small so that the recipient can receive   
   >them in "real time".   
   > I am streaming financial market data. The recipient must receive the   
   >data in a timely fashion.   
   >   
   >Is there a better protocol than TCP for this type of application?   
      
   TCP is the best choice if you need a reliable connection and do not   
   know enough about network protocols to design your own reliable   
   protocol on top of UDP.  A reliable connection involves timers and   
   other mechanisms to retransmit data that gets lost without retransmit   
   too quickly or too often.   
      
   If the chunks of data are smaller than about 1400 bytes, and   
   especially if they are smaller than about 500 bytes,   
   and unless your customers are using very low bandwidth devices   
   such as cell phones or personal data assistants (PDAs),   
   you should probably not compress the chunks.   
      
   In general it costs about the same to send one tiny packet as one   
   larger packet.   
      
   Compression works better with more data, and always needs CPU cycles.   
   Compression can significantly increase latency.  Depending on how you   
   compress the chunks and the compression algorithm, a receiving system   
   might stall after receiving one chunk waiting for the decompression   
   mechanism to get more data and finally emit the decompressed chunks.   
      
      
   Vernon Schryver    vjs@rhyolite.com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)