From owner-freebsd-hackers Sat May 23 05:48:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20587 for freebsd-hackers-outgoing; Sat, 23 May 1998 05:48:48 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (IyaysqvMP0eYKvfKQoE1v87Ow7fS0Bu3@heron.doc.ic.ac.uk [146.169.46.3]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA20578; Sat, 23 May 1998 05:48:42 -0700 (PDT) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([a+uCvNv8PtCXHuJbZsFGfqEmGalMqQpD]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0ydDip-0000VP-00; Sat, 23 May 1998 13:48:23 +0100 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0ydDio-0001gv-00; Sat, 23 May 1998 13:48:22 +0100 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Sat, 23 May 1998 13:48:21 +0100 In-Reply-To: Terry Lambert "Re: TIME_WAIT/FIN_WAIT_2..." (May 22, 7:43pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Terry Lambert , jas@flyingfox.com (Jim Shankland) Subject: Re: TIME_WAIT/FIN_WAIT_2... Cc: mark@vmunix.com, hackers@FreeBSD.ORG, isp@FreeBSD.ORG Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 --> --> CLOSE-WAIT > > 3. FIN-WAIT-2 <-- <-- 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