httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Netscape 3.0/Win95 doesn't have "Roy's" FIN_WAIT_2 problem
Date Thu, 30 Jan 1997 02:34:41 GMT
Netscape 3.01 on Win95 does _not_ appear to exhibit the problem of leaving
the socket in the FIN_WAIT_2 state until exit or another connection is
opened which Roy found.

However, MSIE 3.01 _does_ have this problem.  

More importantly, I think I may have figured out part of the cause of
some of the FIN_WAIT_2 problems.  

The close of a connection with Navigator 3.01 on Win95; alive is the server:

18:57:46.430330 > P 101:140(39) ack
273 win 17520 (DF)
18:57:46.430379 > F 140:140(0) ack
273 win 17520 (DF)
18:57:46.431790 > . ack 141 win 8621
18:57:46.434525 > R 19158839:19158839(0)
win 0 (DF)

The server sends a FIN, the client sends an ACK, then instead of the 
client properly shutting down their half of the connection they send a 
RST.  This presents two problems:

	- it is lame and it sure ain't TCP
	- the FIN will _NOT_ be retransmitted if lost during transit.  This 
	  means the connection will hang in FIN_WAIT_2 until it times out
	  on the server _if_ the server has a timeout.

There was some talk of this on end2end-interest, and someone mentioned
that Microsoft knew this was against the standard and said "tough, 
we are doing it that way.  End of discussion."  I am not yet entirely
sure how lingering_close() fits into this.  I am also not sure how much
of it is Netscape's doing (the client) or Microsoft's doing (the author 
of the stack).

Sheesh, MSIE sends lots of crap headers, or did I miss some standard or

	GET / HTTP/1.0
	Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
	Accept-Language: en
	UA-pixels: 800x600
	UA-color: color24
	UA-OS: Windows 95
	UA-CPU: x86
	User-Agent: Mozilla/2.0 (compatible; MSIE 3.01; Windows 95)
	Host: alive:1234
	Connection: Keep-Alive

View raw message