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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: RE: [wsrm] Need to rethink semantics of duplicate elimination behaviour


Title: RE: [wsrm] Need to rethink semantics of duplicate elimination behaviour

+ 1 on no faults for dups.

But the end of your mail is ambiguous on one point:

>I would propose we do not add these dupOfWhatever faults in the first
>place and simply return acknowledgements.

given  the Ack semantics agreed on (ack-on-delivery),
no acks will be sent for dups - which is fine.

Jacques

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Tuesday, December 16, 2003 1:11 PM
To: tom@coastin.com
Cc: Bob Freund; Sunil Kunisetty; wsrm
Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination
behaviour


Sorry, I must have missed something important a while back.  The idea of
a fault returned when a duplicate is received seems flawed from the
start and the questions below are only the start of the problems.

 From the original sender's perspective, it is irrelevant whether it was
the previous outbound message or the acknowledgement response that was
lost.  That system is looking for an acknowledgement and will treat a
dupOfWhatever fault identically to that acknowledgement.  Extra
acknowledgements that arise from duplicates generated in the network are
certainly not faults from this perspective and the original sender must
be designed to handle them.

 From the receiver's perspective, a duplicate is irrelevant to the
application at that end and will not be passed along to it.  However,
this again is not a fault situation -- it is part of the normal
processing of the RMP as it handles duplicates caused by lost
acknowledgements (sender retries) and the underlying protocols (network
duplicate generation).  It takes identical effort to store and return an
earlier acknowledgement or to find a previous message identifier with
its disposition and generate a particular fault.  The fault case may
take more effort in fact, with little or no gain.

I would propose we do not add these dupOfWhatever faults in the first
place and simply return acknowledgements.  This has the added benefit of
reducing processing requirements when an acknowledgement must be signed
or encrypted because the work does not have to be done again to sign or
encrypt a new fault message.

thanx,
        doug

On 12-Dec-03 11:56, Tom Rutt wrote:

> Bob Freund wrote:
>
>> Typical firewall setting for tcp session timeout is an hour or so.
>>
> Jacques gave me a clarification which removes my concerns.
>
> If a sender is piplining requests from a sequence on the same TCP
> connection,
> the properties of TCP will ensure ordered receipt by the sender, to the
> error cases
> I was concerned about would not happen .
>
> The problems of ordered delivery occur when different TCP connections
> are used per
> message on the sequence.  However in this case, the order of return is
> not constrained by
> pipelining.
>
> However, I still think we need two faults, one for dupOfHeld and the
> other for dupOfDelivered.
>
> Tom Rutt.
>
>>
>> 
>>
>>> -----Original Message-----
>>> From: Tom Rutt [mailto:tom@coastin.com]
>>> Sent: Thursday, December 11, 2003 2:01 PM
>>> To: Sunil Kunisetty
>>> Cc: wsrm
>>> Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination
>>> behaviour
>>>
>>>
>>> Sunil Kunisetty wrote:
>>>
>>>  
>>>
>>>> Tom,
>>>>
>>>> This semantics will be very confusing as it will result in    
>>>
>>> DuplicateMessage
>>>  
>>>
>>>> fault (which indirectly indicates an Ack.) before the    
>>>
>>> actual Ack. itself.
>>>  
>>> But I think this is a consequence of our new semantics of
>>> acknowldegment awaiting delivery.
>>>
>>> If a sender resends a message which is being held wating for a prior
>>> message, what should
>>> the receiver do?    He is holding the ack to the original http
>>> request for that messageID, what
>>> does he do for the new http request which is duplicate due to
>>> retry?   I say the receiver gives
>>> a fault message as http response to the second http request with info
>>> that the original request
>>> was received, but its response is being held due to wating for a
>>> prior message.
>>>
>>> There are two http requests outstanding from the sender, and the fact
>>> is that the second
>>> http request is responded first with a fault (which is really a reply
>>> with information about
>>> the status of the message) message.  Later, when delivered, the
>>> receiver returns a response to
>>> the original http request with an ack.
>>>
>>> Note that the first http request could wait a long time for a
>>> response.  If the TCP connection
>>> goes down, what does HTTP do to get the response back to the sender?
>>>
>>> Tom Rutt
>>>
>>> PS: this discussion is about a potential new issue, and is not part
>>> of 52/57 resolution.
>>>
>>>
>>>  
>>>
>>>> Take the case of ordered group in which msg. 2 was missing    
>>>
>>> and msg. 3
>>>  
>>>
>>>> of received. Since it is not delivered, it will not be    
>>>
>>> Ack-ed. Assume
>>>  
>>>
>>>> your new proposal. If msg. 3 is tried, a NewDuplicateMsg    
>>>
>>> fault will be
>>>  
>>>
>>>> sent. Assume 2 was finally delivered. Then the receiver    
>>>
>>> will send the
>>>  
>>>
>>>> original Ack...
>>>>
>>>> For Sender, it will be very confusing to receive the Ack.    
>>>
>>> AFTER receiving
>>>  
>>>
>>>> a DuplicateMsg. fault.
>>>>
>>>> -Sunil
>>>>
>>>> Tom Rutt wrote:
>>>>
>>>>
>>>>
>>>>    
>>>>
>>>>> Based on our current thinking, we are not sending an ack until the
>>>>> message is actually delivered.
>>>>>
>>>>> Thus in the ordered delivery held waiting for prior message      
>>>
>>> state, an
>>>  
>>>
>>>>> RMP may receive several
>>>>> retransmits of that held, and thus not acknowledged message.
>>>>>
>>>>> In such a case, the receiving rmp should respond to sending rmp
>>>>> regarding its receipt of the duplicate message with an appropirate
>>>>> DuplicateMessage fault.
>>>>>
>>>>> Please correct me if I am wrong, but I think we need to clean up the
>>>>> semantics of this from what is in the current draft.
>>>>>
>>>>> Tom Rutt
>>>>>
>>>>> --
>>>>> ----------------------------------------------------
>>>>> Tom Rutt                email: tom@coastin.com;      
>>>
>>> trutt@fsw.fujitsu.com
>>>  
>>>
>>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>>>
>>>>> To unsubscribe from this mailing list (and be removed from      
>>>
>>> the roster of the OASIS TC), go to
>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leav
>>> e_workgroup.php.
>>>  
>>>
>>>>> 
>>>>>      
>>>>
>>>> To unsubscribe from this mailing list (and be removed from    
>>>
>>> the roster of the OASIS TC), go to
>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leav
>>> e_workgroup.php.
>>>  
>>>
>>>>
>>>>
>>>>    
>>>
>>> --
>>> ----------------------------------------------------
>>> Tom Rutt        email: tom@coastin.com; trutt@fsw.fujitsu.com
>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>
>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the roster
>>> of the OASIS TC), go to
>>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leav
>>> e_workgroup.php.
>>>
>>>
>>>  
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>>
>>
>> 
>>
>
>


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



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