Andrew Knutsen (firstname.lastname@example.org)
1 Oct 87 03:53:15 GMT
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...
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
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....
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:34 GMT