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?
>
> Marcin Adamski
>
>
Hi Daniel & all,

I'm just starting my first libcurl project and have the same kind of
question. The application is collecting information from printers,
primarily via SNMP. Unfortunately, printer manufactures aren't very
open with a lot of information we want to collect, hence the need to
engage in the ugly act of scraping information via HTTP. The program is
a single threaded state machine, driven by a select() function. The
curl_multi_fdset/curl_multi_perform architecture looks like it should
drop in in BEAUTIFULLY!

Like Marcin, I think, I'm interested in how vigorously I need to call
curl_multi_perform. I'm not after high performance. I will have a lot
of traffic happening simultaneously (particularly UDP) and I want to
give processing the UDP SNMP messages priority. This is happening in a
long-running daemon program (errr, Windows service.) If an HTTP scrape
takes a little longer, I don't care. How lackadaisical can I be about
calling curl_multi_perform?

The 'perform man page says :
"Before version 7.20.0: If you receive CURLM_CALL_MULTI_PERFORM, this
basically means that you should call curl_multi_perform again, before
you select() on more actions. You don't have to do it immediately, but
the return code means that libcurl may have more data available to
return or that there may be more data to send off before it is
"satisfied". Do note that curl_multi_perform(3) will return
CURLM_CALL_MULTI_PERFORM only when it wants to be called again
immediately. When things are fine and there is nothing IMMEDIATELY it
wants done, it'll return CURLM_OK and you need to wait for "action" and
then call this function again. "

I'm trying to figure out what this really means. What about from 7.20.0
onward? The bolding of IMMEDIATELY makes it seem like one MUST (in the
RFC sense) call 'perform if one gets CURLM_CALL_MULTI_PERFORM. Is this
really so? I understand that it means 'perform has more work to do
without going back to select(), but what if I have other things to do?
  What if I want to go back to the select() because I want to check for
and process any new UDP traffic first? Is this harmful? Is this really
more along the lines of an RFC MAY?

For program timing, my select() timevals are always a second or less.
So, if I can guarantee that 'perform will be called at least once a
second, do I need to even mess with getting the timeout value from libcurl?

I'm hoping to make a comment post along the lines of "libcurl - a
newcomers first impressions" when I "have time." For now, let me just
say this: WOW!

Cheers!
Rich
http://www.plustechnologies.com

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