Re: [wsrm] about ordering

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

Jacques,

The rest of this thread seems to be extending the options rather than 
addressing the questions you raise so I will start back here.

I do not believe this proposal aligns with the decisions this group has 
already made on REL-16 and adds requirements not presently in our 
Requirements document.  In a number of previous discussions, we chose 
*not* to cover the monitoring (ordered but not guaranteed delivery) use 
case.  This proposal appears to head toward reopening those earlier 
decisions.

thanx,
	doug

On 08-Sep-03 21:15, Jacques Durand wrote:

> I propose the following (partial) answer for Rel 57, see below,
> and also after this, see my concern on the way we seem to tie the 
> "ordering" vs "no ordering" decision
> to the seq number value (section 9.5 in the meeting minutes)
> 
> Regards,
> 
> jacques
> 
> *Rel 57:*
> 
> *Proposal*: Message ordering has actually two variants (o1) and (o2) 
> that address different ordering requirts. Roughly:
> 
>       -       "message ordering" (o1): loosing some messages will not
>       "break" a sequence, provided that what is passed to the receiver
>       application is still ordered. We can imagine that a flow of
>       messages from a monitoring device could just need that.
> 
>       -       "consecutive message ordering" (o2) a missing message is
>       not allowed in the delivered sequence. A message that cannot be
>       waited for any longer, should break the sequence, and subsequent
>       messages not be passed to the app (so this enforces passing only
>       consecutively ordered sequences).
> 
> The spec seems to endorse either o1 (section 2.4) or o2 (section 3.3.2). 
> Instead, it should clearly define these two variants.
> 
> *Definition 1*: (message ordering, o1 above):
> When "message ordering" is required, an  RMP implementation that is 
> required to do "message ordering" , MUST NOT make any two received 
> messages available to the application in a different order than their 
> sending order.
> 
> *Definition 2*: (consecutive message ordering, o2 above):
> When "consecutive message ordering" is required, an RMP implementation 
> MUST enforce "message ordering", and in addition MUST NOT make a 
> received message available to the application if its was sent after 
> another message that is not yet available to the application.
> 
> Depending on which variant is used, o1 or o2, either one or the other of 
> the current options (b)and (a) respectively
>  in Rel 57 will apply.
> The decision when to decide to "not wait anymore", remains to be decided 
> (TimeToLive of the first unordered message? The min of TimeToLives of 
> all unordered messages? Or a max unordered window size parameter, 
> related to Rel 56.)
> 
> -------------------------------- meeting minutes 9.5:
> 
> "...The text is currently unclear on whether sequenceNO other than 0 can 
> be used without ordering. The general consensus is no."
> 
> *Issue*: restricting the use of sequence numbers to the message ordering 
> feature alone - and enforcing one message
> per groupId otherwise, with seq nbr equal to 0 - will preclude 
> implementations from using of a whole set of fast and space-efficient 
> algorithms for duplicate elimination.
> 
> *Proposal*: Do not preclude using sequence numbers for other purpose 
> than message ordering, at least until some conclusive results have been 
> obtained on testing duplicate elimination algorithms. The spec should 
> only require
> 
> that (groupId + seq.nbr) be always unique.
> If the concern is about how to instruct an RMP what to do when it sees a 
> sequence number in a message (should order? Should not?), that is 
> another problem that could be solved separately.
> 
> If we resort to such tricks as using a different groupId for each 
> message that does not require ordering, this amounts to enforcing 
> duplicate check algorithms that are based on unique messageId strings. 
> This will lead to more costly duplicate check (less scalable and less 
> performant) and to the use of two different algorithms, if we still want 
> to use sequence number-based duplicate check for ordered sequence that 
> also need exactly once delivery.
> 

-- 
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