SPUG: Closing HTTP::Daemon port

[Andrew Sweger]

On the ^C thing: if you kill the first instance of the daemon _before_ any
client connections have been made (thus creating our TIME_WAIT zombie
sockets), then the server completely shutdown and releases all network
resources immediately.

On Tue, 12 Aug 2003, Andrew Sweger wrote:

> On the network side of things, what I am seeing is a socket created by the
> second instance (by the get() call I presume) that hangs around for a
> minute in TIME_WAIT state. It's on the daemon's side of the connection
> (the first instance). So, I'm going to say that it is your daemon that's
> not cleaning up the socket after handling incoming requests. I can prove
> this by calling for arbitrary URIs on this port (repeatedly) and see
> half-dead sockets piling up on the daemons side. E.g., "wget
> http://localhost:9876/foobar". The TIME_WAIT sockets are not associated
> with any process. If I remembered more about the TIME_WAIT state, I'd know
> what this means. But I'm guessing that the daemon is releasing the socket
> before completely shutting it down after handling the request.

It looks like TIME_WAIT is a part of life with TCP/IP. But I know I deal
with servers that don't exhibit this behavior (some written by me back
where my memory has faded). I have read that the TIME_WAIT state occurs
_after_ the socket has been closed but to allow handling of data that may
still be on the network. The TIME_WAIT state can last up to four minutes
depending on certain attributes of the socket.

I have attempted to influence the $connect socket by calling flush and
shutdown on it prior to the close, all to no avail (as well as the $server
instance). It's been a long time since I've tinkered with socket stuff
lower down than this (and my hands just start shaking when I even think of
taking the debugger back down there).

I'm throwing in the towel. :)  Good luck.

-- 
Andrew B. Sweger -- The great thing about multitasking is that several
                                things can go wrong at once.