On Tue, Apr 24, 2007 at 10:57:13AM +0300, Alper Yegin wrote: > > > 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.
The issue I am trying to bring is complexity of maintaining two state machines and still follow the "one outstanding request at a time" rule. I am actually faced with this issue while I am revising pana-statemachine draft. > > > > 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. When we preserve "lock-step", then it means we can't run two state machines independently, right? This is very similar to multi-thread programming using semaphore to access critical resource (i.s., one outstanding request issued by the same peer) to which only one thread can access at a time. This constraint is basically coming from using the same sequence number space for ping and other messages. I am just thinking that implementations can be much simpler if we have separate sequence number space for ping in order to run ping state machine independently of non-ping state machine. Yoshihiro Ohba > > 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
