Brian Thomson (firstname.lastname@example.org)
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
> 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, email@example.com
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:34 GMT