Date: Fri, 22 May 1998 09:43:04 -0700 (PDT) From: Jim Shankland <jas@flyingfox.com> To: mark@vmunix.com, tlambert@primenet.com Cc: hackers@FreeBSD.ORG, isp@FreeBSD.ORG Subject: Re: TIME_WAIT/FIN_WAIT_2... Message-ID: <199805221643.JAA01914@biggusdiskus.flyingfox.com>
next in thread | raw e-mail | index | archive | help
[mark@vmunix.com (Mark Mayo) asks about large numbers of TCP connections in TIME_WAIT and FIN_WAIT_2 states on a busy Web server. Terry Lambert <tlambert@primenet.com> responds: > This is a client bug, specifically with Windows WinSock clients, which > do not call "shutdown(2)" in the following way: > > shutdown( s, 1); > > The '1' should be a '2', but many WinSock implementations fail to work > correctly if it isn't a '1'. > > [...] > > The fix is to be bug-compatible with Windows NT as a server, and to, > when you are in FIN_WAIT_2 state, back up to resend the FIN. > > The problem is the lack of an ACK needed for a state transition in > the Windows TCP/IP implemenetation. Terry, I think you have your TCP states mixed up. First, none of this applies to the TIME_WAIT connections. As for the FIN_WAIT_2 connections: FIN_WAIT_2 means, "I'm done sending, I've sent a FIN, the other side has ACKed my FIN, but the other side has not sent *me* a FIN to indicate that it is done sending." One would then expect the peer to be in CLOSE_WAIT state. This is a perfectly legal state that can persist indefinitely, with the CLOSE_WAIT end sending unbounded amounts of data to the FIN_WAIT_2 end for consumption. Why on earth would you "back up to resend [a] FIN" that has already been ACKed? I suspect what you really mean is that the client side never sends its FIN, even though it's really done sending, leaving the server-side hanging in FIN_WAIT_2 state, waiting for either more data or a close from the client, while the client wll never bother to send either.. This can happen due to application-layer or TCP-layer bugs on the client side, or because the client crashed or was powered off at an inopportune time. What BSD-based TCP stacks do is this: if the FIN_WAIT_2 socket has been closed by the application (i.e., there's no-one there to receive any data that might arrive), and no data arrives for about 11 minutes, then the connection is silently dropped. (Remember, if the FIN_WAIT_2 socket has not been closed, then data could arrive after an arbitrarily long silence, and there's a process there to read that data; so the connection *must not* be dropped.) So what you're really seeing, Mark, is connections in FIN_WAIT_2 state, where the web server has closed the socket, but the client has never indicated that it is done sending. These hang around for about 11 minutes, then disappear. (Of course, more take their place.) The reason for the 11 minute wait is so that if the client is just slow going through its shutdown stuff, the server can still walk the client through an orderly close. On the other hand, maybe 11 minutes is too long? I'll bet nothing terrible happens if that timeout drops to 1 minute ... or 30 seconds. Even 0 would at worst lead to some unnecessary RST's on closing connections. Anyone have any thoughts on this? Jim Shankland Flying Fox Computer Systems, Inc. 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?199805221643.JAA01914>