> > Do the sequence numbers play a role our state machines? I hadn't thought > so. > > The play is implicit based on the following lock-step constrations: > > - Each peer maintains a single sequence number space for outgoing > requests. > > - There is only one outstanding outgoing request allowed for each > peer. A peer that receives a request accepts the sequence number > which is last received sequence number + 1 only.
Both of these rules are still maintained whether we have two state machines or one. Do we change anything? As long as we stick to "one outstanding request at a time" rule, these rules shall apply as they are. > This means sequence numbers play a role in our state machine. Running > multiple state machines in pararell and independenly would break the > lock-step constraints. In my understanding, "lock-step" is about "not having two outstanding requests issued by the same peer." Based on that, I'd say the lock-step nature is preserved. The sequence number processing on incoming messages are done for validation. Invalid messages are tossed away, valid ones are processed by the state machine. I don't think we'd have a statement in our state machine specification that uses the "sequence number" as an input and change the way state machine runs. What do you think? Alper > > Yoshihiro Ohba > > > > > > > Alper > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > This scheme prevents any special case handling to be part of the > > > protocol > > > > specification. > > > > > > > > Your suggestion below works too I believe. Though I lean towards the > > > above > > > > suggestion, given that it does not special case one type of message > in > > > the > > > > spec. > > > > > > > > I remember once mentioning use of a separate state machine for > pings. I > > > > don't remember what the feedback was.... > > > > > > > > Alper > > > > > > > > > > > > > which will end up with the 2*N > > > > > problem. On the other hand, it may be possible for the PaC to > queue > > > > > the incoming PAR until the ping request is answered. > > > > > > > > > > So how about relaxing the third item to: > > > > > > > > > > " > > > > > - When there is an outstanding ping request, all incoming messages > > > > > MUST NOT be processed except for ping answer or error request > sent > > > > > in response to the ping request. > > > > > " > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This may be an acceptable operation. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > [email protected] > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
