[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Rel16 Ordering and Sequencing
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]