On Mon, 4 Oct 2010, curl_at_james-rhodes.demon.co.uk wrote:

> The program periodically does an HTTP GET using the 'easy' interface, in
> it's own thread. On one run it paused for a long time (about 7 hours) before
> returning an error '56' - CURLE_RECV_ERROR

Does it happen often? Regularly? Sometimes? Only once?

> During this period another thread was sucessfully executing FTP gets/puts
> with the curl interface.

That proves the network was functional, but a single connection could still
have problems. Like if a NAT timed out the session or similar.

> It is notable that the call returned just as the the network interface was
> removed.

Well, at that point the function call probably returned an error which it
didn't previously.

> MSDN tells me...

> "If no incoming data is available at the socket, the recv call blocks and
> waits for data to arrive according to the blocking rules defined for WSARecv
> with the MSG_PARTIAL flag not set unless the socket is nonblocking."
>
> I had thought that Curl used non-blocking sockets internally, but only
> exposed non-blocking behaviour in the multi interface (from previous
> mailings)

That's correct.

> The interesting thing is that I can see from the web-server access_log that
> the response was dispatched (with out error) almost immediately.

Can you also see it happen if you snoop on the network like with wireshark? If
so, it sounds like a bug in libcurl. If so, I would ask you if you can repeat
this problem with the latest libcurl too.

> This is over a wireless broadband device so it possible that there is some
> transparent proxy in the path. It is (currently) my supposition that this
> proxy correctly got the data from the server but then failed to pass it on
> and then also failed to close the TCP connection (and kept it alive).

Yeah, that's what it sounds to me as well. Either that or a bug somewhere
else...

> Is an indefinate timeout the deafult behaviour?

Yes.

> Is it possible that Curl is stuck doing something else?

Everything is possible, but it isn't a bug that I recognize.

> Can I affect this timeout behaviour with the use of the various TIMOUT
> options? (or is that dangerous)

You can affect this with a CURLOPT_TIMEOUT, by using CURLOPT_LOW_SPEED_LIMIT /
CURLOPT_LOW_SPEED_TIME or implementing your own magic with the callbacks.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html