OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ws-rx] our favorite - anon replyTo


I agree that this is another issue with the proposed model as written.


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


"Oxygenating the Web Service Platform", www.wso2.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]