Re: [wsrm] about ordering

[Tom Rutt <tom@coastin.com>]

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.
>
The recommended messageID algorithm uses a sequence number along with 
date and
host address of the sender.  However this sequence number is embedded in 
a string.

Tom Rutt

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


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133