[Twisted-Python] spread.sturdy reconnect delay

Donovan Baarda abo at minkirri.apana.org.au
Sun Aug 4 18:18:12 EDT 2002


On Sat, Aug 03, 2002 at 02:55:33AM +0200, Paul Boehm wrote:
> currently, when spread.sturdy is unable to (re)connect (e.g. because the
> connection was refused/server not running), it retries at full
> speed.. without any delay.. 
> 
> implementing some kind of rate limiting is trivial, but i'm not sure about
> the right approach. the issue is current for me, as i'm using sturdy in
> my application and wouldn't want it to flood the network too much.
> 
> i've come up with the following approaches:
>   *) try n times, then wait i seconds, rinse, repeat
>   *) try, sleep i, try, sleep i, ...
>   *) try, sleep i++, try, sleep i++, ..

What about exponential backoff...

    *) try, sleep i, i=i*2, repeat

the i can grow very large very quickly. This approaches the heuristic of "it
has been down for total of x seconds and it's still not up, so I'll wait x
seconds more before trying again". ie assume the last failed attempt was in
the middle of the total down time.  

A more explicit version of this with a tuneable factor would be;
   total=1
   try, i=f*total, sleep i, total+=i, repeat
   
or, taking into account the time taken trying;
   start=time()
   try, i=f*(time()-start), sleep i, repeat

where 0<f (usually f<1), and indicates you should wait f fraction of the
total time already waited. ie setting f=0.1 indicates you should wait 10% of
the total time already waited.

-- 
----------------------------------------------------------------------
ABO: finger abo at minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------




More information about the Twisted-Python mailing list