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: our favorite - anon replyTo

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? :-)


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