[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i144 - Editorial (maybe) RMS MessageNumberRolloverbehavior unclear
Doug, Comments in line: -bob From: Doug Davis
[mailto:dug@us.ibm.com]
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?
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.
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]