On Tue, 18 Mar 2008, Gabriel Kälin wrote:

> I was talking about libcurl. I'm using the easy interface with
> curl_easy_perform(), which does not return nor call any callbacks in this
> case. So from the application point of view it seems blocking. At any rate
> it is synchronous.

Right, but internally libcurl is using non-blocking sockets so no
socket-related function should ever block.

I'm not saying the behavior you mentioned doesn't happen, just that however it
happens it shouldn't be an actual blocking socket call.

>> It can't avoid it, it just needs to deal with it. And it can minimise the
>> occurance by the use of TCP KEEPALIVE messages - but then you need to
>> enable them in your app.
>
> What options can an application set in order to prevent libcurl from
> spending too much time on the dead connection?

Eh, none. libcurl should never spend much time on dead connections. If/when
you see that, it is rather a sign of a bug and not how it is supposed to work.
I can't think of any situation where detecting a dead connection should be
time consuming. Can you?

> TCP keep-alive indeed is a partial solution, but it doesn't solve the
> problem if the firewall is reconfigured or drops the connections anyway.

Yes it does. If the TCP stack detects that the connection went down, then
libcurl's "check-if-dead" function works properly and instantly (well almost).

> I've performed a test, where I configured the firewall to drop any packets
> on the connection at 18:35:00. A dump of network traffic reveals, that the
> connection remains established until I kill the process at 18:38:30.

I've never seen anything like this happen in real life, and in fact I don't
see what libcurl can do to detect this particular situation any better than
currently.

Does a NAT really just swallow the packages after it has closed down a TCP
"session" ?

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