Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!cbosgd!ucbvax!usc-isid.arpa!MILLS From: MILLS@USC-ISID.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Re: Zero window probes Message-ID: <8511111739.AA07725@ucbvax.berkeley.edu> Date: Mon, 11-Nov-85 12:27:36 EST Article-I.D.: ucbvax.8511111739.AA07725 Posted: Mon Nov 11 12:27:36 1985 Date-Received: Tue, 12-Nov-85 04:36:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@ucbvax.berkeley.edu In response to the message sent Fri, 8 Nov 85 15:57 EST from Mills@CISL-SERVICE-MULTICS.ARPA John, See MIL-STD-1778 for another view of the TCP spec, although officially this and RFC-793 define the same protocol. Speaking pragmatically, the TOPS-20 TCP abandons the connection if the window soes not open in five minutes. The Fuzzball TCP does the same. You have a similar problem when you send a FIN, which is ACKed, and the other end never sends a FIN. If data are queued beyond the right window edge, the user timeout will catch it. If not, the zero-window probe could continue indefinately, at least until either new data appears or the connection is closed. This means, of course that the use would have to proved exactly enough data to fill the window and then never provide any more. Dave (no relation) -------