[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assurance
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:chrisfer@us.ibm.com] >>Sent: Monday, July 25, 2005 1:08 PM >>To: Doug Davis >>Cc: Anish Karmarkar; tom@coastin.com; 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: chrisfer@us.ibm.com >>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 <Anish.Karmarkar@oracle.com> >>>07/25/2005 01:11 PM >>> >>>To >>> >>>tom@coastin.com >>> >>>cc >>> >>>wsrx <ws-rx@lists.oasis-open.org> >>> >>>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 >>>> >>>> >>>> >> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]