limit-rate revisited

Tweaks around handling of --limit-rate:

* tracing: trace outstanding timeouts by name
* multi: do not mark transfer as dirty that have
  an EXPIRE_TOOFAST set
* multi: have one static function to asses speed limits
* multi: when setting EXPIRE_TOOFAST remove the transfers
  from the dirty set
* progress: rename vars and comment on how speed limit
  timeouts are calculated, for clarity
* transfer: when speed limiting, exit the receive loop
  after a quarter of the limit has been received, not
  on the first chunk received.
* cf-ip-happy.c: clear EXPIRE_HAPPY_EYEBALLS on connect
* scorecard: add --limit-rate parameter to test with
  speed limits in effect
This commit is contained in:
Stefan Eissing 2025-09-02 15:16:21 +02:00
parent ad42850b23
commit c5fccfffc6
No known key found for this signature in database
10 changed files with 218 additions and 120 deletions

View file

@ -582,17 +582,16 @@ class CurlClient:
with_profile: bool = False,
with_tcpdump: bool = False,
no_save: bool = False,
limit_rate: Optional[str] = None,
extra_args: Optional[List[str]] = None):
if extra_args is None:
extra_args = []
if no_save:
extra_args.extend([
'--out-null',
])
extra_args.extend(['--out-null'])
else:
extra_args.extend([
'-o', 'download_#1.data',
])
extra_args.extend(['-o', 'download_#1.data'])
if limit_rate:
extra_args.extend(['--limit-rate', limit_rate])
# remove any existing ones
for i in range(100):
self._rmf(self.download_file(i))