Re: closing half-open connections


Brian Thomson (clyde!watmath!utgpu!utcsri!uthub!thomson@rutgers.edu)
5 Oct 87 18:25:53 GMT


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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:34 GMT