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