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

[Doug Davis <dug@us.ibm.com>]

Stefan,
  thanks for this - I've gone through your note
and added all of the
various spec changes that I believe would need to
be made in order 
for this to work - or for someone who reads the spec
(w/o knowledge
of this note) to know for sure how its supposed to
work.

"Stefan Batres" <stefanba@microsoft.com>
wrote on 02/27/2006 07:00:49 PM:
> 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.

Spec changes:
1 - MUST be a direct correlation between the request
sequence and the 
    response/offered sequence.
2 - client MUST know when the response/offered sequence
is done.  This
    means there MUST be a 1-1 relationship
between all requests and 
    responses or there MUST be some out
of band knowledge to make this
    determination.
3 - the client MUST use an RM-specific "poll"
message to initiate this
    "reverse message flow" of
the response/offered sequence TS message.
    Or, the client MUST periodically "poll"
the RMD in case there is
    some message that needs to be sent back
from the RMD to the RMS,
    whether it be an Ack, a CloseSeq or
a TermSeq.
4 - the RMS and/or the RMD MUST have access to the
WSDL/MEP-info since
    knowing whether or not there is a reply
expected is critical to
    making all of this work.

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

5 - the client MUST periodically "poll"
the RMD just in-case the
    RMD wants to close down the sequence.
 The only other way I can
    see it working is to rely on the client
to send a one-way message
    at some point so the RMD can use the
empty response flow to carry
    the CloseSeq message.  I think
it must be a one-way since not sending
    the real response message back (but
instead sending a CS) would
    probably not be what the client expected.
 And this "poll" message
    MUST reference the sequence in question
since the RMD needs to 
    know which (of possibly many) anon-RMSs
its talking to - it can't
    just sent a Close to any old RMS - it
must be one of the RMSs
    that's related to the response/offered
sequence.

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

I need to think more about 'a' since a 202 could also
mean its a late-
arriving (already acked) request - per #3 above -
and I don't know if
this is a problem or not yet.

6 - for 'b', in the case of an RMD receiving a message
it MUST NOT include
    an Ack for that message in any SeqAck
header until the AD has
    completed its processing of that message
and a reply is ready
    to be sent back.
7 - for 'c', the RMD MUST block while processing a
message if that
    message is already being processed by
the RMD/AD - and I think
    spec change #6 applies here too since
some other thread may
    choose to send an Ack back (maybe because
it finished processing
    message #n-1) and it MUST NOT include
ack for msg N.

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

Actually, that's not true.  If the RMS thinks
that it already sent the
Ack but it was lost there is no reason to think that
it would include
an Ack on the next message.  They only way you
can guarantee
this is if the RMD had sent an AckReq to the RMS -
which of course it
can't since it can't initiate a message.

8 - the RMS MUST include a SeqAck for the response/offered
Sequence
    in any TermSeq message - in the anon
case.
9 - if the RMS does not shut-down (ie. send a TS)
in a timely fashion
    the the RMS MUST send some kind of message
(perhaps the "poll"
    message per spec change #5) and it MUST
carry a SeqAck header
    for the offered/response sequence -
even if no new messages
    for that sequence have arrived since
the last Ack was sent.

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

I believe there are at least 9 changes (perhaps less
if we can combine
them), perhaps more as we investigate this more.  Marc's
note didn't
address _any_ of the topics you mentioned so I fail
to see how his
proposed set of changes imply directly or indirectly
any of the
things you've mentioned.

That's quite a list of changes - and they're not just
explanatory
changes, these are changes to how an RMS and/or RMD
MUST behave
when anonymous replyTo is used. They must (IMO) radically
change
the normal RM processing model in order to support
this.  One
might say we're hacking up the protocol.

One of the main things that kept popping up in my
head as I was 
reading this note was that the RMS and RMD had to
know something
special was going on in order for this to work.  And
I suspect that
that will always be true - so the question is: how
much tweaking of
the spec (if any) should we do in order to support
this.

Take, for example, spec change #3 - that to me is
key - and I'm
trying really hard not to be biased  :-)  -
but IMO the only way
this entire anon-replyTo thing can work is for the
RMS to 
periodically ask the RMD if there's something that
needs to be
sent back.  Relying on there always being some
message that needs
to be sent from the RMS to the RMD that we can either
piggy-back
something on, or even worse, hijack the response is
just not a good
thing to count on when writing a spec.

So, if the RMD must "poll" periodically
I think we need to ask ourselves
whether or not this is really an RM problem or not.
 Even when we
remove RM from the picture the entire notion of how
a client can
receive async responses when it can't expose an endpoint
is an issue
that is much broader than RM - RM is just one of the
first specs to
expose the problem.

If the client knows that something special is going
on (as is the case
here), and this isn't just an RM problem, it would
be smart to solve 
this in the non-RM case first and then confirm that
RM can be layered 
on top of this solution w/o hacking-up the RM protocol.
 IMO, we'd be
pushing the boundaries of our scope if we tried to
address this issue.
(I suppose it might be possible to claim that reliable
delivery could
include delivery to unreachable endpoints and thus
we could produce
a spec that includes a solution for that problem independent
of the
current RM protocol - but I doubt that our TC would
do that - it is
an option though)

I'd like to suggest that we consider making a request
of the 
WS-Addressing working group to see if they would be
willing to 
accept the "anon replyTo" issue as something
that
is within their domain. Based on their current time-line
we can 
suggest that they deferred it for v2 but then we can
be assured that
the issue will eventually be solved.

Also, I'd like to request that we do not vote on any
proposals
related to these two issues this week - this is too
important to
rush and we should make sure everyone has had a chance
to fully
think through the issues surrounding it.

thanks,
-Doug