From: gah@ugcs.caltech.edu   
      
   Rick Jones wrote:   
      
   > Glen Herrmannsfeldt  wrote:   
      
   >>With TCP, if one packet is lost you won't get any data sent after   
   >>that until it is retransmitted after the sender receives the NAK.   
      
   > Don't you mean "no data past that which is lost will be _delivered_ to   
   > the receiving application until after the lost data is retransmitted?"   
      
   Yes.  The "you" was the person on the receiving end.  It won't get   
   to the person until it gets to the receiving application.   
      
   > Depending on the congestion control algorithm and its behaviour, the   
   > sending TCP may still _send_ some data after a presumed lost TCP   
   > segment, but the receiving TCP will always deliver data in order to   
   > the application.   
      
   > When did TCP get NAKs?-)   
      
   Oops, yes.  Well, it the receiver misses a packet and requests   
   the retransmission of a previous one, then the effect is NAK,   
   but yes that isn't the TCP name for it.   
      
   >>With UDP, you still get later data, and your program must request   
   >>the retransmission.   
      
   > And must deal with the possibility the datagram was merely delayed by   
   > a routing change, or even duplicated somewhere in the cloud.   
      
   That could happen.  It seems that the OP has market data, such   
   as the price of stocks.  The data in each packet is likely   
   independent (prices of different stocks, or at a later time).   
      
   I would expect packets to have a time in them, such that   
   the receiver could protect against severe delays.   
   If one is delayed, the receiver (person) would still like to   
   know what is happening to other stocks in the mean time.   
   Sufficiently late, it might as well not be sent at all,   
   but an updated price for the stock might be sent instead.   
      
   > Other questions from the OP ask if one can compress TCP headers - just   
   > how small a chunk of data are you sending at one time?!?  IIRC the   
   > only thing that could compress TCP headers was the old CSLIP stuff for   
   > running over dial-up lines.  Broadly speaking you should give   
   > everything you have at the moment to TCP.   
      
   > Some old boilerplate on Nagle and TCP_NODELAY:   
      
   Or UDP.  A series of stock prices is really sets of independent   
   data, not a data stream TCP style.   
      
   >>I'm not familiar with this issue, and I'm mostly ignorant about what   
   >>tcp does below the sockets interface. Can anybody briefly explain what   
   >>"nagle" is, and how and when to turn it off? Or point me to the   
   >>appropriate manual.   
      
   (snip of nagle)   
      
   Thinking about independent data packets, it would seem that   
   UDP should be best for NFS, yet later versions have converted   
   to TCP.   Assuming an NFS client with multiple users all making   
   requests of the same server, it would seem that the serialization   
   required by TCP would not be appropriate.   
      
   -- glen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)