Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!sri-unix!ctnews!mitisft!andrew
From: andrew@mitisft.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: closing half-open connections
Message-ID: <247@mitisft.Convergent.COM>
Date: Wed, 30-Sep-87 23:53:15 EDT
Article-I.D.: mitisft.247
Posted: Wed Sep 30 23:53:15 1987
Date-Received: Sat, 3-Oct-87 12:03:27 EDT
References: <8709291530.AA13517@aplpy.ARPA>
Distribution: world
Organization: Convergent Technologies, San Jose, CA
Lines: 33


	While I dont have any suggestions for closing existing half-open
connections (although I think someone posted something awhile back), I
do have a scenario which I have seen cause this, which can be traced to
an ambiguity in the RFC...

	Scenario:

1) Server sends FIN, gets ACK, enters FIN_WAIT_2.

2) Client sends a bunch of data.

3) Server's window size goes to zero due to normal flow control.

4) Client closes connection.
	At this point, client has data buffered, and needs a window update.
	FIN hasnt been sent since data is pending.

5) Client is now in LAST_ACK.  However, he ignores window updates, looking
	only for ACK of FIN he hasnt sent! The connection is effectively
	idle.

	Now, the RFC says all data should be sent after a close (pgs 49 & 61),
and that when a segment arrives in LAST_ACK state only the ACK of FIN should
be checked for (pg 73).

	4.3 seems to have "fixed" this problem by both flushing data on a close
and putting a timer on FIN_WAIT_2, along with having just about everybody
use "linger mode" where the close delays till the data drains (not the default).
I fixed it by looking at window updates during LAST_ACK; not exactly spec,
but harmless (apparently) in the normal cases....

Andrew