httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: [BUG] 1.3 not closing socket on NT
Date Fri, 05 Sep 1997 05:14:01 GMT
On Thu, 4 Sep 1997, Philip A. Prindeville wrote:

> 	Sending a RST also has the problem of if it is lost, then the server
> 	will remain in FIN_WAIT_2 until it times out which, on some systems, is
> 	forever.  The RST won't be retransmitted so it isn't a reliable close.
> 	A proper TCP close is reliable.
> Actually, there are good reasons for retransmitting RSTs, one of them
> being it doesn't do any harm to send duplicates (since the same
> associatation can't be used for 255 seconds anyway).

The fact is either you have to retransmit it over and over on the
chance it will get lost or you have to send it once and hope it
doesn't get lost.  However you do it, that is not a reliable close
so if you have the right packet loss (eg. link down for 5 seconds,
which could swallow all your RSTs) the server won't get the RST.
A proper TCP close is reliable.

> 	In any case, I think that "fixing" Netscape would only make the
> 	perceived problem with sockets in CLOSE_WAIT bigger.  Sending the RST
> 	avoids CLOSE_WAIT.
> You lost me there.  The socket should leave that state (and have its
> TCB deleted) after a reasonable amount of time.

Sending the RST avoids CLOSE_WAIT.  Otherwise, you have a socket
hanging around in CLOSE_WAIT for 2*MSL; it appears NT is too
stupid to handle that without crashing, so fixing the clients to
properly close the connection would result in more connections
in CLOSE_WAIT which would result in it crashing faster.

NT should not crash, even with thousands of sockets in 
CLOSE_WAIT.  Probably some registry parameter you can tune.

If you are referring to hanging in FIN_WAIT_2 if the RST is lost,
traditional BSD stacks have _not_ had a timeout on FIN_WAIT_2.  It
is not in the protocol spec.  Most modern OSes have it, but a good
number (eg. SunOS 4.x) don't.

View raw message