> -----Original Message-----
> Daniel Stenberg
> Sent: Tuesday, March 18, 2008 1:47 PM

> > In that case curl seems to block indefinitely instead of
> establishing a new
> > TCP connection.
>
> curl or libcurl? libcurl uses non-blocking connections so it
> doesn't block on
> the socket functions and it shouldn't block on this kind of
> situation either -
> it's not even a very rare situation.

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.

>
> > How can curl avoid this situation without stopping to
> re-use connections?
>
> 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?
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.

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.

No. Time Src Dest Protocol Info
22 18:34:51.430010 A B HTTP GET / HTTP/1.1
23 18:34:51.531943 B A TCP http > 49034 [ACK] Seq=3396281101 Ack=3475429659 Win=50400 Len=0
24 18:34:51.574422 B A HTTP HTTP/1.1 200 OK (text/html)
25 18:34:51.676621 A B TCP 49034 > http [ACK] Seq=3475429659 Ack=3396282015 Win=50400 Len=0
36 18:36:28.650103 A B HTTP GET / HTTP/1.1
37 18:36:33.436618 A B HTTP GET / HTTP/1.1
38 18:36:43.006687 A B HTTP GET / HTTP/1.1
39 18:37:02.136748 A B HTTP GET / HTTP/1.1
40 18:37:40.386622 A B HTTP GET / HTTP/1.1
41 18:38:30.736661 A B TCP 49034 > http [FIN, ACK] Seq=3475430566 Ack=3396282015 Win=50400 Len=0

>
> > The only way I see would be CURLOPT_LOW_SPEED_LIMIT and
> > CURLOPT_LOW_SPEED_TIME. Am I missing an obvious solution to
> this problem?
>
> Those options have no effect when libcurl doesn't do
> anything, which is the
> time when idle connections typically are "killed" by NATs/firewalls.

I'm not that much bothered with TCP connections in the CLOSE_WAIT state, but when a new request is performed, I don't want libcurl to take too long until it figures out that the connection may be dead.

Gabriel