[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] our favorite - anon replyTo
Dug I agree that this is another issue with the proposed model as written. Paul Doug Davis wrote: > > The anonymous replyTo scenario in the interop doc says this: > As a consequence, a request must be resent to allow for the > retransmission of its reply even if the request has already been > acknowledged (by another reply received on a different HTTP > connection, for example). > In one of Stefan's previous notes he said this (I bolded the key part): > 4. Can there be two sockets connected to the RMD at the same time and > both sending the same message? What's the response to in each case? > The number of sockets a client opens seems irrelevant to the abstract > correctness of the protocol. Maybe a better question is: What if two > instances of the same request arrive at the same time? The rule that > MUST be followed is: *Neither of the replies should carry an ack for > the request until the RMD/AD decide what the reply should be*. For > instance, say request A and request B arrive at the same time, they > both carry a Sequence header with MessageNumber == N. Say A is > processed by the RMD first and delivered to the AD. The AD takes some > time to prepare a reply. Now B is processed. According the rule above > the RMD can do one of three things: a) Send a 202. b) Send an ack that > does not include N. c) Hold the request carrying B until the AD sends > the reply, then reply to both requests (A and B) with that reply and > an ack carrying N. This would seem to be the best approach. > > Unless I'm misreading these, the text from the interop doc implies > that a request can be ACKed even though the reply hasn't been sent. > The text from Stefan's note implies that an ACK for a request is > never sent until the reply is sent. > > What I'm wondering is whether or not the solution MSFT is proposing > allows for a reply to be ACKed w/o the response having been delivered? > This is an important issue to me because the text in the interop doc > implies that the RMS would need to resend an ACKed request in order > for the response to be delivered. The notion of resending an already > ACKed message is a bit of a new concept (at least to me). The text in > Stefan's note seems to imply that that may not be necessary - it could > be interpreted as the RMS will never receive an ACK for a request w/o > the corresponding reply, so it would not need to resend an ACKed > request. If we did try to support this it would involve some kind of > change to either the RMS or RMD (or both) in how they deal with ACKs > and I'm trying to get an understanding of what kinds of changes we're > talking about. > > Did any of that make sense? :-) > > thanks > -Doug -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://feeds.feedburner.com/bloglines/pzf paul@wso2.com "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]