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] [i089] a revised proposal



"Duane Nickull" <dnickull@adobe.com> wrote on 02/21/2006 05:11:55 PM:
...

> 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


This is interesting because I don't think its limited to this anon
reply issue.  Are you suggesting that the RMD needs to do two different
things depending on whether its a dup or a retransmission?  I thought
one of the first things the TC decided was that all the RMD could safely
look at was the Seq header (id+msg#) to determine whether or not this
message had been seen before.  Did you want to revisit that decision?

> 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:
>  
> 1. That its original ack did not reach the RMS within the specified
> time period; or

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


Yes but the way it normally tells it that it received (or already received)
the message is thru the sending of Acks not the http respone code.  My
concern is that the RMD (and actually the RMS) may need to be changed
from their normal RM behavior in order to support this case.  For example,
normally the RMS can drop the contents of a message once it has been Acked -
in the proposed solution this is no longer the case - it must now hold on to
it until the response is received.  That now changes our RM processing and
links one RM sequence with another - all of which is new and true for just
certain cases. It may be the right thing to do so but if so we need to spell
that out in the spec then. And, IMO, we need to also make sure that we can
still fully support the spec in these case.  I can understand if some edge
features can't be supported (that _might_ be ok - would need to examine
each one carefully) but if mainline (normal) RM processing is compromised
then that's something serious.

-Doug

> Duane
>  
>  
>  
>  
> *******************************
> 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 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


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