httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: more lingering_close...
Date Sun, 09 Feb 1997 21:48:11 GMT
On Sun, 9 Feb 1997, Jim Jagielski wrote:

> Ben Laurie wrote:
> > 
> > A timeout is a different matter. We should not l_c() a timed out connection -
> > that is silly - we are aborting it, because it isn't behaving, so trying to be
> > nice to it is self-destructive.
> > 
> It's not that we are l_c()ing a timed-out link but that l_c() contains
> a timeout itself. Thus, if Apache wants or needs to close the connection
> (say it doesn't want to handle anymore persistant connections) this
> would be handled by l_c(). l_c() closes all output but keeps on
> accepting input. However, it also has a timer in it such that if,
> during that time, it doesn't rec' input after a period of time,
> it simply closes the link anyway. If the whole idea behind l_c() is
> to NOT close the connection until we are 100% sure that the client
> is ready for it, then having a timer in it defeats it's own purpose.

It is OK to have that timeout based on the idea that if the client doesn't
do its half of the close in that period and we get no more data, then
either the RTT of the link is greater than the timeout or the client is
really broken.  If the client is really broken, too bad.

With the current implementation, if the RTT is greater than time timeout
(10 seconds min timeout) we have problems anyway.  Lowering the timeout as
Roy proposes does potentially have negative effects, although it should
improve the performance bit a lot.

> Now, as devil's advocate, if it's OK for l_c() to have a timer to
> keep from sucking up resources then how does l_c() help out? There
> is no real diff between closing the link or closing-output/waiting-a-
> few-seconds/closing-if-no-response. If the input we get is VERY slow,
> then once again we have a process tied up reading input, with the
> performance hits of that (at the least, we have a process just sitting
> there)... As it stands now, we have to wait until we gobble up every-
> thing before we can close the link...

All we _have_ to do is make sure that the client ACKs the last packet of
the error message before we send a RST.  Once the client has done that, it
knows the connection is closed and it should deal with anything further.
The timeouts interact closely with the RTT of the link.  There are unusual
situations where it behaves in a manner which could be considered bad, but
it needs to be a compromise between waiting forever for clients that never
finish the close and timing out too quickly and causing errors. 

>From a purely theoretical ideal situation protocol view, there should be
no timeout.  From a more practical view, clients will be broken so we need
a timeout.

View raw message