[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: message ordering
> 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. >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]