Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!crackers!solensky From: solensky@animal.clearpoint.com (Frank T. Solensky) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP flow control query Message-ID: Date: 13 May 91 13:59:35 GMT References: <4238@zaphod.UUCP> Sender: news@crackers.clearpoint.com Distribution: na Organization: Clearpoint Research Corp. Lines: 26 In-reply-to: derrick@zaphod.UUCP's message of 10 May 91 20:22:11 GMT In article <4238@zaphod.UUCP> derrick@zaphod.UUCP (Derrick Nagy) writes: ... The problems seem to lie at the TCP level when the receiving end advertises a zero window. It does not appear to turn flow control on again on its own initiative. The pausing host will send a datagram with one byte of garbage data as a probe after a few seconds, to which the receiving end responds with an ACK with the current window size (usually wide open). The stalling host only sends ACKs, and the receiving end never responds to them. Questions: are the ACKs from the stalling host probes? Are they valid probes? The ACK from the stalling [client] host is in response to the zero-window probe sent by the pausing [server] host. The ACK in the packet isn't as important as the window size that the packet contains -- this is what allows the pausing host to resume sending data. What criteria should the receiving end use to advertise when its window opens? When the stalling host's receive window changes from zero to non-zero, it should be sending out an ACK at that time, rather than waiting for the zero-window probe from the pausing host. -- -- Frank Solensky / Clearpoint Research Corp. Red Sox magic number: 132