Doug:
Good questions – too bad I don’t
have good answers ;-)
I think “duplicate” has to be juxtaposed
to “retransmission” before meaningful conversation can take place. Additionally.,
we have to decide what layer takes action in certain events. This may lead to
profiles for use of WS-RX over different transport protocols where and if
applicable, although I imagine most people will use HTTP. If the duplicate
message is in fact a real duplicate (exactly the same byte for byte) then a 202
would be acceptable, assuming HTTP as the transport protocol. This in itself
is an issue given our charter does not allow us to map to specific network
transports. We rely on SOAP which MAY be used over HTTP but is not tied to it.
If UDP receives a byte for byte duplicate, it does nothing to handle this.
If it is a retransmission of an earlier
message, it has to be treated differently IMO. HTTP provides a 409 for state
conflicts however it is fathomable that WS-RX may be used with protocols other
than HTTP in the future, is it not? UDP is best effort but the WS-RX spec may
make it possible to achieve some form of RM using UDP (probably not
architecturally elegant). In any event, I interpret our charter to preclude
mapping to specific network protocols.
TCP/IP also has a mechanism for avoiding
duplicate packets that are true duplicates (not retransmissions).
Logic:
If an RMD receives an already acked
message, it must assume one of two things:
- That
its original ack did not reach the RMS within the specified time period;
or
- That
something has gone wrong with the RMS (and any application that uses it) or
some node in the network between the RMS and the RMD is doing something weird
causing the problem.
In either case, all the RMD should do is
tell the RMS that it has already received the message IMHO. At some point, a
maximum numbers of retries should be reached or an ack should get through and
the transmission should cease.
Duane
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006
11:53 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a
revised proposal
Duane,
yes, its the latter. Yes I agree its a dup but the question is what
should the response be? a 202? the response that was previous generated? What
if the response that was previously sent was lost - would seem to imply that a
202 would be wrong - and the RMD needs to send the response message - or at
least do so until the response is acked. But then what's the response to
another dup request? Now is it a 202? And what should the client do with
that 202? 202 feels like an odd response since it could mean so many
things, but mainly it means just "Accepted" - would an RM-specific
"already sent you the response" message be more appropriate? And
in these cases (202 or some other response) should it assume that some other
retry thread already got the response? probably. But what about
non-ExactlyOnce DAs? Does that change things at all? Dunno. Maybe
not. I may have already answered my own question with all of this
rambling, but the point isn't that some of these questions can't be answered
but rather I'd like to see the proposed textual changes for the spec so that
readers will not need to ask these questions themselves.
The more we talk about this the more I'm thinking that we're leaving our RM
space and entering into WSA's :-(
thanks,
-Doug
|
"Duane Nickull"
<dnickull@adobe.com>
02/21/2006 02:24 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [ws-rx] [i089] a revised proposal
|
|
Doug:
Can you be more specific on point #3? Do you mean a
message arrives after timeout value has been exceeded for a legally constituted
sequence or a message arrives after the RMD has send an ack for it? If it
is the latter, the late arriving message would simply be a duplicate (unless
the RMD had ESP) and could just be dropped, could it not? Perhaps I am
missing the meaning.
Funny how on the surface it all seems to simple.
D
*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006 10:57 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a revised proposal
I believe MSFT has the todo to go off and write down how anon ReplyTo is
supposed to work. In the last interop call we had there were quite a few
questions raised about how things should work and we need those addressed. I
believe some of them were:
How does the offered seq get shutdown? ie. how does the RMD send a
terminate back to the RMS?
How can the RMD close the offered sequence if it needs to?
What should happen when a late arriving (already ack'd) message arrives at the
RMD? What should the response be?
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?
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.
What specific changes to the spec(s) do we ned to make to clear up these
issues?
If we end up keeping Offer around just for the anon replyTo case (which I
believe you said is the main reason for keeping it), but we can't explain how
anon ReplyTo is supposed to work without hacking up the protocol, I'm not sure
its worth keeping it - esp. not when there are other solutions around that do
allow these scenarios to work without messing up RM.
thanks,
-Doug
|
"Marc Goodner" <mgoodner@microsoft.com>
02/21/2006 01:12 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [ws-rx] [i089] a revised proposal
|
|
Only time? I think the scenario is pretty clear so what are the issues with it
you see that would prevent it from working?
If you are suggesting that you want to do interop on it first then are you
likewise suggesting that this issue (and I would infer i090) should be deferred
from being closed until then?
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, February 21, 2006 10:04 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] [i089] a revised proposal
Yea, I figured you'd say that :-) that's why I wanted the latest text in
the issue list. W.r.t. your assertion that anon replyTo can work w/RM -
only time (and your proposal) will tell :-)
-Doug
|
"Marc Goodner"
<mgoodner@microsoft.com>
02/21/2006 12:55 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
RE: [ws-rx] [i089] a revised proposal
|
|
I can’t support this. I think some of the scenarios we have been
discussing around the use of Offer demonstrate that you can get a reliable
response back when using an anon wsa:ReplyTo value. I think the proposal would
be OK if the last sentence, beginning “Note” was struck.
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, February 08, 2006 9:31 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] [i089] a revised proposal
For issue 089, I'd like to offer this revised proposed text (same basic idea
just different wording):
After line 441 of [1] add:
Messages sent using this protocol MUST NOT use a wsa:To value that would
prohibit the RM Source from retransmitting unacknowledged messages. For
example, using WS-Addressing's anonymous IRI, without any additional
transmission mechanism, would restrict an RM Source's ability to
re-establishing a new connection to the RM Destination when a re-transmission
of a message is needed. Note, that this implicitly impacts possibles
values used in other places - for example, in wsa:ReplyTo when responses are
expected to be transmitted reliably.
thanks,
-Doug
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16095/wsrm-1.1-spec-wd-08.pdf