OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]