On Wed, 29 May 2002, Rich Gray wrote:

> The biggest problem with this algorithm, is that if the writes get stalled
> for any period of time, it will try to make up for lost headway by running
> wide open until it is back on the bytes per second slope which originates
> from the start of the run.

*Ugh*. Right. That was a "slightly" naive approach to the problem. Thanks for
correcting me.

> Something with a shorter timeframe (sliding window) might be better.
> Below is an off the top of my head, rough, untested example of how one
> might hack an inner write function to literally limit the release of data
> to some number of bytes per second. (Please excuse my mutant indenting
> style.)

Thanks. Due to conditions set by the libcurl design, we won't delay the
actual writing (nor reading), but we will make the callback (called by the
library to write or read data) wait a little before it returns back to the
library to perform.

This is so because I'm talking about an implementation of this feature
outside the actual library. Had I implemented this in the library code, the
situation would've been slightly different.

So.

For download, it means that libcurl will read a full chunk as fast as
possible and hand it over to the client code. It then has to delay the
operation so that it'll return when the "bytes/sec" limit is reached.

For upload, we can do it slightly neater as then we'll get invoked with a
callback when libcurl wants to send away data, so we can read only as much
data we believe libcurl should send during this "period", delay sufficiently
and then return.

All in all, we won't end up with single second or subsecond periods for the
throttling (at least we can't be sure to get that), but we can make sure that
we don't overstep the limits on counted on slightly longer periods.

> One other thing (which I've never messed with) might be to reduce the size
> of the tcp transmit buffer to, say, the size one intends to release in a
> given second. That would avoid carefully throttling into a large buffer in
> case of a connection stall. (When the stall goes away, all the buffered
> data is going to go at full speed.)

Yeah it would be a cool hack, but it would probably be horribly hard to make
it even somewhat portable...

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm