Clarifications on two-way and anonymous clients

All,

In the last interop call there were several questions on how to support anonymous clients and two-way operations. It has also been noted that clarifying this usage of the protocol is needed to think about issues i089 and i090. Here are some clarifications to points that have been raised as a result of the interop call and the discussion on this list (thx to Dug for compiling the list of questions).

1. How does the offered seq get shutdown? ie. how does the RMD send a terminate back to the RMS?

In the submitted version of the spec, the RMD sent a TerminateSequence for the offered sequence on the response of the HTTP connection that carried a TerminateSequence from the client for the requested sequence. The RMD was forced to terminate its sequence when the client terminated its. In the new version of the spec, we have the TerminateSequenceResponse to worry about. I envisioned opening a new issue to add another final exchange, one for the responses. A client “requests” a TSR for the server’s TS, the server then “replies” with a TSR for the client’s original TS.

2. How can the RMD close the offered sequence if it needs to?

The RMD can close the sequence whenever it wants – the question is how it tells the client. The answer is that it would have to wait for the client to make a request. At that point, the RMD would respond with a CloseSequence message that may potentially piggy-back-acknowledge the sequence message that may have been carried by the request. The RMS will now have to deal with this as it sees fit – close its sequence, fault, keep using its sequence for one-way messages only, etc.

3. What should happen when a late arriving (already ack'd) message arrives at the RMD? What should the response be?

It depends, if the message is a one-way then an ack is sufficient. If the message is part of a two-way then:

a) if the reply has not been acknowledged then the reply for the late arriving message should a copy of the original reply.

b) If the reply has been acknowledged then it doesn’t matter, an ack or a 202 should be sufficient.

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.

5. If request msg #2 is acked (back at the RMS) but response msg #2 isn't acked (back at the RMD) how can the RMD resend it? I think its possible that the RMS can get to a point where it received response msg #2 but the ack for it was lost. So, RMS thinks all is well, but RMD doesn't. Unless the RMS resends a message (but why would it when it thinks all is well), then the RMD is stuck. Can't resend and can't close the sequence.

In general, if the ack for any given reply message is lost, the next message received by the RMD contain an ack for that reply. In the worst case, that message will be a TS that includes the ack.

6. What specific changes to the spec(s) do we ned to make to clear up these issues?

Marc sent out a set of proposed changes. I think those would suffice.

--Stefan

ws-rx message