Implementation of the restart Timer - PPP

This is a discussion on Implementation of the restart Timer - PPP ; When exactly is the restart timer supposed to start, on initialization
?. In other words, when a PPP Stack initializes, does it initialize and
start its restart timer(s), which then go off every n time intervals
reguardless of the current ...

Implementation of the restart Timer

When exactly is the restart timer supposed to start, on initialization
?. In other words, when a PPP Stack initializes, does it initialize and
start its restart timer(s), which then go off every n time intervals
reguardless of the current state. And then the state machines control
what it does by resetting/zeroing the various counts ?

or

Is the restart timer started by specific actions in the state machine
(i.e. Zero/irc)

My first impression after reading the RFC is the former, but wanted to
check

Thanks

-Chris

Re: Implementation of the restart Timer

"Chris" writes:
> When exactly is the restart timer supposed to start, on initialization
> ?. In other words, when a PPP Stack initializes, does it initialize and
> start its restart timer(s), which then go off every n time intervals
> reguardless of the current state. And then the state machines control
> what it does by resetting/zeroing the various counts ?

RFC 1661 is fairly clear about when the Restart timer runs and when it
does not:

The states in which the Restart timer is running are identifiable by
the presence of TO events. Only the Send-Configure-Request, Send-
Terminate-Request and Zero-Restart-Count actions start or re-start
the Restart timer. The Restart timer is stopped when transitioning
from any state where the timer is running to a state where the timer
is not running.

As an internal implementation issue, you can obviously do whatever you
want, so long as the behavior and bits on the wire conform to the
expectations of the standards. The standards intentionally don't
dictate anything about internal design matters. Personally, I would
likely not just have one global timer for all of the state machines,
as sending coordinated bursts of messages is likely to trigger bugs in
other implementations. But, again, it's just a quality of
implementation issue.