More in-line
-bob
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006
12:54 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i144 -
Editorial (maybe) RMS MessageNumberRollover behavior unclear
Comments in line.
-Doug
|
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/05/2006 12:36 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [ws-rx] i144 - Editorial (maybe) RMS
MessageNumberRollover behavior unclear
|
|
Doug,
Comments in line:
-bob
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006 10:33 AM
To: ws-rx@lists.oasis-open.org
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?
Hmmm, interesting. I wonder what the original intent of
the RMS generating that Fault was for. If I'm wrong and that fault should
be used for AS->RMS interactions then the text you cite is ok but I still
think your (1) isn't an issue for the spec. If the fault isn't
necessarily mandated in the AS->RMS interactions then I think that line
should be changed. I'm currently leaning towards saying it just applies
to the RMD but if the RMS wanted to use it too then that's its own choice but I
don't think we can use "MUST" in those cases since its not dealing
with RMS->RMD interactions.
One solution is to delete the “RM
Source” in the sentence so that the fault would only be generated by the
RM Destination. That would make me happy since I think that the RMS can
deal with the AS any way it desires at the exhaustion of its ability to
represent message numbers. Presumably the RMS would then choose to close
or terminate the sequence any way it desired once outstanding acks and
retransmissions have been drained. The event remains in the RMS state
table but only as an internal event that allows for messages “Sent”
previously to be dealt with properly.
I think that it is purely derivative then
to say that upon draining of these outstanding messages the sequence SHOULD be
closed and / or terminated since it would then be useless. Terminating
with a TerminateSequence would allow state cleanup more quickly. Right
now the spec reads that retransmissions and acks may continue until the
sequence is closed or terminated. My original question was related to the
motivator for that closure or termination action.
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.
True, no more, higher numbered, messages can be transfered
but lowered ones can be - that's why I'm not comfortable saying that the
sequence should be closed or terminated - it depends on what's going on.
If there are no gaps in the sequence then it probably would be closed or
terminated but the RMS may also choose to wait until a rollover sequence is
created - we just don't know. Either way, since the original sequence is
still valid (just full) there is no reason to manadate anything happen to it.
What is a rollover sequence?
thanks
-Doug