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"
!
-
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.
