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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
