httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: more lingering_close... (tcpdump analysis)
Date Sun, 09 Feb 1997 23:10:25 GMT
On Sun, 9 Feb 1997, Jim Jagielski wrote:

> Ben Laurie wrote:
> > 
> > So, as you say, it might be reasonable for the stack to not send RSTs
> > until the other end has closed. On the other hand, that would seem prone to
> > problems - the client may carry on sending forever, and there's really no point
> > in permitting it to. If data is expected from the other end, the only correct
> > thing to do is half-close (in the real sense of the word - the above usage is
> > misleading; the connection is in the process of doing an orderly close). That
> > is, to close the server's output, and leave the input open, and read to EOF.
> > Otherwise known as an l_c(), I believe.
> > 
> 
> I just know I'm pissing people off by this, and I have no real
> desire to do that... I'm just trying to make this as clear as
> possible, in a theoritical way as well as practical.
> 
> Let's assume that someone has set Apache up for 5 keepalives.
> Let's also assume that a client is setup to attempt 100 keepalives.
> As I understand it, the way Apache currently works is that after
> the 5 it responds to, it closes it's output and listens to the next
> 95 requests simply to ignore them, at which point it fully closes
> the socket. It does this to guarantee that it not send the final
> fin/ack until it's sure the client is ready for it.

No.  It sends its final FIN as soon as it finishes sending data, and the
client ACKs that. This means that the client will get an EOF on the next
read, or whatever happens with the particular API.

Then Apache keeps reading data.  The client may send the next 95 requests,
in which case Apache will ignore them unless they take longer than the
length of the 'Timeout' directive.  However, what the client _should_ do
is figure out the connection is closed and stop sending.  Then Apache may
get a few more requests after the first five, but not 95 unless the client
is really dumb.  The lingering close is really needed for the period
between when Apache closes half of the connection and when the client
figures out that half the connection is closed.  The minimum time required
for that is 1/2*RTT, but since the client could have sent something right
before it got the FIN you need to wait at least 1*RTT on the server in the
ideal case.

In any case, if the client gets the RST after the server has got the ACK
of the last packet of the close the client _can_ still ignore the error,
IN THIS CASE.  That doesn't always work.

> 
>    1. Is this, in fact, the way it actually works?
>    2. Is this a Good Thing?
> 
> My beef is, and has always been, that the problem can be "taken care
> of" much easier on the browser side, instead of Apache trying to

No.  It can not.  Write the client that does it, then I will agree.

Yes, it can be partly to mostly worked around and kludged by the client so
it mostly works by not stopping pipelining but I don't really like that
method and it doesn't work all the time. 

> "overrule" the underlaying tcp/ip layer. When a solution requires
> all OS vendors to "adjust" their tcp/ip implementations or else
> suffer reboots every coupla days, something is very wrong.
> 
> l_c() fixes the problem but also causes performance hits as well
> as severe operational constraints unless an OS vendor has patched
> their stack and the user has thusly upgraded to that new version.
> What's that old medical saying... "Do no harm".
> 
> Is the "cure" worse than the disease?



Mime
View raw message