httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@topsail.org>
Subject Re: cvs commit: apache/htdocs/manual/misc fin_wait_2.html
Date Sat, 01 Feb 1997 04:46:49 GMT
Jim Jagielski wrote:
> 
> Marc Slemko wrote:
> >
> > > That can't be right, or at least it doesn't make sense. If the server
> > > decides to timeout, for whatever reason, it is perfectly justified
> > > in closing the connecting. Does the protocol actually state that
> >
> > And it can close the connection.  It just involves more than simply a
> > close().  A TCP close is already a multi-step process, this just adds
> > another step.
> 
> A step which may not be needed and seems to cause problems with
> lots of systems TCP/IP stacks. The fact that SGI is now "fixing"
> it is just another data point that whatever lingering_close is
> doing, it's bad.
> 
> ...
Let's not lose sight of the forest. If we were the only source of
FIN_WAIT_2 states, I doubt everyone would change their TCP stacks to add
timeouts just because we have a beta release out. Everyone's having this
problem, is my guess, from crappy browsers. It almost sounds like
Netscape is acting like the server side of a half-close would, eh?

BTW, got about 8 hours of tcpdump data from the proxy at (soon to be
ex-) work today. Lotsa RSTs sent on keepalive connections, some NT, most
Win95, all Netscape 3.x. I'll get a chance after the weekend's coding
festivities to sort through the data in more detail.
-- 
chuck
Chuck Murcko
The Topsail Group, West Chester PA USA
chuck@topsail.org

Mime
View raw message