httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: [PATCH] lingering_close performance improvement
Date Sun, 09 Feb 1997 20:17:55 GMT
On Sun, 9 Feb 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > NO!
> > 
> > IT IS NOT JUST BUGGY BROWSERS.
> > 
> 
> True enough... It's also browsers that don't do correct error
> detection... ALL "problems" that l_c() try to fix can be done on the
> browser side by simply checking things before assuming that the
> socket it open.

NO!

NO!

NO!

No.  You are assuming that the RTT is always 0.  That is not true.  It is
very often as high as 2000ms for users connecting via modem and using
multiple connections.  Even if the client checks everything they can
possibly check all the time, they can still have problems unless they
don't use persistent connections.  Read my annoted PUT.  Look carefully at
the timestamps.  Even if the client stops sending data as soon as it gets
the FIN from the server, it will still get RSTs unless the latency between
client and server is _extremely_ (ie. probably far lower than ethernet)
low. 

There are things browsers can do to work around the problem; hey, no
problems if they don't support persistent connections or HTTP/1.1; 
supporting them is a bug in the browser, so Apache shouldn't worry about
it.  Requiring that a browser retry without using persistent connections
seems to me like forcing the client to work around a shortcoming in the
server.  

There is no way for the client to get rid of this problem without
modifying the TCP stack in a way which would probably violate the RFC and
be bad.  There is a way for the server to do it.



Mime
View raw message