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@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
