Bug #17044 Updated: TIME_WAIT status
| From: | filippo at zirak dot it | Date: | Mon, 24 Jun 2002 13:07:36 +0000 |
| Subject: | Bug #17044 Updated: TIME_WAIT status | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-11907@lists.php.net to get a copy of this message | ||
ID: 17044
Updated by: filippo@zirak.it
Reported By: gberger@apaara.com
Status: Open
Bug Type: Sockets related
Operating System: Linux Red Hat 7.0
PHP Version: 4.2.1
New Comment:
the thing i do not understad is that in the praticular case described,
the tcp connection opened to the browser stays in TIME_WAIT as
well;
this should not be, since webserv is the server in this case.
probably,
this is an apache issue.
just because i'm curious, fillipo: what kernel and what apache do
you
use?
Previous Comments:
------------------------------------------------------------------------
[2002-06-19 11:13:04] gberger@apaara.com
as i have discussed with others in the meantime, i think the TIME_WAIT
status is not the problem:
the process that is opening a tcp-connection from webserv to tixserv
needs to stay in TIME_WAIT, in case its last ACK is lost and tixserv
sends its FIN again. webserv is acting as client here and has to stay
in TIME_WAIT for 2MSL.
the thing i do not understad is that in the praticular case described,
the tcp connection opened to the browser stays in TIME_WAIT as well;
this should not be, since webserv is the server in this case. probably,
this is an apache issue.
just because i'm curious, fillipo: what kernel and what apache do you
use?
------------------------------------------------------------------------
[2002-06-19 10:46:32] filippo@zirak.it
> probably, this is not a php issue anymore.
I think it still is a php bug (4.2.1)... even using it as command line
script, it seems from netstat that the connection is not well closed...
:-(
binding, accepting, (shutdowning,) closing a socket on 19731 leave
anyway the connection open in TIME_WAIT
tcp 0 0 localhost:19731 localhost:32861 TIME_WAIT
------------------------------------------------------------------------
[2002-06-18 02:40:06] gberger@apaara.com
i partially agree - have not thought about this yet. well, so i went
and turned KeepAlice Off in the apache conf. and yes, the described
behaviour went away. so far, so good.
but there are still some points that make no sense to me:
- the TIME_WAIT status of these tcp connections stays there until
timeout (after 2MSL has passed). that should not be the case if i am
doing an active close, right?
- even with KeepAlive On: in my apache conf, the KeepAliveTimeout
Directive is set to 15 seconds. but the tcp connection of httpd stays
in ESTABLISHED state for much longer than 15 seconds. this should not
happen, right?
probably, this is not a php issue anymore. i would be grateful for any
pointers, though.
btw. i have upgraded to php 4.2.1 in the meantime.
------------------------------------------------------------------------
[2002-06-17 07:16:48] rick@simpleftp.co.uk
Are you sure this isn't the keep-alive part of the HTTP protocol?
AFAIK, most browsers will use a keep-alive header to keep the
connection to the HTTP server open, even after it has received the
entire document. That lets it speed things up as it doesn't have to
reconnect to load another page, images or whatever.
There's details on the settings for it under Apache 1.3 at
http://httpd.apache.org/docs/keepalive.html
------------------------------------------------------------------------
[2002-05-13 05:16:21] gberger@apaara.com
i have also tried this in a slightly different setting:
red hat 7.2, kernel-2.4.7 and php 4.1.2.
in this environment, both tcp-connections go right to the TIME_WAIT
status and stay there for 1 minute (which seems to be 2MSL); the tcp
connection owned by httpd is not waiting in ESTABLISHED mode as it does
under kernel 2.2.
this seems to be a kernel-related issue, then? has anyone else
experienced this problem?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17044
--
Edit this bug report at http://bugs.php.net/?id=17044&edit=1