httpd-dev mailing list archives

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

> 	I've made some tracing with tcpdump -vv.
> 
> 	They seems to show that the problem is originated by the fact that
> 	windoz clients (netscape 3 on win95) reset the socket after
> 	acknoledging a FIN, versus Unix clients (Lynx 2.6) that after
> 	acknoledging a FIN send another FIN..
> 
> Actually, one FIN is being sent in either direction with the same
> sequence number as the last byte of data sent, which is the correct
> behaviour.  RSTing a socket is definitely *not* the right thing to
> do.  This is broken behaviour.  Complain loudly to Netscape.  I'm
> surprised that a client even has that much control over the
> connection.  Under UNIX a process has to terminate without closing
> the socket properly to cause a RST (e.g. coredump, etc).

Yes it can.  If you set the linger time to 0 and close it right, it will
send a RST.  Some versions of Navigator do this on Unix.  A similar method
is used under the Windows socket interface.

This was done on purpose by MS and NS.  There are two reasons behind it. 
The first is to avoid CLOSE_WAIT because broken servers can't handle it. 
That is a poor reason. 

The second reason is so that servers will abort the data they are in the
process of sending when the client aborts a connection; it is impossible
to do anything else if the client wants to terminate the request in the
middle of a connection.  This is a valid case to send a RST in.

You ask why don't they just do that for connections they abort?  I asked
MS and NS the same question, and they told me "erm... erm... good
question".  They have told me that they are fixing it to do proper closes
for cases where the connection is not aborted by the client.  I have not
checked v4.x of Navigator and MSIE to see if they have actually fixed it.
I should check and pester them again if it isn't fixed.

Oh, actually what MS said about why they send it was "because NS did it so
we just copied it".  Honest, that's what they said.

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.

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.


Mime
View raw message