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
