On Fri, 3 Aug 2012, Miguel Parra wrote:

> On real time applications it will be ideal if we could make sure transfers
> go smoothly and processing proportionate chunks of data.

I wouldn't mind having more exact speed control. This said, you must remember
that a small overrun or bursty function calls etc are not very important, as
the underlying TCP stack will not work fully synchronously with our calls and
it will even out a lot. Also, the max speed is meant to be the max speed as an
average over a certain time.

> I'm suggesting adding a Curl_pgrsUpdate() to update the download speed, then
> checking if we are over our speed and if so break the loop.

At first glance, that looks like a fair idea. But...

That function is a no-op for many protocols. So if you don't use SCP, SFTP or
an SSL-based protocol (using a certain set of SSL libraries) it won't have any
effect for you.

When SSL/SSH libraries are used to read data (such as OpenSSL or libssh2) we
must not abort it like that since the data was already read off the socket so
if we don't read it now, we can't just wait for activity on the socket to read
again as the data is now living in a buffer within the library... If you'd add
that break, you would also have to introduce a completely new level of logic
for that.

So, I would not recommend this.

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