Re: What are consequences of late curl_multi_perform call
Date: Mon, 3 Oct 2011 16:41:25 +0200 (CEST)
On Mon, 3 Oct 2011, Marcin Adamski wrote:
> I'm wondering what are consequences of late curl_multi_perform call. I guess
> that it may cause some timeouts to occur later than it should i.e. we set
> CURLOPT_TIMEOUT for 60s, but whole operation lasted 62s. But are there any
> significant consequences for ongoing transfer? Say we are downloading file
> via FTP and we call curl_multi_perform 3s too late. Can it be the reason for
> transfer failure? In my understanding all protocols that use TCP should
> handle this kind of delay. Am I right?
Okay, let me first address your question(s) and then I'll see what is left to
cover Rich's additional thoughts. Let me preface my explanation by saying that
if you can figure out a wording and a place where we can insert this into the
documentation to help users, please let me know!
First, libcurl provides the curl_multi_timeout() function to help applications
know when to call curl_multi_perform(). That's the longest time you should
wait before you call libcurl again to make sure it can keep its internal
libcurl has some timers and timeouts internally. libcurl itself bascially
doesn't need to be called repeatedly to keep the timers accurate, that's more
of a choice and effect that may be wanted by the application. There are some
exceptions, like when doing UDP transfers (for example during c-ares name
resolving or when doing TFTP transfers etc) then libcurl might need to handle
packet retransmissions and during that time a very slow calling of
curl_multi_perform() might hamper libcurl's ability to do good.
In all cases where TCP based transfers are used, I can't think of any moment
in time where it would matter much if you call curl_multi_perform() "too
late". The connections themselves and their flow control etc will be dealt
with using TCP magic. If you wait a very long time, you may hit TCP_KEEPALIVE
limits or just that there isn't any traffic on the connection that makes your
NATs or firewalls to consider the connection dead.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2011-10-03