[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
Tom Rutt wrote: > 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. It turns out this is not allowed by HTTP. Attached is an extraction regarding pipelining HTTP requests on the same connection. It seems that the first request must have a response before a response may be send for the second request. This for my scenario, the dupOfHeld fault is send in response to the first request, and the ack would be send later as http response to second http request. This change of order is just an HTTP delivery detail, for the fault is still received before the 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/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. >> >> >> >> > > -- ---------------------------------------------------- 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]