8ff66346   
   XPost: comp.arch.embedded, sci.electronics.design   
   From: nobody@nowhere.com   
      
   On Sun, 13 Sep 2009 03:40:32 -0700, Dimiter Popoff wrote:   
      
   >> > ....  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.   
   >   
   > Page 69 of rfc793 says something about that.   
      
   I presume that you are referring to:   
      
   	If a segment's contents straddle the boundary between old and new, only   
   	the new parts should be processed.   
      
   Which implies that the old version should take precedence, regardless of   
   whether it has been passed up to the application.   
      
   Although it shouldn't make any difference (the sender shouldn't be sending   
   conflicting data for a given range of sequence numbers), this has been   
   suggested as a possible attack vector, to "smuggle" malicious data past   
   a security scanner built into a router.   
      
   >> > 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.   
   >> ....   
   >   
   > I know, and I know where that comes from.   
   > The clear error of the tcp implementation at the windows' size is   
   > the fact that it chooses to take part of a segment; the sending side   
   > (mine) sees too late that the tcp window is too small and sends   
   > a segment which the receiver cannot accept (no matter how low my   
   > system latencies are, at 12-13 uS/segment this can still happen).   
   > Instead of discarding the segment, the receiver acks *part* of it;   
   > this is illegal (rfc793, page 69: "If the RCV.WND is zero, no segments   
   > will be acceptable, but special allowance should be made to accept   
   > valid ACKs, URGs and RSTs". The table at that page is also quite   
   > explicit about that).   
      
   Note that it's talking about the receive window within the receiver's TCP   
   stack, not the last advertised window. It's possible that the window has   
   just opened but this fact hasn't yet been announced. If the receiver   
   responds to a probe with a zero window size, then ACKs some data from the   
   next packet, it isn't necessarily violating the rules.   
      
   >> > 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".   
   >   
   > The 0 window does mean that indeed, the 1200 ack is nonsense; and I   
   > agree that 30 seconds timeout may be somewhat aggressive but at 100 MbpS   
   > it seems an eternity (or is it an ethernity :-) . It is my tcp sending   
   > action which times out, but the application can set if there is one   
   > and how long it must be on a per connection basis, in this case   
   > it is 30 seconds (I believe this was the default setting, also   
   > settable).   
      
   That's an API issue. The BSD sockets API offers the SO_SNDTIMEO socket   
   option (for all socket families). This specifies how long a send/write/etc   
   call can block for; if the timeout is exceeded, the call will return a   
   short count (or -1 with errno set to EAGAIN), but the socket remains   
   valid for futher operations (i.e. it doesn't terminate the connection).   
      
   One thing I'm not entirely clear on is whether the result reflects:   
      
   1. the data actually acknowledged by the receiver,   
   2. the data actually sent (and scheduled for retransmission until   
   acknowledgement), or   
   3. the amount of data copied into the kernel's transmit buffer.   
      
   I assume that it would be either 2 or 3; data sent but not acknowledged   
   may have already been received and passed up to the application, so it   
   cannot be "rescinded". If it's 2, the kernel can just discard any data   
   which hasn't been sent yet.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)