Hi there,

I have a program executing on...
libcurl 7.19.5
Windows 7 (starter).

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

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

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

Searching previous posts to this list I found the statement
"The CURLE_RECV_ERROR return code is a failed recv() call (or similar)"
i.e. it is a failure of the underlying recv() function.

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)

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

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).

Questions:
Does my theory match the observed behaviour?
Is an indefinate timeout the deafult behaviour?
Is it possible that Curl is stuck doing something else?
Can I affect this timeout behaviour with the use of the various TIMOUT options? (or is that dangerous)

Anything that I've missed?
Any other ideas?

cheers,
   James.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-10-04