From: gah@ugcs.caltech.edu   
      
   Vernon Schryver wrote:   
   (snip)   
      
   > 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.   
      
   I don't disagree.  Though since network bandwidth has a cost,   
   it might be more economical to pay someone to do it right,   
   even if that is over UDP.   
      
   > 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.   
      
   Well, it seems that the OP is multicasting.  In that case, the   
   compression only needs to be done once before sending to   
   multiple receivers.  The receivers might well be cell phones   
   or PDAs (almost the same by now), though each one will have   
   a relatively slow data stream.   
      
   > In general it costs about the same to send one tiny   
   > packet as one larger packet.   
      
   True for ethernet, maybe not for some slower links.   
      
   > 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.   
      
   Yes, so in that case each chunk should be separately compressed.   
      
   -- glen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)