molybtek wrote:
Chris Robertson-2 wrote:
This is getting a bit off the path of your original question, but...
Have you changed quick_abort_min, quick_abort_max or quick_abort_pct?
How about read_ahead_gap?
Delay pools should not download from the 'net faster than the data is
delivered
Chris Robertson-2 wrote:
molybtek wrote:
Chris Robertson-2 wrote:
This is getting a bit off the path of your original question, but...
Have you changed quick_abort_min, quick_abort_max or quick_abort_pct?
How about read_ahead_gap?
Delay pools should not download from the 'net
molybtek wrote:
Chris Robertson-2 wrote:
molybtek wrote:
Chris Robertson-2 wrote:
This is getting a bit off the path of your original question, but...
Have you changed quick_abort_min, quick_abort_max or quick_abort_pct?
How about read_ahead_gap?
Delay pools should not download from
molybtek wrote:
muhammad panji wrote:
molybtek wrote:
I'm trying to limit download accelerators making multiple connections,
the only reliable way I could think of to identify them is their use of
the Range header. However, if I block all range requests, then that would
stop even
Chris Robertson-2 wrote:
This is getting a bit off the path of your original question, but...
Have you changed quick_abort_min, quick_abort_max or quick_abort_pct?
How about read_ahead_gap?
Delay pools should not download from the 'net faster than the data is
delivered to the
I'm trying to limit download accelerators making multiple connections, the
only reliable way I could think of to identify them is their use of the
Range header. However, if I block all range requests, then that would stop
even legitimate partial downloads. So I was thinking of using maxconn as
muhammad panji wrote:
molybtek wrote:
I'm trying to limit download accelerators making multiple connections,
the only reliable way I could think of to identify them is their use of
the Range header. However, if I block all range requests, then that would
stop even legitimate partial
