Bugs item #1358860, was opened at 2005-11-17 11:35
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1358860&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: bad behaviour
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Neville_Sinnamon_Aepona (ns0217)
Assigned to: Daniel Stenberg (bagder)
Summary: libcurl not closing sockets

Initial Comment:
We are using libcurl in our application which is
effectively an HTTP client. The HTTP server which we
connect to, is closing sockets after they have been
idle for 30 seconds. Our application (the HTTP client)
is not responding with its own close.

In TCP packet terms the HTTP server sends a FIN this is
ACKed but the client (our application using libcurl)
does not respond with it's own FIN.

Rather than the sockets closing this behaviour has the
effect of a socket going into the state of FIN_WAIT_2
on the server side and CLOSE_WAIT on the client side.
The sockets do eventually close after a timeout period,
but our customer would like the sockets closed immediately.

I've had a quick look at the libcurl code and (although
I'm no expert) it appears that after the client has
received the response from then server; flags are set
and the handle goes into a state where it does not
listen to the socket, that is until it receives another
http request to send to the server.

If the handle does not listen to the socket then it
cannot detect the FIN/close arriving and respond with
its own FIN.

Firstly is my analysis of the code correct? Is it a
feature or bug? Is there anything we can do about this?

Note the HTTP server is written by someone else and we
can't control its behaviour.

The version of curl we are using is 7.11 although I
have tried it with 7.15 (which I think is the latest)
and the behaviour is the same. OS = SunOS jotto 5.8
Generic_117350-12 sun4u sparc SUNW,Ultra-60.

Thanks, for you time Neville Sinnamon

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2005-11-18 00:21

Message:
Logged In: YES
user_id=1110

This is very much a design that is intended. If you want to
force a closure, then go ahead do that.

What is your suggestion on a better behaviour? I don't see
what else it can do.

----------------------------------------------------------------------

Comment By: Neville_Sinnamon_Aepona (ns0217)
Date: 2005-11-17 15:59

Message:
Logged In: YES
user_id=1380855

Firstly I understand the idea behind re-use: we like that
feature and it helps us. No, the issue we have can be
described better by: "libcurl not responding to close socket
from server side".

For a TCP socket to be closed it must be closed by both
sides of the connection. When the server closes the
connection libcurl should respond by closing it's end of the
connection too. When it doesn't the server side of the
socket remains in a state of FIN_WAIT_2.

The guys that own the server look at the sockets (using
netstat -a) and find them in a state of FIN_WAIT_2 (instead
of closed). They are complaining that our app is not closing
the socket, or more accurately not responding to the
server's close.

Eventually the socket is closed by the operating system
usually after 120 seconds. But the server guys would like
to see the socket closed immediately, and are complaining
that this is a drain on system resources.

Small diagram below showing the sequence of events.

libcurl --> http post --> server
libcurl <-- http response <-- server
connection idle for 30 seconds.

timout triggered on server side resulting in the server
initialing a close socket on the server.
libcurl <-- FIN <-- server
libcurl --> ACK --> server.

libcurl should send a FIN to the server next (to close the
socket) but it doesn't.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-11-17 13:29

Message:
Logged In: YES
user_id=1110

Of course it won't close them immediately after use since
that would kill all possiblities of re-use. You can easily
force a closure though by calling curl_easy_cleanup().

So yes, unless I misunderstand you this is very much a feature.

Why is this a problem to you?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1358860&group_id=976
Received on 2005-11-18