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 assurance


Ashok Malhotra wrote:

>Chris, your interpretation is correct.
>
>As several people have pointed out, duplicate elimination
>on top of AtMostOnce may be desirable, but that is a private
>matter between the RMD and the AD.
>
>  
>
I am confused by the statement above.

Duplicate elimination means the same message id will not be delived 
twice,  At most once also means the same message
id will not be delivered twice (if this is not the case, it needs a new 
name).

TomRutt

>All the best, Ashok
> 
>
>  
>
>>-----Original Message-----
>>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
>>Sent: Monday, July 25, 2005 6:11 PM
>>To: wsrx
>>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
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>>    
>>
>
>  
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]