Hi, On Thu, Jun 23, 2016 at 02:42:18PM -0400, Selva Nair wrote: > > So, now we have 4 different remotes. You're scaling the exponent by 1/4 > > here, so the retry timer would be > > > > 5s 5s 5s 5s 10s 10s 10s 10s 20s 20s 20s 20s ... > > > > then (or, phrased differently, "one round uses the unscaled timer, the > > next round across all remotes uses 2^1, the third round uses 2^2"). > > > > > > If I understood the math right, I think this would be useful behaviour ;-) > > - fast failover if multiple remotes are there, exponentially slowing down > > if all remotes have been tried. Plus, fairly easy to implement as nearly > > all needed values are already around. > > > Yes, the book-keeping variables are already there. > > To avoid aggressive slowing down, may be we could start the scaling after > rc has reached a threshold. Say don't do anything until rc = 5 and then > start scaling the timer until rc reaches 15.
I think that is a good addition to the original plan - a server might have
a hickup for other reasons than pull-reject (maybe just restarting due to
upgrades, whatever), and trying "a few times in quick sequence" before
going into backoff should help in these cases.
Go for it :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
