Re: [wsrm] Proposed resolution for Rel16 - Ordering and Sequencing

[Doug Bunting <Doug.Bunting@Sun.COM>]

Iwasa,

Thank you for sending this proposal again.

I remain somewhat confused by the wording.  More generally, I am unsure 
what is necessary except for the first sentence and the second paragraph 
of your text.  The remaining text would seem to duplicate information 
available elsewhere in the specification.  The document should have 
already described the semantics of the AckRequested and 
DuplicateElimination elements.  (Even more generally, I prefer text that 
describes the visible behaviour of a compliant sender or receiver rather 
than prescribes processing steps hidden within an implementation.)  By 
the way, where would this text appear?

thanx,
	doug

On 26-Aug-03 06:59, iwasa wrote:

> Since we have decided in the last telecon to mandate both 
> AckRequested element and DuplicateElimination element
> for Ordered delivery, I would like to propose the same 
> resolution I sent out before as follows:
> 
> --
> 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.
> --
> 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.
> 
> 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.
> 
> 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,
>     and waste the message.
> 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.
> 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.
> 5. The receiver MUST remove the message if it was duplicating
>     at #3 above.
> 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.
> --
> 
> 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.php
> 

-- 
SunNetwork 2003 Conference and Pavilion
"An unparalleled event in network computing! Make the net work for you!"

WHEN:  September 16-18, 2003
WHERE: Moscone Center, San Francisco

For more information or to register for the conference, please visit:
http://www.sun.com/sunnetwork