ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i144 - Editorial (maybe) RMS MessageNumberRollover behaviorunclear
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Wed, 5 Jul 2006 15:51:37 -0400
See more stuff in-line.
<extracting the key text>
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.
<dug> I agree with removing
"RM Source". As for what to do with the sequence...to me
its no different than any other sequence w.r.t. what the state table shows.
I understand your point that its a useless sequence, in that you've
hit the max msg #, but in terms of what the RMS does for the wire protocol
I'm not sure its in anything other than a Connected state. The fact
that the RMS may choose to not accept any more messages from the AS is
an impl detail and not part of the RM spec - in other words that interaction
is not part of the state table. </dug>
...
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?
<dug> I was using the term
"rollover sequence" to mean some 2nd sequence set up by the RMS
to continue sending messages to the RMD since the 1st sequence hit the
max msg number. This is just one option for an RMS and not in scope
for the spec. My point in bringing it up was to show that we can't
know for sure how an RMS will choose to recover from this fault. Closing
and/or Terminating is just one option - there may be others that are environment/impl
specific that I wouldn't want to preclude. </dug>
thanks,
-Doug
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/05/2006 02:34 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 |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]