RE: [ws-rx] i144 - Editorial (maybe) RMS MessageNumberRolloverbehavior unclear

Doug,

Comments in line:

-bob

 

From: Doug Davis
[mailto:] 

Sent: Wednesday, July 05, 2006
10:33 AM

To: 

Subject: [ws-rx] i144 - Editorial
(maybe) RMS MessageNumberRollover behavior unclear

 

http://lists.oasis-open.org/archives/ws-rx/200606/msg00212.html

Bob,

 
Just to get the discussion going on this (again), I would prefer to close this
with no action.  Your two questions: 

1)
It is unclear under what circumstances the RM Source generates a
MessageNumberRollover fault 

2)
Assuming that the RM Destination Transmits a MessageNumberRollover fault upon
receipt of a message with a MessageNumber that exceeds its internal limitations
or the big number cited, whichever happens first, what mechanism is used by the
RM Source to close or terminate the sequence? 

Are
either already covered in the spec or are implementation choices/details that
the spec should not dictate. 

For
(1) the RMS may choose to generate this if the AS asks to use a msg# that is
too big.  But this is not something the spec can (or should) have any say
over.  This is not something that would appear on the wire and is an issue
between the AS and the RMS.  I would point out that in the case of the AS
trying to use a msg # that is too big (if the RMS allows the AS this choice at
all), could result in some other fault too.  Since the RM spec deals with
just faults related to the RM protocol, and this fault is not necessarily an RM
protocol fault, there is no reason to mandate a specific fault for this
condition. 

 

No, this fault when generated by the RM
Source is not likely a wire level event, but the spec says (June 27 version of
WD 15) on line 583 that the “RM Source or Destination MUST generate a
MessageNumberRollover fault”.  Should that text be changed to
reflect your assertion?

If your (1) was related to whether or not an RMS passes
a MsgNumRollover fault that it received from the RMD back up to the AS (so it
is in essence generating a MsgNumRollover fault on behalf of the RMD) then
again this is an impl detail.  The RMS may choose to never expose this
fault to the AS - we can't say. 

 

No, this is not my interpretation; I am
just trying to apply what the spec text says as it relates to the construction
of the state tables.  To support the behavior as stated in the paragraph
cited above, I assumed the need for this event (at either RMD or RMS) required
some sort of state change that would permit the retransmission of unacknowledged
messages while preventing the acceptance of new messages for
transmission.  This is the only difference between the connected and the
rollover state.  If this state is omitted, then the RMS would continue to
fire new messages at the RMD.  The state is there since this behavior is
sort of implied by the last sentence of that paragraph.

For (2) - why do you assume that the RMS should close
or terminate the sequence?  There are other choices - like start a new
sequence for that msg. 

 

That would not be prohibited on a new Sequence;
but the old sequence is not useful for the transfer of any new messages. 
I guess that there is always either expiry or the RMS’s knowledge that all
transferred messages have been acknowledged.  I added the closure option
since the spec says in sec 3.2 that either the RMS or RMD MAY close a sequence
before terminating it.  Terminating the sequence would be the humane thing
to do once all messages have been acked or closure then termination
otherwise.  I would hate to leave a rolled over sequence languishing and
suffering in the RMD.

 

thanks 

-Doug