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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
