id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
30	add Reconnector.reset()	Brian Warner		"It would be handy if the Reconnector instances offered a 'reset()' method.
This method should:

 * lower {{{self._delay}}} down to {{{self.initialDelay}}}
 * accelerate the expiration of any timer currently running (by doing
   {{{self._timer.reset(1.0)}}}

The use case is a Foolscap-using client on a laptop, which gets suspended,
then resumed on an airplane without network connectivity for a while, then
suspended again, then resumed with a real network connection. The goal is to
accelerate the resumption of connectivity once the client is back on the net.

When the client wakes up the first time (on the plane), the banana-level
keepalive timer will fire right away (since a long time has passed since it
saw any traffic), which will cause the connection to be dropped. This will
trigger the Reconnector to reconnect, but since there's no network on the
plane, it will soon ratchet up to the maximum retry delay (one hour). When
the laptop gets suspended again, it will somewhere in the middle of this one
hour cycle.

Then, when it gets resumed again, the Reconnector's one-hour timer will fire
immediately, probably before DHCP has had a chance to establish a new network
configuration, which means the connection attempt will fail, and the
Reconnector will schedule the next connection for an hour later.

An application which discovers the suspend/resume cycle (perhaps by
scheduling one-minute timers and noticing when they expire much later than
expected, or by some operating-system-specific means like D-BUS or COM or
something) can poke all the Reconnectors that it's using by calling their
reset() methods. It can do this as soon as it discovers the time-jump, which
will trigger an immediate reconnect attempt (which will probably fail) and
then try again using the normal exponential-backoff behavior, resulting in a
new connection perhaps 10-60 seconds after the laptop is resumed.

Alternately, the application can pay close attention to the network
configuration (again using some OS-specific mechanism) and refrain from
calling .reset() until the network is back up. With this approach, the
Foolscap connection should be successfully established immediately after
reset() is called.

"	enhancement	closed	major	0.2.0	usability	0.1.7	fixed	reconnector