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 12:54:10 -0400
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.
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.
thanks
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]