Re: [wsrm] about ordering

Jacques,

Jacques Durand wrote:
 Sunil,the
decision "delayed vs lost" you point at is indeed essential to (o1), although
the reason I would drop (o1) definition and keep (o2) - if we have to settle
on only one -is
more due to the logic of Ack + ordering (all messages are expected to be
received + ordered )Note
however that (o2) will also face the decision "delayed vs lost"  !

Yes, it does.
But the difference is that in the (o2) case it's inefficiency issue,

where as
in the (o1) case it's a compliance issue.

In the (o2),
as you correctly pointed out, we keep pilling up the messages

which is
inefficient but still legal & compliant. Which is not the case with

with (o1).

We need to
have a global default for msg. expire time-out to be more

efficient
in the (o2) case.

 

-Sunil

 

 

 

 

 

 

 

 

 

 

 

 

 -
message #2 is "late", we have passed #1 to the app, and keep piling up 
#3, 4,5... -
when do we decide that it is not worth waiting anymore for #2? Even with
"guaranteed delivery"a
particular message may never go through (e.g. too big...).-
from then the main difference with (o1) is that we won't pass anything
more from this sequence to the app (3,4,5 are lost)while
in (o1) we would pass them in the right order. Some
decision criterion still needs be supported... even though more unlikely
to be used, thanks to resending.Jacques

-----Original
Message-----

From: Sunil Kunisetty [mailto:]

Sent: Friday, September 12,
2003 11:15 AM

To: Jacques Durand

Cc: ''

Subject: Re: [wsrm] about
ordering

 

 Jacques,

 How does a Receiver distinguish a 'lost' message to a 'delayed'
message? In other

 words, how does a Receiver assume that the message is 'lost'
and not 'delayed'?

 Sender may have sent msgs. 1,2, & 3 in that order.  Msg.
2 was 'delayed' and

 somehow 3 shows up much before 2. Receiver may have assumed that
2 was

 'lost' and could have delivered 3 to the application. And then
2 arrives and

 assuming that it doesn't expire, what does the Receiver do with
then?

 Since we don't have a global default for msg. expire time as of
now and there

 is no explicit msg. lost header/token (from Sender to receiver),
we can't easily

 distinguish a lost message to a delayed message. Because of this
it will be very

 difficult to implement the "message ordering" (o1).

 Thanks,

 -Sunil

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.