[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
+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: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 >>>> >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]