Date: Sat, 23 May 1998 13:48:21 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) To: Terry Lambert <tlambert@primenet.com>, jas@flyingfox.com (Jim Shankland) Cc: mark@vmunix.com, hackers@FreeBSD.ORG, isp@FreeBSD.ORG Subject: Re: TIME_WAIT/FIN_WAIT_2... Message-ID: <E0ydDio-0001gv-00@oak67.doc.ic.ac.uk> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: TIME_WAIT/FIN_WAIT_2..." (May 22, 7:43pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 22, 7:43pm, Terry Lambert wrote:
} Subject: Re: TIME_WAIT/FIN_WAIT_2...
> > [mark@vmunix.com (Mark Mayo) asks about large numbers of TCP connections
> Because the peer is *NOT* in CLOSE_WAIT state, because the peer is
> a Windows box, and the socket descriptor was abandoned with the
> peer in CLOSE_WAIT, without a resource-track cleanup of the connection.
[snip]
> Here is what the Windows machine does, when you are not running
> WinSock 2.0, and you have not called "shutdown()" on the socket,
[snip]
> TCP A TCP B
>
> 1. ESTABLISHED ESTABLISHED
>
> 2. (Close)
> FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
>
> 3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
>
> 4. (Exit)
> FIN-WAIT-2
> 5.
> FIN-WAIT-2
> 6.
> FIN-WAIT-2
>
> In other words, the socket is torn down without a LAST-ACK.
> The "workaround" that you should use to deal with this is to:
>
> A) wait 2 MSL for the LAST-ACK.
>
> B) reset to FIN-WAIT-1; send the packet.
>
> C) if you get CLOSE-WAIT, then goto (A).
I'm a little unclear as to what exactly what should happen when
a TCP stack receives a packet when it is in CLOSE-WAIT state. Are
you relying on the following bahaviour documented in STD7, line ~2358?
3. If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
> D) if you get no response in 2 MSL, or RST, then act as if
> you had recieved the CLOSE-WAIT, transitioned to FIN-WAIT-2,
> and subsequently recieved the LAST-ACK.
Uh-huh.
> E) (potential "enhancement") If you get no response, rather
> than treating it as an RST, goto (A), but maintain the
> FIN_WAIT_2_TIMEOUT kludge currently in place.
Can I suggest that if you receive a response after step C, which you call
the CLOSE-WAIT response, then the TCP stack should remain in FIN-WAIT-2
with an infinite timeout, because the response indicates that the remote
TCP stack not broken and moreover that the remote client is not finished
sending yet. (i.e. the 11 minute timeout you mention later would not
be used)
> Of of the main pains-in-the-ass in not calling "shutdown()" is
> Netscape, BTW.
Well, the Windows TCP/IP stack should be sending the FIN when the
socket is closed.
> 11 mintues is too long a time compared to 6 MSL. By sending a
> "duplicate packet" to test the lividity of the client, you can
> solicit a "keepalive" (or an RST). If you get the RST, then you
> recover from the client error.
And otherwise wait indefinately for the FIN?
> And according to RFC793, they are not supposed to be timed out at
> all, ever, and FreeBSD's implementation is non-conforming for doing
> the 11 minute drop.
[snip]
> Much as I hate the idea of being bug-compatible with NT, at the very
> least there should be a sysctl that acknowledges the fact that most
> client machines are Windows boxes with broken TCP implementations.
I think that this is a bug Microsoft would be eager to fix, after all,
if it affects FreeBSD web servers it also affects NT web servers, as
well as NT file servers, Exchange servers etc etc. Has anyone yet
verified that this is indeed the observed behaviour with NT with all
applied patches? If so perhaps we should try and convince Microsoft to
fix the problem first. Although having said that, Terry's algorithm
does have the nice side effect of allowing us to remove the 11 minute
non-conformant FIN-WAIT-2 drop.
Niall
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0ydDio-0001gv-00>