[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel16 Ordering and Sequencing
In the same context, why is it a MUST for an Ordered Message to have Duplicate Elimination? I believe we have to address this Resolution along with REL {50,51,52,53}. All of them are related in some way or other. -Sunil Scott Werden wrote: > Comments <scott></scott> inline.... > > > -----Original Message----- > > From: iwasa [mailto:kiwasa@jp.fujitsu.com] > > Sent: Tuesday, July 29, 2003 5:10 AM > > To: wsrm > > Cc: iwasa; iwasa.kazunori@nifty.ne.jp > > Subject: [wsrm] Rel16 Ordering and Sequencing > > > > > > Here is a proposed resolution for Rel16, > > which is my action item at last telecon. > > > > -- > > Issues: > > Description: The behavioral semantics of senders and > > receivers need to be > > further defined with regard to the tracking of sequence > > numbers for the > > purpose of detecting duplicate or out of order messages. For > > example: How > > long should a receiver hold on to out-of-sequence messages in > > anticipation > > of a missing message?" > > REL-11 proposals address some of the sequencing issue. > > REL-6 and REL-17 deal with persistance issues, but not out of sequence > > messages directly. > > [see original spec] > > -- > > > > Proposed resolution: > > Include the following description to the spec at section 2.4. > > -- > > When a sender sends multiple messages with Guranteed message ordering, > > the sender is REQUIRED to include MessageOrder element in the message. > > And all messages to be delivered in order MUST have same GroupID > > and MUST have sequence number as a value of SequenceNumber element > > in order of the message to be delivered to receiver's > > application. (Please > > refer to section 3.3.2 for SequenceNumber element.) > > > > When the sender uses Guranteed message ordering, > > the sender MUST use Guaranteed message delivery and Guranteed > > duplicate elimination together. In detail, the sender MUST > > include both > > AckRequested element and DuplicateElimination element, as well as > > the MessageOrder element for Guranteed message ordering. > > > > <scott> > Why are we requiring an ACK on ordered messages? Let's say I have a logging > application (like log4j) that simply logs all events sent to it. This is not > a critical app so if a message gets lost it is OK. But of the ones that are > successfully received, they should be kept in-order. So, no need to ACK, but > there is a need to order them. What is the behavior in this case of a > missing sequence #? Let's say the receiver receives #0,1,3. The receiver > delivers 0 and 1 to the app and hold #3 for its MET (msg expiration time), > waiting on message #2. If #2 does not show up within that time it delivers 3 > and considers 2 to be lost. > </scott> > > > A receiver that received messages including MessageOrder element > > MUST provide its application layer with those messages > > in order within the same groupID. In detail, the receiver MUST > > follow the following procedure, when it received messages > > with MessageOrder element: > > 1. Confirm the message is including AckRequested element and > > DuplicateElimination element as well as MessageOrder element. > > If there is missing eaither/both of the above two elements, > > the receiver MUST send back [TBD] Fault message to the sender, > > waste the message, and terminate this procedure. > > 2. The receiver MUST check if the message is duplicating > > with any message persisted at receiver. > > 3. The receiver MUST persist the message until PersistentDuration > > [TBD:This parameter must be defined as a configuration parameter] > > has expired, if the message is not duplicating. > > <scott> > I think the receiver must presist the message for at least the MET. If there > is a (local) "persistance duration" parameter and it wishes to persist > longer, that is implementation specific and should not be part of the wsrm > spec. > </scott> > > > 4. The receiver MUST generate and send back an Acknowledgement > > message to the sender. Note the Acknowledgement message > > MUST be sent back whether it was duplicated or not. > <scott> > See comment above on not requiring an ACK for ordered delivery. > </scott> > > 5. The receiver MUST remove the message if it was duplicating > > at #3 above, and terminate this procedure. > > <scott> > Not sure what you mean by "terminate this procedure". If you are saying that > processing of messages within the Group is discontinued, I disagree with > that. If this is not what you mean, this needs to be clarified. > </scott> > > > 6. The receiver MUST check the SequenceNumber and GroupId > > to see whether the message is arrived in order within the GroupId. > > If the message is arrived in order, the receiver MUST provide the > > message to the application layer. If the message is not arrived > > in order, the receiver MUST wait until all previous messages > > is received by receiver and provided to the application layer > > in order. > > > > In addition to the above procedure, the receiver MUST check > > messages persisted and didn't provided to the application layer > > until PersistentDuration is expired. If there are those messages, > > the receiver MUST send back [TBD] fault to sender to notify > > those messages are not delivered to the application, even if > > the Acknowledgement messages were returned before. And > > then the receiver MAY remove those messages. > > -- > > <scott> > I propose that it follow the semantics of guaranteed delivery, if that is > requested in the wsrm header (through the ACKRequested element), otherwise > it continues on silently. I believe we should have guaranteed delivery > orthogonal to ordered delivery. > </scott> > > > > > Please propose any updates to make the above > > sentences more appropriate. > > Thanks, > > > > Iwasa > > > > > > You may leave a Technical Committee at any time by visiting > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph > p > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]