Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP flow control query
Message-ID: <9105151637.AA11054@ftp.com>
Date: 15 May 91 16:37:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 23


       ....  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 ....
    
    The ACK from the stalling [client] host is in response to the zero-window
    probe sent by the pausing [server] host....

If in fact the single byte of data is garbage, then the sequence number MUST
be SND.UNA - 1, and the segment is a "keepalive".  A real zero-window-probe
is sent with SND.UNA (not SND.NXT, or you may wedge if someone shrinks the
window on you) as the sequence number and a real data byte.
    
    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.

This is true, but it doesn't excuse you from implementing zero-window-probe
logic.  The single ACK might get lost in transit, and if this happens, the
TCP connection necessarily stays stalled until the sender probes.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901