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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Implementation of the restart Timer

  1. 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


  2. 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.

    There's a book that discusses implementation issues ...

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread