[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
Ooops, backtrack this: something is
missing in your proposal Doug, that I didn't catch before: -
remember
this is the issue where termination is on sequence Fault from RMD side: the RMS
does not even get a chance to do some closing. -
So I
think we should also give all Sequence Faults a "closing"
semantics, rather than an actual "termination" semantics. When
getting the Fault, the RMS knows the sequence has closed, but can still send a "close"
op to get a final Ack. Then it would have to Terminate the sequence (unless it
lets inactivity or expiration time kick-in). -
Your
proposal seems to be more appropriate for the twin issue - reworded Proposed-01
-, where RMS just wants the final tab after deciding to not use the sequence
anymore, regardless of gaps and regardless of termination process (expiration,
inactivity, or TerminateSequence if allowed here) Jacques From: Doug: Overall that seems to do the trick. More Inline <JD> A related comment: -
the use
of LastMessage marker appears now like a subcase of closing, where the RMD will
close if (1) LastMessage was received, (2) all messages before were received. -
After we
are done with i019, I think we should reconsider how useful LastMessage is (I
guess a separate issue). My expectation here is to keep the protocol simple. At
least, I would like i019 and your proposal to NOT be perceived as making the
protocol more complex... as I believe it makes it possible to trade one feature
("LastMessage") for another ("Close"). Cheers, Jacques From: Doug Davis
[mailto:dug@us.ibm.com]
<JD> I thought TerminateSequence can't be sent out unless RMS get all
messages acknowledged ? (hey, I am not the only one reading the spec in a
"lax" way !! ;-) However, if message #3 is just slow, and arrives at
the RMD after the sending of the Terminate but before it arrives then the RMD's
sequence state will differ from the RMS's. Sending a final Ack back to
the RMS might not be sufficient since that might be lost as well. <JD> In fact, the termination case
for i019 is more of a SequenceFault that, at the time it occurs on RMD, leaves
the RMS without an idea whether some missing messages were received since it
got its last SequenceAck. But the solution is the same.
<JD> semantics of Close is: sequence
will reject any future message (in effect freezing its state) except
"operation" messages such as Close and TerminateSequence, to which it
should respond as appropriate.
<JD> if the Closed is always
accompanied by the SeqAck, then this Ack can be considered as final
("Final" marker is only cosmetic). If this message (or the Close)
is lost the RMS is free to send it over and over until it gets an Ack+Final
since processing multiple ones has no negative impact. Upon receipt of
the Ack+Final the RMS can then safely send a TerminateSequence without fear of
any new messages arriving and changing its perception of the gaps in the
sequence. <JD> that means we change the rule
of usage for TerminateSequence too.
<JD> I'm OK with this. -Jacques
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]