5d6a5b88   
   XPost: comp.arch.embedded, sci.electronics.design   
   From: nobody@nowhere.com   
      
   On Fri, 11 Sep 2009 06:42:49 -0700, Dimiter Popoff wrote:   
      
   >> Let me guess -- you kept sending it the same data it had already ACKed   
   >> and it kept telling you it had already ACKed it.   
   >   
   > It is not telling it has acked it. It is telling it has a window size   
   > of 0 for half a minute.   
   >   
   >> See the problem? You   
   >> are refusing to honor the peer's ACK until it ACKs more data. The peer   
   >> is refusing to ACK more data until you accept what it has already   
   >> ACKed. You are in the wrong.   
   >   
   > So who (except you) says that. If the peer reports a window size of 0   
   > forever it is just dead, period.   
      
   There's a big difference between "half a minute" and "forever".   
      
   If the receiving client application doesn't consume received data (e.g.   
   because it is suspended, or in a blocking wait on user input), the receive   
   buffer will fill up, resulting in the kernel's TCP implementation   
   reporting a window size of zero. It will continue to report a window size   
   of zero so long as the receive buffer is full (i.e. until the application   
   eventually retrieves data from the buffer).   
      
   Unless the sending application implements its own timeout, the sender will   
   continue to probe the receive window indefinitely. The kernel won't time   
   out the connection so long as the receiver continues to send ACKs, even if   
   the ACKs report a zero window size.   
      
   >> Why do you keep refusing to accept the peer's ACK? Why do you keep   
   >> retransmitting data it has already ACKed, forcing it to ACK it again?   
   >   
   > Again, it has not acked that data. Only part of them.   
   > Retransmission is an integral part of tcp and the receiver *must*   
   > be ready to rewind back and accept retransmitted data it has   
   > already acked, at any offset.  Further, the latest data it has   
   > received   
   > has precedence over older data at that offset. But all that   
   > has been standardised  since decades, consult rfc793 for the details.   
      
   The RFCs say nothing about the case where you get two conflicting versions   
   of a particular byte.   
      
   In many cases, the behaviour which you suggest (allow the newer version to   
   override the older version) is impossible, as the older version will   
   already have been passed up to the application.   
      
   In order for that behaviour to even be possible, the older data must still   
   exist in the kernel's receive window, either because the application   
   simply hasn't retrieved it, or because preceding data is missing.   
      
   > Anyway, let me see what you think the transmitter must do in   
   > that situation: it sends a 1460 bytes segment, receives an ack   
   > for 1200 of them with a window size of 0 (repeat that   
   > forever).   
      
   If the sender reports with a window size of zero, the receiver should   
   continue to send window probes containing a single byte of data. Such   
   probes should have an exponential back-off capped at 60 seconds, and   
   should be sent until the socket is closed, either by the application or by   
   the protocol (i.e. either a RST or if the sender stops ACKing the probes   
   for an extended period; 9 minutes is typical).   
      
   > The obvious meaning is "I am done with that file, cannot   
   > take any more but the last 1200 bytes you sent me, please   
   > go away".   
      
   The correct meaning is "I'm busy, and cannot consume the data right now;   
   please hold".   
      
   There are any number of reasons why reception may be suspended   
   temporarily, e.g. the user suspended the application, or the application   
   is blocked waiting for a new tape to be inserted, etc. Note: "temporarily"   
   could easily mean "until Monday morning".   
      
   An application doesn't have to do anything special to wait indefinitely   
   for its data to be consumed; rather, it has to explicitly set a time-out   
   if it doesn't want to wait forever.   
      
   > Which I do, after a 30 seconds timeout.   
      
   That may be reasonable (if somewhat aggressive) behaviour for an   
   application, but the TCP stack shouldn't time-out the connection so long   
   as the window probes continue to be ACKed.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)