Fwd: message ordering

[John Fuller <jfuller@wernervas.com>]

>

An even stricter requirement than definition 2 would be to only pass
the whole group on
after all messages have been received for the group:  the group would
be all or nothing,
like a transaction, and the RMP would be responsible.
Admittedly, by definition 2, the application layer could just go off
the "end" event since messages are ordered, but a stricter requirement
would hide the coordination all-together from the application layer....


> On Monday, September 8, 2003, at 11:15 PM, 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=20
>> "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)=20
>> that address different ordering requirts. Roughly:
>>
>> -=A0=A0=A0=A0=A0=A0 "message ordering" (o1): loosing some messages =
> will not=20
>> "break" a sequence, provided that what is passed to the receiver=20
>> application is still ordered. We can imagine that a flow of 
>> messages=20=
>
>> from a monitoring device could just need that.
>>
>> -=A0=A0=A0=A0=A0=A0 "consecutive message ordering" (o2) a missing =
> message is not=20
>> allowed in the delivered sequence. A message that cannot be waited 
>> for=20=
>
>> any longer, should break the sequence, and subsequent messages not 
>> be=20=
>
>> passed to the app (so this enforces passing only consecutively 
>> ordered=20=
>
>> sequences).
>>
>> The spec seems to endorse either o1 (section 2.4) or o2 (section=20
>> 3.3.2). Instead, it should clearly define these two variants.
>>
>> Definition 1: (message ordering, o1 above):
>> When "message ordering" is required, an=A0 RMP implementation that 
>> is=20=
>
>> required to do "message ordering" , MUST NOT make any two received=20
>> messages available to the application in a different order than 
>> their=20=
>
>> sending order.
>>
>> Definition 2: (consecutive message ordering, o2 above):
>> When "consecutive message ordering" is required, an RMP 
>> implementation=20=
>
>> MUST enforce "message ordering", and in addition MUST NOT make a=20
>> received message available to the application if its was sent after=20
>> another message that is not yet available to the application.
>>
>> Depending on which variant is used, o1 or o2, either one or the 
>> other=20=
>
>> of the current options (b)and (a) respectively
>> =A0in Rel 57 will apply.
>> The decision when to decide to "not wait anymore", remains to be=20
>> decided (TimeToLive of the first unordered message? The min of=20
>> TimeToLives of all unordered messages? Or a max unordered window 
>> size=20=
>
>> parameter, related to Rel 56.)
>>
>> -------------------------------- meeting minutes 9.5:
>>
>> "...The text is currently unclear on whether sequenceNO other than 
>> 0=20=
>
>> can be used without ordering. The general consensus is no."
>>
>> Issue: restricting the use of sequence numbers to the message 
>> ordering=20=
>
>> feature alone - and enforcing one message
>> per groupId otherwise, with seq nbr equal to 0 - will preclude=20
>> implementations from using of a whole set of fast and 
>> space-efficient=20=
>
>> algorithms for duplicate elimination.
>>
>> Proposal: Do not preclude using sequence numbers for other purpose=20
>> than message ordering, at least until some conclusive results have=20
>> been obtained on testing duplicate elimination algorithms. The spec=20
>> 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=20=
>
>> a sequence number in a message (should order? Should not?), that is=20
>> another problem that could be solved separately.
>>
>