Ashok:
Most architects would want to eliminate duplicate messages from being
passed on to an application that may be compelled to make each one
actionable. Accordingly, there is a big requirement to capture and
constrain these at the messaging layer. Imagine you were sending a
"create account" message from a brokers office to a big insurance
company. If the message was retransmitted 5 times due to delays in
receiving acknowledgements by the SA and the DA received all five you
would create 5 new accounts.
Perhaps this is why some companies send me 5 copies of the same snail
mail ;-)
Duane
Ashok Malhotra wrote:
>>The WS-RM protocol itself is an AtLeastOnce protocol as
>>observed between the RMS and RMD.
>>
>>
>
>Let's make a note of this! If this is the case, then how is AtMostOnce
>an option as some messages may not be delivered. Sure RMD can throw messages
>away but then it can do whatever it wants with the messages.
>
>To my mind, AtMostOnce is not 'reliable' messaging.
>
>And if you want AtMostOnce why build the apparatus of a RMS and RMD
>and starting sequences etc. Why not just send messages and be done with it.
>They may or may not get there, but that's the protocol.
>
>All the best, Ashok
>
>
>
>
>>-----Original Message-----
>>From: Christopher B Ferris [mailto:]
>>Sent: Monday, July 25, 2005 1:08 PM
>>To: Doug Davis
>>Cc: Anish Karmarkar; ; wsrx
>>Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once"
>>delivery assurance
>>
>>Doug is exactly right. I thought I had made this point clear
>>in my overview presentation at the F2F.
>>
>>The WS-RM protocol itself is an AtLeastOnce protocol as
>>observed between the RMS and RMD.
>>That means that the RMD must sucessfully receive each message
>>in the sequence at least once.
>>That means that the RMS is responsible to retransmit any
>>message that is unacknowledged (within the relevant intervals, etc.)
>>
>>The DA does not effect what goes on the wire. It is a
>>contract between the RMD and AD logical components. For
>>AtMostOnce, the RMD is permitted to "drop" messages (e.g.
>>in the case where the
>>RMS has a limited store for unprocessed messages and it wants
>>to effect a LIFO or FIFO algorithm to drop one or more of the
>>received (and acknowledged) messages on the floor.
>>
>>I have heard arguments that AtLeastOnce as a DA between RMD
>>and AD makes no sense as there is already a need for the RMD
>>to check for duplicates, etc. Whatever...
>>
>>I think that for the most part, the DA that will have the
>>most use will be ExactlyOnce, but there are valid use cases
>>where one could certainly envisage AtMostOnce being quite relevant.
>>
>>To Anish's point, The use and purpose of Nacks is to optimize
>>the protocol by taking an optimistic view of the inherent
>>reliability of the network. e.g. the frequency of acks could
>>be tuned way down and nacks used to compensate for when the
>>RMD knows it wants a particular message to be retransmitted.
>>
>>For the protocol to complete "correctly", a
>>SequenceAcknowledgement with AcknowledgementRange elements
>>covering the complete range of MessageNumbers for the
>>Sequence MUST be received by the RMS.
>>
>>A Nack is not an Ack. Just because the RMS receives a Nack
>>does not mean by any stretch of the imagination that the
>>resultant retransmission of the message will be successfully
>>received by the RMD. Of course the RMS is required to respond
>>to successive Nacks of the same message.
>>
>>In the case when the RMS does not have the message to be
>>retransmitted, then the Sequence must be terminated by the sender.
>>
>>Cheers,
>>
>>Christopher Ferris
>>STSM, Emerging e-business Industry Architecture
>>email:
>>blog: http://webpages.charter.net/chrisfer/blog.html
>>phone: +1 508 377 9295
>>
>>Doug Davis/Raleigh/IBM@IBMUS wrote on 07/25/2005 03:09:17 PM:
>>
>>
>>
>>>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
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>
