[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] State Tables - First June 27 version
Doug. It was very hard for me to make the state
table reflect the text that I found and not what I thought the protocol should
do. I made a distinction between blank which I
thought to be unspecified or invalid behavior, and N/A which is internal
behavior inconsistent in the given state. The state table is not a general
state table for a machine capable of processing wsrm messages, but rather it is
a state table that describes behavior with respect to the lifetime of a
sequence. N/A in general represents combinations that I thought to be
impossible or self inconsistent. An example of this is the Create
Sequence event from an unspecified motivator that starts the ball
rolling. Perhaps in incorrect implementation of an RMS might have this
event occur to a sequence that already exists, but it is not an event that has
any external appearance on the wire and thus has meaning to the RMS state table
only while in the None state. To illustrate this distinction take the
case of receipt of a CSR while in the None state. In the None state,
there is no knowledge of the sequence, it does not yet exist, thus I chose to apply
the unknown sequence fault due to its description in Section 4.3, unless
message in its context has some sort of special meaning. In the closed
state, the sequence is known, but there is no text I can find that expresses
what should be done. Perhaps, since this might be an unrecoverable state
or protocol error, a Sequence Terminated fault as described in Sec 4.2 might be
appropriate, but the definition of protocol error exists in only its plain
reading but does not otherwise what messages received at what time constitute
such an error. The CreateSequenceRefused fault’s
reception while in the none state was a close call. Note that I specified
that the fault is dropped with a reference of unspecified which roughly means
that I made it up (my bad). Strictly speaking, I am not sure that the
CSRefused fault contains a sequence identifier or not since its detail element
is only defined as xs:any, so I could not make up my mind if it was targeted to
a sequence or not (*maybe there is a new issue here*). If it is not sequence targeted, then in
the none state it could by N/A, but since it is a potential message from the
other side of the wire it could be a sequence Terminated fault. My error
was not leaving this cell as blank since I don’t this the spec says what
should happen here. One problem for me as I worked to
construct these tables is that we are not very good at making the distinction
of generating a fault and transmitting a fault message. Many of these
ought to be transmitted as fault messages since efficient state recovery
depends to some degree on these fault messages to be used as signals from one
side of the wire to the other. I opened an issue for more precise
statements of source and action for each fault partially due to this lack of
clarity. Perhaps there ought to be a flavor or two of faults that might
be generated but not transmitted for local purposes that can be used for such
circumstances. -For Send message in the rollover state the
spec does not specify when message rollover occurs precisely. That is why there
a Reached max msg number internally sourced event. I imagined that if the
RMS was in rollover state for whatever reason, the sequence was going to have
to wind down. We know that the transfer of some prior message was faulted
by the RMD or that the RMS itself determined that the message about to be sent
generated a MessageNumber too high. Anyway, I did not include a section
reference here since there is none describing this situation. We also do
not have a fault that is used to convey such a situation. Perhaps I
should have left this cell blank too and not attempted to make an unreferenced
guess about correct operation. The fix for this cell is to make some text
somewhere state what it should do or to point me to where I missed it which is
a distinct possibility. -Close Sequence event. The motivator
for close sequence is not specified; indeed it is an optional concept as
indicated by its MAY language from whence I derived its definition. I
think that you caught an error of mine. The cells should be N/A in Closed and
Terminated. I agree that is something that I should fix. I have
some difficulty with this event in the connecting state, since it is
conceivable that the RMS might to close the sequence at any time and indeed
that includes the connecting state where the RMS has not yet created the
sequence (since it is not created until the CSR is successfully processed and
the Sequence ID in known. I think that No Action [None] might be applied
here although it might leave an orphaned sequence for the RMD to clean up some
day. As for CloseSequence re-transmissions, there is nothing that
describes re-transmissions in any specific way. I don’t think it
should be the re-triggering of the close sequence event. I suspect that
especially dur to the new polling stuff that I might enjoy construction a “MEP”
engine that might operate underneath the Sequence State machine to handle
re-transmission and polling. Re-transmission behavior probably should be moved
entirely to that new state table when we decide it is warranted. -Terminate Sequence[int] none state:
You there is a problem with this row Should be N/A | No Action[none] | STET
| STET | STET | N/A In the connecting state although the RMS
may have sent a sequenceID, the RMS has not yet processed it. It is a
valid condition, but the correct next state is None with no action since there
is no sequence yet to terminate. Spec text might be tightened here.
Can you suggest where? * Perhaps some words that define Sequence Lifetime ought
to be included in Sec 3.4*. -TernSeqRed event well in the None and
Connecting State I guess it ought to be the unknown seq fault I will fix
In the other states other than Terminating I left it blank since the behavior
is unspecified as far as I can determine. Perhaps this is a good use of
SequenceTerminated fault transmission to the RMS. -Expires: you are correct, but the spec doesn’t
say. I opened an issue on this one The last row is an event raised by the
receipt of an invalid acknowledgment range (see section 4.4) Its tribber
is the receipt of any ack range that is invalid RMD -CloseSeq message, I disagree, according
to sec 4.7, the attempt to close a sequence that is already closed results in
this fault. -Expires: Yup, where does the spec say
what it should do? (issue proposed on this one) -Non-RM message: you are correct, I will
fix Thanks for reviewing -bob From: Doug Davis
[mailto:dug@us.ibm.com]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]