1d244bafbd
To avoid some unusual edge cases where too much retrying could result in far more data transfer than makes sense.
29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
The forwardRetry RetryDecider keeps retrying a transfer as long as at least
|
|
one more byte got transferred than in the previous, failed try.
|
|
|
|
Suppose that a transfer was restarting from the beginning each time, and it
|
|
just so happened that each try got a tiny little bit further before
|
|
failing. Then transferring an `N` byte object could result in `sum [1..N]`
|
|
bytes being sent. Worst case. (Real world it involves the size of chunks
|
|
sent in a failing operation, so probably `sum [1..N/1024]` or so.)
|
|
|
|
So I think forwardRetry should cap after some amount of automatic retrying.
|
|
Ie, it could give up after 5 retries. --[[Joey]]
|
|
|
|
Of course, the real use case for forwardRetry is remotes that use eg, rsync
|
|
and can really resume at the last byte. But, forwardRetry can't tell
|
|
if a remote is doing that (unless some timing heuristics were used). Around
|
|
5 retries seems fairly reasonable for that case too, it would be unlikely
|
|
for a rsync transfer to keep failing so many times while still making
|
|
forward progess. --[[Joey]]
|
|
|
|
> Or could add data to remotes about this, but it would need to be added
|
|
> for external special remotes too, and this does not really seem worth the
|
|
> complication.
|
|
>
|
|
> I think, even if a remote does not support resuming like
|
|
> rsync, it makes sense to retry a few failed transfers if it's getting
|
|
> closer to success each time, because forward progress suggests whatever
|
|
> made it fail is becoming less of a problem.
|
|
|
|
[[done]] --[[Joey]]
|