[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a proposal
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]