OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[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]