Hi Ulf,
just to be clear:
The sender is allowed to send 1 byte more than the rwnd allows.
This is used for zero window probing.
The receiver has a rwnd which he uses to accept data or not.
But he is free to advertise less, for example for SWS avoidance.
This is what you experience: the receiver advertises 0, but the
'real' window is not zero. So he accepts the data and ACKs it.
When the 'real' window is also zero, the might not accepts the
data.
A TCP receiver is free to accept data, even if he advertised 0.
(This is different for an SCTP receiver: It has to drop the data
when received with a_rwnd == 0).
Best regards
Michael
On Feb 20, 2007, at 8:52 PM, Ulf Lamping wrote:
ronnie sahlberg wrote:
So if the window is still zero, the ACK will indicate this by NOT
advancing to cover the new byte.
If the window is no longer zero, the receiver can handle the byte and
the ACK will be advanced to cover the new byte.
First of all, thanks a lot for the detailed response - it helped me
a lot!
Interestingly, the effect I saw is that the window size is zero before
and after the probe byte, although the receiver actually ACK'ed the
"probe byte".
When I understand this correct, this is because of the silly window
avoidance algorithm.
As the Window size is not already at a size "notable" (I saw notes
about
some 1/4th of buffer size or at least the size of a single packet to
indicate a window size above zero),
the window size != 0 is *not* reported from the receiver to the
sender -
it's still too small to be noted but *not* zero in effect.
So the probe byte is transferred in effect and ACK'ed, but the window
size still remains zero!
I'm not sure if this implementation is "TCP correct", but the RFC just
seems to be fine with this.
BTW, I'm talking about two Interniche embedded TCP/IP stack
implementations talking to each other (just for the record).
I will fix the WIKI when i get to a more modern computer than my home
one. Konqueror 3.0 does not like wiki things :-(
I've fixed it with the knowledge I have now, please correct me if I'm
wrong ;-)
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
