httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: more lingering_close... (tcpdump analysis)
Date Sun, 09 Feb 1997 22:26:18 GMT
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.

Don't keep thinking that discussing an issue pisses people off. It certainly
isn't having that effect on me.

> 
> 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 does this to ensure that the client sees the response that caused it to
close the connection. Or else it might just go round again, and so on forever.
But this may not be the only way to solve the problem. This is important,
AFAICS.

> 
>    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
> "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?

Possibly. I refer you to my summary for some alternatives.

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Mime
View raw message