[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
Typical firewall setting for tcp session timeout is an hour or so. > -----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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]