From: Daniel Ouellet (danielpresscom.net)
Date: Tue Dec 11 2007 - 18:51:02 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

knitti wrote:
> you tell me that there is some correlation between HTTP keep alives and
> a socket ending up in CLOSE_WAIT for some time. That is the practical
> observation. But I'm interested in whether this is by design or not.
> RFC 2616 doesn't mention implementation details, and I can't see why
> the socket implementation (OS) would want to keep a socket in
> CLOSE_WAIT for some time (not sending a final ACK).

No. I am saying that there is a direct relation between the socket not
being available to reach that state and the value assigned to keep alive
making it take more time to reach the CLOSE_WAIT state and as such
reducing the number of sockets you can use and as a side effect of this,
limiting the number of users httpd can handle.

As to the second part of that question, meaning "after it reach the
CLOSE_WAIT", how long it stay in it? I think, and that's where my
knowledge and understanding is lacking some, that it is at that point an
OS part and as such may be able to be adjusted by some OS variable, not
applications one at that time.

See, the difference is creation, usage and destruction of sockets are an
application function, but all the signaling of it and handling of it is
an OS function. At a minimum, that's how I understand it and as such
when you reach the CLOSE_WAIT state, that's not under the application
layer control anymore, but the OS and as such can be helped by OS changes.

I may be wrong here and if so, I would love for someone to correct that
for me, but that's how I understand it.

The creation, usage and closing of the socket itself is application
related, but the signaling, etc is a function of the TCP/IP stack under
the OS control, and this 'CLOSE_WAIT' state is in the TCP/IP stack
control and as such not an application issue, but an OS control factor
that may be helped some and only if needed under heavy traffic as other
wise the default as good as is.

I hope this makes it more clear, for my own understanding, or lack there
of, of it anyway.

May be I make a foul of myself here (wouldn't be the first time and I
only learn by extending myself out and learn from my mistakes), but that
what I understand is, thinking about it now.

So, that's why I pointed the three parts that would/could help in this case.

Best,

Daniel

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]