Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!uthub!thomson
From: thomson@uthub.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: closing half-open connections
Message-ID: <609@uthub.toronto.edu>
Date: Mon, 5-Oct-87 14:25:53 EDT
Article-I.D.: uthub.609
Posted: Mon Oct  5 14:25:53 1987
Date-Received: Thu, 8-Oct-87 00:35:31 EDT
References: <8709291530.AA13517@aplpy.ARPA> <247@mitisft.Convergent.COM>
Reply-To: thomson@uthub.UUCP (Brian Thomson)
Distribution: world
Organization: CSRI, University of Toronto
Lines: 31

In article <247@mitisft.Convergent.COM> andrew@mitisft.Convergent.COM (Andrew Knutsen) writes:

 >	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...

...
 >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).

The problem is really with the implementation, not the RFC.
A TCP is not supposed to enter LAST_ACK until it has sent the FIN.
From pg. 61, it should remain in CLOSE_WAIT state "... until all preceding SENDs
have been segmentized; then send a FIN segment, enter [ LAST_ACK ] state".
The actual document said "enter CLOSING state", obviously a typo.

Having said all that, it may well be that the easiest way to handle this
is to accept window updates while in LAST_ACK.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu