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

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