httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip A. Prindeville" <>
Subject Re: [BUG] 1.3 not closing socket on NT
Date Fri, 05 Sep 1997 04:53:00 GMT
	Date: Thu, 4 Sep 1997 22:32:40 -0600 (MDT)
	From: Marc Slemko <>
	Subject: Re: [BUG] 1.3 not closing socket on NT

	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.

Hmmm.... OK, must have filed that fact away somewhere irretrievable.
In TP-4, there is no graceful close.  You just delete the TCB.  You
must negotiate the close at the session (or application) level.

	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. 

I agree.  Breaking (b) as workaround to a problem with (a) is never
a workable solution.  They should let the vendor for the broken server
take some heat for their stupidity.

	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.

Hmmm...  That's right.  Because a FIN means I am FINished sending
data (but I'm expected to be able to keep receiving until you send
me your FIN).

	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.

Hmmmm....  If Netscape ran into the sea and drowned itself, do you
think .... ???  It's too much to hope for, but it might be worth
the sacrifice.

	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).

	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.


View raw message