On Wed, 6 Apr 2005, Andrei Tarassov wrote:

> The situation is that the sockets is hanging in CLOSE_WAIT state for hours
> (at least I did not notice any changes in the output of the lsof command).
> On the server side there seems to be nothing known about these connections.
> I guess the server has closed its socket, but for some reasons the client
> does not know anything about that.

What OS? Does it happen for all protocols? How many sockets do you get in
CLOSE_WAIT after having done a single libcurl request (for a given protocol
such as HTTP for example)?

> If that is the situation, then my understanding is that the connection
> should be closed on the client side as well, at least after some timeout.
> However this does not seem to happen.

IIRC, CLOSE_WAIT should normally be two minutes.

> 1. Has anyone encountered the same problem and handled it?

Not me, and I've not seen anyone report this before.

> 2. At what moment curl closes the TCP socket?

It uses many sockets and thus closes them all over. Search the source code for
'sclose' and you'll see. I'm pretty sure it closes all of them as it should,
as otherwise both the internal memdebug system as well as valgrind would
complain when running test cases.

> 3. Is there any way to pass custom options to the curl function, which
> creates a socket? I want to try to play with different timeouts a bit.

Nope. There have been talka about adding such a callback that allows the app
to set whatever options it desires, but it hasn't been done. I'm not even sure
anyway works on it.

> 4. Is there any way to switch off the normal tcp connection closing
> procedure, i.e. to close the socket without sending different FIN/ACKs?

I don't think you can do that with plain stream sockets. But I'm far from
sure.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html