Re: [ws-rx] Clarifications on two-way and anonymous clients

[Tom Rutt <tom@coastin.com>]

Stefan Batres wrote:

> All,
>
Few comments/questions in=line

> 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.
>
However, the "rmd" would have to send a "replyTo" epr with the place for 
the "client" to send the TSR corresponding to the offered sequence 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.
>
Same comment as on 1: the "rmd" would have to send a "replyTo" epr with 
the place for the "client" to send the CSR corresponding to the offered 
sequence CS?

> 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
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133