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
