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
