Title: RE: [wsrm] Need to rethink semantics of duplicate elimination behaviour
Doug:
I suspect a remaining gray area in the Ack semantics and behavior:
- Given we all agree on Ack-on-delivery (meaning the message has
actually been "delivered" to the receiver app),
What you point at, is the case where:
- message was well received and well delivered.
- the Ack was sent back,
- the Ack was never received by Sender.
What you expect is:
- when duplicates for the delivered message are received,
the RMP will repeat the Ack sending, because the message
was actually previously delivered, yet the Sender does not seem to know this.
So the current spec is still unprecise as what "sending an Ack on
duplicate" means (3.2.1 line 552), since that seems to be a remnant of the old
"ack-on-receipt" semantics:
with "ack-on-delivery", we should not send an ack for a duplicate
of a message that has NOT been delivered for whatever reason.
Personally, I thought this ack of duplicate was obsolete
with the new ack semantics, yet I see your proposal as an optimization that
may reduce the number of cases where:
(1) a message was well delivered
(2) Sender cannot assume it was delivered.
Note that when a duplicate has expired when arriving, the ID of the initial
message may be removed, and the receiver RMP may never know that this is
a duplicate of a well-delivered message (this duplicate would be discarded
due to expiration.)
I have no problem with acking duplicates in that case.
That would improve things, yet only an optimization.
Is that a good summary of where we are?
Jacques
-----Original Message-----
From: Doug Bunting [mailto:]
Sent: Tuesday, December 16, 2003 2:40 PM
To: Jacques Durand
Cc: ; Bob Freund; Sunil Kunisetty; wsrm
Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination
behaviour
Jacques,
I am not sure what you mean. A message may be resent after the
receiving application has processed it. The previous acknowledgment
could easily have been lost. In effect, the sender is performing the
resend in order to retrieve the missing acknowledgment. Of course, that
sender does not know or care whether the original message or the
acknowledgment was lost.
This all means we need acknowledgments for all messages sent reliably
whether duplicates or not.
thanx,
doug
On 16-Dec-03 14:31, Jacques Durand wrote:
> + 1 on no faults for dups.
>
> But the end of your mail is ambiguous on one point:
>
> >I would propose we do not add these dupOfWhatever faults in the first
> >place and simply return acknowledgements.
>
> given the Ack semantics agreed on (ack-on-delivery),
> no acks will be sent for dups - which is fine.
>
> Jacques
...
