2020-09-01 20:00:49 +00:00
|
|
|
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]`
|
2020-09-04 16:46:37 +00:00
|
|
|
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.)
|
2020-09-01 20:00:49 +00:00
|
|
|
|
|
|
|
|
So I think forwardRetry should cap after some amount of automatic retrying.
|
|
|
|
|
Ie, it could give up after 5 retries. --[[Joey]]
|
2020-09-01 20:04:40 +00:00
|
|
|
|
|
|
|
|
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]]
|
2020-09-04 16:46:37 +00:00
|
|
|
|
|
|
|
|
> 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]]
|
