+1
Jishnu.
Doug Bunting wrote:
> 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:]
>>>> 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: ;
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> 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: ;
>>>> Tel: +1 732 801 5744 Fax: +1 732 774 5133
>>>>
>>>>
