On lör, 2007-09-15 at 21:25 +0200, Francisco Gimeno wrote:
> I was wondering if it would be too difficult to implement and acl
> method for matching big files.
Problem is knowing..
> I want then to use it with delay_pools. I think there are two
> different approaches:
> - Matching Content-Length value: the problem is that some objects
> don't include that HTTP header.
Yes..
most downloads do have Content-Length however..
> - Using internal counters on request: the problem is that the request
> object is created and I don't know if it could be reinserted in a
> delay_pool. I don't know where should I put the matching code (but it
> seems the right place has to be in the read object content function.
Currently delay pools is assigned before the request is forwarded. But I
guess it should be possible to reassign delay pools while the request is
running somehow..
> The idea is then, restricting the bandwidth of big files (let say more
> than 1Mbytes) and promoting the interactive (little objects) to have
> more bandwidth available.
Or you could just ignore size, and promote reasonable but bursty use.
This is what delay pools was designed for and why there is both a pool
size and a refill rate.. the pool size allows for bursts of traffic
without getting delayed, making the delay pool only kick in if the user
uses his allocated bandwidth for a longer period.. one can view it as a
sliding average, and as long as the average bandwidth use is below the
limit there is no delay. Works quite well, and can not be bypassed by
using download managers that split the download in many small parts...
Regards
Henrik
This archive was generated by hypermail pre-2.1.9 : Mon Oct 01 2007 - 12:00:05 MDT