[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 assur ance
Jacques, That's not how I interpreted Ashok's note. I think he was suggesting that it would be a waste to bother with ws-rm if you wanted AtMostOnce between RMS and RMD. Basically, I think he was saying: don't use rm for that. Of course, I could be completely wrong in that understanding. However, if that's what he meant, then I concur. 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 Jacques Durand <JDurand@us.fujitsu.com> wrote on 07/25/2005 08:35:14 PM: > But Ashok seems to also make the point that when AtMostOnce alone is requested, then there is no > reason for the protocol (and for RMS / RMD) to incur the overhead of Acks and resending mechanism... > -JD > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Monday, July 25, 2005 1:58 PM > To: ashok.malhotra@oracle.com > Cc: Anish Karmarkar; Doug Davis; Tom Rutt2; wsrx > Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assurance > Ashok, > I gather that you don't think that the protocol itself should be used to > provide an AtMostOnce > assurance between the RMS and RMD, and that the contract between the RMD > and AD is > whatever the two have established between themselves (they can do whatever > they like). > I think that I pretty much agree on this point. > 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 > Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 07/25/2005 04:30:27 > PM: > > > 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]