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.
