On Thu, 10 Mar 2005, Dominik Douville-Belanger wrote:

> Hi. I'm interested in integrating the bandwidth limiting capability of cURL
> into libcURL and I am looking at the application source code in order to do
> so. I am just wondering why it has not been done in the lib in the first
> place. I saw in the mailing list that you were waiting to do it correctly.
> Could the sleep like strategy done in the app be used in the lib? Better to
> do it another better way?

Allow me to tell the long (and hopefully complete) story:

libcurl offers two different APIs to file transfers: the easy and the multi
interface. The multi is completely non-blocking while the easy blocks until
the whole transfer is done.

The multi interface is used by adding separate easy interface handles to a
multi handle and then you do N connections simultanously. Thus, options for
invidual transfers is done using curl_easy_setopt() just like you do for easy
interface tranfers.

All transfer and protocol related options and features that is offered for
easy transfers are provided for multi transfers too.

So, while the sleep-approach would be very simple and easy to add for the easy
interface, it is not as nicely integrated into the multi interface since it
would imply blocking in a way it can't or at least shouldn't do.

To further add up, I plan to soon more or less remove the internal
special-cases for the multi/easy interfaces that exist in the code, and have
the easy interface use multi interface functions internally. Then there's no
room left for a sleep approach.

What is the "correct" approach? I don't want to be so bold to say that I have
the absolute truth, but I do have an idea on how it could be made. Feel free
to suggest other ways or improvements if you figure out any!

libcurl will be non-blocking and the caller will be responsible for the wait
until there's socket action or until a timeout has elapsed. When bandwidth
limiting is activated, we must make sure that the app only calls us after a
certain time and than we only receive/send a certain amount of data with a
time frame. So, by carefully adjusting what curl_multi_fdset() returns (if we
want want to deliver received data we don't expose a file descriptor that may
have data available for reading), and by making sure curl_multi_timeout() [*]
is implemented (so that we can ask the app not to call us again until a given
time period has elapsed), we should be able to do right.

This was written off the top of my head. I might've missed something, but I'm
sure you'll point out my mistakes if so! ;-)

[*] = curl_multi_timeout() is a suggested additon to the libcurl API,
       currently described as part of the multi improvement document:
       http://curl.haxx.se/dev/curl_multi_socket

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html