Title: Message
Doug:
I think this is what this issue is trying to clarify.
What you are saying is proposal (3) in
Tom's email and basically means that the DA
is a contract between application
destination
and RM
destination, and thus does not apply to wire protocol which is always at least
once.
However, I can also see the merits of the other two
proposals.
Lei
-----Original Message-----
From: Doug Davis
[mailto:]
Sent: Monday, July 25, 2005 11:09
AM
To: Anish Karmarkar
Cc: ;
wsrx
Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once"
delivery assurance
Hi,
No matter what the DA is,
any unACK'd message needs to be resent.
DAs have no impact on the protocol itself.
thanks,
-Doug
Anish Karmarkar
<>
07/25/2005 01:11 PM
To
cc
wsrx
<>
Subject
Re: [ws-rx] NEW ISSUE:
semantics of "at most once" delivery
assurance
Two related questions that need to be answered are:
can a RM
receiver send a NACK in case of AtMostOnce DA? If yes, what is
the RM
sender supposed to do when it receives such a NACK and it is
never going
to retransmit the message (as it has already thrown away the
message) --
i.e. to prevent the RM receiver from NACKing the message
repeatedly,
should the RM sender send a specific fault?
-Anish
--
Tom
Rutt wrote:
> *Title*: Semantics of "At most once" Delivery
assurance.
>
> *Description*:
> The semantics of the "at
most once" delivery assurance are not clear.
>
> One
interpretation is that at most once implies that the sender is not
>
required to retransmit mesages which are not acked.
>
>
*Justification*:
> It is important to clarify whether the sender must
retransmit
> unacknowledged messages when the "at most once" delivery
assurance is in
> use.
>
> *Target*: (core | soap | wsdl |
policy | schema | all)
> all
>
> *Type: *(design |
editorial)
> design
>
> *Proposal*:
>
>
Clarify the semantics. There are at least three possible semantics
> associated with "at most once"
>
> proposal 1) at most
once means that the sender will never retransmit a
> message,
regardless of whether it is acknolweged by the destination.
>
>
Proposal 2) The sender may retransmis messages, but is not required to
> to so, however the destination will not deliver
duplicates
>
> Proposal 3) the sender must retransmit messages,
however the destination
> may drop messages in times of resource
saturation, but will never
> deliver a duplicate.
>
>
*Related issues*:
> Issue 9
>
