[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
________________________________ From: Jacques Durand [mailto:JDurand@us.fujitsu.com]=20 Sent: Monday, Jul 25, 2005 6:51 PM To: 'Christopher B Ferris'; wsrx Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assur ance =09 =09 Let us wait for Ashok to clarify this (Ashok, have we put enough words in your mouth yet :-) ?=20 I think we agree that some aspect of the protocol would be useless for just AtMostOnce, but I'd argue that the notion of sequence and seq number is quite important for implementing an efficient duplicate check - so even if no Ack nor resending is needed, I'd say it is valuable to use this part of the protocol (meaning the sequence creation and usage).=20 -Jacques=20 -----Original Message-----=20 From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]=20 Sent: Monday, July 25, 2005 6:11 PM=20 To: wsrx=20 Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assur ance=20 Jacques,=20 That's not how I interpreted Ashok's note. I think he was suggesting that=20 it would be a waste to=20 bother with ws-rm if you wanted AtMostOnce between RMS and RMD.=20 Basically, I think he was saying: don't use rm for that.=20 Of course, I could be completely wrong in that understanding. However, if=20 that's what he meant, then=20 I concur.=20 Cheers,=20 Christopher Ferris=20 STSM, Emerging e-business Industry Architecture=20 email: chrisfer@us.ibm.com=20 blog: http://webpages.charter.net/chrisfer/blog.html=20 phone: +1 508 377 9295=20 Jacques Durand <JDurand@us.fujitsu.com> wrote on 07/25/2005 08:35:14 PM:=20 > But Ashok seems to also make the point that when AtMostOnce alone is=20 requested, then there is no=20 > reason for the protocol (and for RMS / RMD) to incur the overhead of=20 Acks and resending mechanism...=20 > -JD=20 > -----Original Message-----=20 > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]=20 > Sent: Monday, July 25, 2005 1:58 PM=20 > To: ashok.malhotra@oracle.com=20 > Cc: Anish Karmarkar; Doug Davis; Tom Rutt2; wsrx=20 > Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery=20 assurance=20 > Ashok,=20 > I gather that you don't think that the protocol itself should be used to=20 > provide an AtMostOnce=20 > assurance between the RMS and RMD, and that the contract between the RMD=20 > and AD is=20 > whatever the two have established between themselves (they can do=20 whatever=20 > they like).=20 > I think that I pretty much agree on this point.=20 > Cheers,=20 > Christopher Ferris=20 > STSM, Emerging e-business Industry Architecture=20 > email: chrisfer@us.ibm.com=20 > blog: http://webpages.charter.net/chrisfer/blog.html=20 > phone: +1 508 377 9295=20 > Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 07/25/2005 04:30:27=20 > PM:=20 > > > The WS-RM protocol itself is an AtLeastOnce protocol as=20 > > > observed between the RMS and RMD.=20 > >=20 > > Let's make a note of this! If this is the case, then how is AtMostOnce=20 > > an option as some messages may not be delivered. Sure RMD can throw=20 > messages=20 > > away but then it can do whatever it wants with the messages. > >=20 > > To my mind, AtMostOnce is not 'reliable' messaging.=20 > >=20 > > And if you want AtMostOnce why build the apparatus of a RMS and RMD=20 > > and starting sequences etc. Why not just send messages and be done=20 with=20 > it.=20 > > They may or may not get there, but that's the protocol.=20 > >=20 > > All the best, Ashok=20 > >=20 > >=20 > > > -----Original Message-----=20 > > > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]=20 > > > Sent: Monday, July 25, 2005 1:08 PM=20 > > > To: Doug Davis=20 > > > Cc: Anish Karmarkar; tom@coastin.com; wsrx=20 > > > Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once"=20 > > > delivery assurance=20 > > >=20 > > > Doug is exactly right. I thought I had made this point clear=20 > > > in my overview presentation at the F2F.=20 > > >=20 > > > The WS-RM protocol itself is an AtLeastOnce protocol as=20 > > > observed between the RMS and RMD.=20 > > > That means that the RMD must sucessfully receive each message=20 > > > in the sequence at least once.=20 > > > That means that the RMS is responsible to retransmit any=20 > > > message that is unacknowledged (within the relevant intervals, etc.)=20 > > >=20 > > > The DA does not effect what goes on the wire. It is a=20 > > > contract between the RMD and AD logical components. For=20 > > > AtMostOnce, the RMD is permitted to "drop" messages (e.g.=20 > > > in the case where the=20 > > > RMS has a limited store for unprocessed messages and it wants=20 > > > to effect a LIFO or FIFO algorithm to drop one or more of the=20 > > > received (and acknowledged) messages on the floor.=20 > > >=20 > > > I have heard arguments that AtLeastOnce as a DA between RMD=20 > > > and AD makes no sense as there is already a need for the RMD=20 > > > to check for duplicates, etc. Whatever...=20 > > >=20 > > > I think that for the most part, the DA that will have the=20 > > > most use will be ExactlyOnce, but there are valid use cases=20 > > > where one could certainly envisage AtMostOnce being quite relevant.=20 > > >=20 > > > To Anish's point, The use and purpose of Nacks is to optimize=20 > > > the protocol by taking an optimistic view of the inherent=20 > > > reliability of the network. e.g. the frequency of acks could=20 > > > be tuned way down and nacks used to compensate for when the=20 > > > RMD knows it wants a particular message to be retransmitted.=20 > > >=20 > > > For the protocol to complete "correctly", a=20 > > > SequenceAcknowledgement with AcknowledgementRange elements > > > covering the complete range of MessageNumbers for the=20 > > > Sequence MUST be received by the RMS.=20 > > >=20 > > > A Nack is not an Ack. Just because the RMS receives a Nack > > > does not mean by any stretch of the imagination that the=20 > > > resultant retransmission of the message will be successfully=20 > > > received by the RMD. Of course the RMS is required to respond=20 > > > to successive Nacks of the same message.=20 > > >=20 > > > In the case when the RMS does not have the message to be=20 > > > retransmitted, then the Sequence must be terminated by the sender.=20 > > >=20 > > > Cheers,=20 > > >=20 > > > Christopher Ferris=20 > > > STSM, Emerging e-business Industry Architecture=20 > > > email: chrisfer@us.ibm.com=20 > > > blog: http://webpages.charter.net/chrisfer/blog.html=20 > > > phone: +1 508 377 9295=20 > > >=20 > > > Doug Davis/Raleigh/IBM@IBMUS wrote on 07/25/2005 03:09:17 PM:=20 > > >=20 > > > >=20 > > > > Hi,=20 > > > > No matter what the DA is, any unACK'd message needs to be resent.=20 > > > > DAs have no impact on the protocol itself.=20 > > > > thanks,=20 > > > > -Doug=20 > > > >=20 > > > >=20 > > >=20 > > > >=20 > > > > Anish Karmarkar <Anish.Karmarkar@oracle.com>=20 > > > > 07/25/2005 01:11 PM=20 > > > >=20 > > > > To=20 > > > >=20 > > > > tom@coastin.com=20 > > > >=20 > > > > cc=20 > > > >=20 > > > > wsrx <ws-rx@lists.oasis-open.org>=20 > > > >=20 > > > > Subject=20 > > > >=20 > > > > Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery=20 > > > assurance=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Two related questions that need to be answered are:=20 > > > > can a RM receiver send a NACK in case of AtMostOnce DA? If=20 > > > yes, what is=20 > > > > the RM sender supposed to do when it receives such a NACK and it=20 is=20 > > > > never going to retransmit the message (as it has already > > > thrown away the=20 > > >=20 > > > > message) -- i.e. to prevent the RM receiver from NACKing > > > the message=20 > > > > repeatedly, should the RM sender send a specific fault?=20 > > > >=20 > > > > -Anish=20 > > > > --=20 > > > >=20 > > > > Tom Rutt wrote:=20 > > > > > *Title*: Semantics of "At most once" Delivery assurance.=20 > > > > >=20 > > > > > *Description*:=20 > > > > > The semantics of the "at most once" delivery assurance > > > are not clear.=20 > > > > >=20 > > > > > One interpretation is that at most once implies that the=20 > > > sender is not=20 > > >=20 > > > > > required to retransmit mesages which are not acked.=20 > > > > >=20 > > > > > *Justification*:=20 > > > > > It is important to clarify whether the sender must retransmit=20 > > > > > unacknowledged messages when the "at most once" delivery=20 > > > assurance is=20 > > > in=20 > > > > > use.=20 > > > > >=20 > > > > > *Target*: (core | soap | wsdl | policy | schema | all) > > > > > all=20 > > > > >=20 > > > > > *Type: *(design | editorial)=20 > > > > > design=20 > > > > >=20 > > > > > *Proposal*:=20 > > > > >=20 > > > > > Clarify the semantics. There are at least three possible=20 > > > semantics=20 > > > > > associated with "at most once"=20 > > > > >=20 > > > > > proposal 1) at most once means that the sender will never=20 > > > retransmit a=20 > > >=20 > > > > > message, regardless of whether it is acknolweged by the=20 > > > destination.=20 > > > > >=20 > > > > > Proposal 2) The sender may retransmis messages, but is > > > not required to=20 > > >=20 > > > > > to so, however the destination will not deliver duplicates=20 > > > > >=20 > > > > > Proposal 3) the sender must retransmit messages, however the=20 > > > destination=20 > > > > > may drop messages in times of resource saturation, but will=20 never=20 > > > > > deliver a duplicate.=20 > > > > >=20 > > > > > *Related issues*:=20 > > > > > Issue 9=20 > > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > >=20 ------_=_NextPart_001_01C59187.4F86E942 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>RE: [ws-rx] NEW ISSUE: semantics of "at most once" = delivery assur ance</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>It seems to me that the important use = case to=20 acknowledge as DA between the RMD and AD is "exactly once" semantics. We = are=20 discussing what types of DAs need to be exposed and be known by a client = application, not the interaction between RMD and RMS. Therefore, it is = important=20 to discuss what DAs need to be exposed as agreed between RMD and AD = which will=20 also affect an application client's choice/behaviour. = </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN><SPAN = class=3D311565501-26072005><FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2>At most once esp. when the messages are = permitted to be=20 dropped on the "floor" does not make sense as one would not bother with = using=20 RM. When one does not allow the messages to be dropped but also required = them=20 tobe delivered only once, you end up with exactly once semantics. I = believe this=20 is also Chris's point. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005></SPAN><SPAN class=3D311565501-26072005>From = an=20 application client's point of view, it is important to know that the DA = for=20 exactly once is obeyed even if it is only as "observed" assurance. For = example,=20 one may care that an endpoint is reliable and the RMD will deliver the = messages=20 exactly once to accomodate a debit (or credit) message of a bank = account. This=20 type of DA may be used for choosing an endpoint (As an example, I would = not=20 personally choose an endpoint for my bank which had at-most-once DA = for credit messages since my deposits may be gone to no man's land = :-). As=20 a matter of fact, I would change my bank if the bank advertised reliable = message=20 delivery but could only advertise at most once behaviour. For me, it is = not=20 reliable, period). </SPAN></FONT></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005></SPAN></FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005>Cheers,</SPAN></FONT></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005></SPAN></FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005>--umit</SPAN></FONT></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT = color=3D#0000ff><SPAN=20 class=3D311565501-26072005></SPAN></FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D311565501-26072005><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Jacques Durand=20 [mailto:JDurand@us.fujitsu.com] <BR><B>Sent:</B> Monday, Jul 25, 2005 = 6:51=20 PM<BR><B>To:</B> 'Christopher B Ferris'; wsrx<BR><B>Subject:</B> RE: = [ws-rx]=20 NEW ISSUE: semantics of "at most once" delivery assur=20 ance<BR></FONT><BR></DIV> <DIV></DIV> <P><FONT size=3D2>Let us wait for Ashok to clarify this (Ashok, have = we put=20 enough words in your mouth yet :-) ?</FONT> </P> <P><FONT size=3D2>I think we agree that some aspect of the protocol = would be=20 useless for just AtMostOnce, but I'd argue that the notion of sequence = and seq=20 number is quite important for implementing an efficient duplicate = check - so=20 even if no Ack nor resending is needed, I'd say it is valuable to use = this=20 part of the protocol (meaning the sequence creation and usage). = </FONT></P> <P><FONT size=3D2>-Jacques</FONT> </P> <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT = size=3D2>From:=20 Christopher B Ferris [<A=20 href=3D"mailto:chrisfer@us.ibm.com";>mailto:chrisfer@us.ibm.com</A>]=20 </FONT><BR><FONT size=3D2>Sent: Monday, July 25, 2005 6:11 PM</FONT> = <BR><FONT=20 size=3D2>To: wsrx</FONT> <BR><FONT size=3D2>Subject: RE: [ws-rx] NEW = ISSUE:=20 semantics of "at most once" delivery assur ance</FONT> </P> <P><FONT size=3D2>Jacques,</FONT> </P> <P><FONT size=3D2>That's not how I interpreted Ashok's note. I think = he was=20 suggesting that </FONT><BR><FONT size=3D2>it would be a waste to=20 </FONT><BR><FONT size=3D2>bother with ws-rm if you wanted AtMostOnce = between RMS=20 and RMD.</FONT> </P> <P><FONT size=3D2>Basically, I think he was saying: don't use rm for=20 that.</FONT> </P> <P><FONT size=3D2>Of course, I could be completely wrong in that = understanding.=20 However, if </FONT><BR><FONT size=3D2>that's what he meant, = then</FONT>=20 <BR><FONT size=3D2>I concur. </FONT></P> <P><FONT size=3D2>Cheers,</FONT> </P> <P><FONT size=3D2>Christopher Ferris</FONT> <BR><FONT size=3D2>STSM, = Emerging=20 e-business Industry Architecture</FONT> <BR><FONT size=3D2>email:=20 chrisfer@us.ibm.com</FONT> <BR><FONT size=3D2>blog: <A=20 href=3D"http://webpages.charter.net/chrisfer/blog.html"=20 = target=3D_blank>http://webpages.charter.net/chrisfer/blog.html</A></FONT>= =20 <BR><FONT size=3D2>phone: +1 508 377 9295</FONT> </P> <P><FONT size=3D2>Jacques Durand <JDurand@us.fujitsu.com> wrote = on=20 07/25/2005 08:35:14 PM:</FONT> </P> <P><FONT size=3D2>> But Ashok seems to also make the point that = when=20 AtMostOnce alone is </FONT><BR><FONT size=3D2>requested, then there is = no=20 </FONT><BR><FONT size=3D2>> reason for the protocol (and for RMS / = RMD) to=20 incur the overhead of </FONT><BR><FONT size=3D2>Acks and resending=20 mechanism...</FONT> <BR><FONT size=3D2>> -JD </FONT><BR><FONT = size=3D2>>=20 -----Original Message----- </FONT><BR><FONT size=3D2>> From: = Christopher B=20 Ferris [<A = href=3D"mailto:chrisfer@us.ibm.com";>mailto:chrisfer@us.ibm.com</A>]=20 </FONT><BR><FONT size=3D2>> Sent: Monday, July 25, 2005 1:58 PM=20 </FONT><BR><FONT size=3D2>> To: ashok.malhotra@oracle.com = </FONT><BR><FONT=20 size=3D2>> Cc: Anish Karmarkar; Doug Davis; Tom Rutt2; wsrx = </FONT><BR><FONT=20 size=3D2>> Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most = once"=20 delivery </FONT><BR><FONT size=3D2>assurance </FONT><BR><FONT = size=3D2>> Ashok,=20 </FONT><BR><FONT size=3D2>> I gather that you don't think that the = protocol=20 itself should be used to </FONT></P> <P><FONT size=3D2>> provide an AtMostOnce </FONT><BR><FONT = size=3D2>>=20 assurance between the RMS and RMD, and that the contract between the = RMD=20 </FONT></P> <P><FONT size=3D2>> and AD is </FONT><BR><FONT size=3D2>> = whatever the two=20 have established between themselves (they can do </FONT><BR><FONT=20 size=3D2>whatever </FONT><BR><FONT size=3D2>> they like). = </FONT><BR><FONT=20 size=3D2>> I think that I pretty much agree on this point. = </FONT><BR><FONT=20 size=3D2>> Cheers, </FONT><BR><FONT size=3D2>> Christopher = Ferris=20 </FONT><BR><FONT size=3D2>> STSM, Emerging e-business Industry = Architecture=20 </FONT><BR><FONT size=3D2>> email: chrisfer@us.ibm.com = </FONT><BR><FONT=20 size=3D2>> blog: <A = href=3D"http://webpages.charter.net/chrisfer/blog.html"=20 target=3D_blank>http://webpages.charter.net/chrisfer/blog.html</A>=20 </FONT><BR><FONT size=3D2>> phone: +1 508 377 9295 </FONT><BR><FONT = size=3D2>> Ashok Malhotra <ashok.malhotra@oracle.com> wrote = on=20 07/25/2005 04:30:27 </FONT><BR><FONT size=3D2>> PM: = </FONT><BR><FONT=20 size=3D2>> > > The WS-RM protocol itself is an AtLeastOnce = protocol as=20 </FONT><BR><FONT size=3D2>> > > observed between the RMS and = RMD.=20 </FONT><BR><FONT size=3D2>> > </FONT><BR><FONT size=3D2>> = > Let's make=20 a note of this! If this is the case, then how is = </FONT><BR><FONT=20 size=3D2>AtMostOnce </FONT><BR><FONT size=3D2>> > an option as = some messages=20 may not be delivered. Sure RMD can throw </FONT><BR><FONT = size=3D2>>=20 messages </FONT><BR><FONT size=3D2>> > away but then it can do = whatever it=20 wants with the messages. </FONT><BR><FONT size=3D2>> > = </FONT><BR><FONT=20 size=3D2>> > To my mind, AtMostOnce is not 'reliable' messaging. = </FONT><BR><FONT size=3D2>> > </FONT><BR><FONT size=3D2>> = > And if you=20 want AtMostOnce why build the apparatus of a RMS and RMD = </FONT><BR><FONT=20 size=3D2>> > and starting sequences etc. Why not just send = messages=20 and be done </FONT><BR><FONT size=3D2>with </FONT><BR><FONT = size=3D2>> it.=20 </FONT><BR><FONT size=3D2>> > They may or may not get there, but = that's=20 the protocol. </FONT><BR><FONT size=3D2>> > </FONT><BR><FONT = size=3D2>>=20 > All the best, Ashok </FONT><BR><FONT size=3D2>> > = </FONT><BR><FONT=20 size=3D2>> > </FONT><BR><FONT size=3D2>> > > = -----Original=20 Message----- </FONT><BR><FONT size=3D2>> > > From: = Christopher B Ferris=20 [<A = href=3D"mailto:chrisfer@us.ibm.com";>mailto:chrisfer@us.ibm.com</A>]=20 </FONT><BR><FONT size=3D2>> > > Sent: Monday, July 25, 2005 = 1:08 PM=20 </FONT><BR><FONT size=3D2>> > > To: Doug Davis = </FONT><BR><FONT=20 size=3D2>> > > Cc: Anish Karmarkar; tom@coastin.com; wsrx=20 </FONT><BR><FONT size=3D2>> > > Subject: Re: [ws-rx] NEW = ISSUE:=20 semantics of "at most once" </FONT><BR><FONT size=3D2>> > > = delivery=20 assurance </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>>=20 > > Doug is exactly right. I thought I had made this point clear = </FONT><BR><FONT size=3D2>> > > in my overview presentation = at the F2F.=20 </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>> > >=20 The WS-RM protocol itself is an AtLeastOnce protocol as = </FONT><BR><FONT=20 size=3D2>> > > observed between the RMS and RMD. = </FONT><BR><FONT=20 size=3D2>> > > That means that the RMD must sucessfully = receive each=20 message </FONT><BR><FONT size=3D2>> > > in the sequence at = least once.=20 </FONT><BR><FONT size=3D2>> > > That means that the RMS is = responsible=20 to retransmit any </FONT><BR><FONT size=3D2>> > > message = that is=20 unacknowledged (within the relevant intervals, etc.) </FONT></P> <P><FONT size=3D2>> > > </FONT><BR><FONT size=3D2>> > = > The DA=20 does not effect what goes on the wire. It is a </FONT><BR><FONT = size=3D2>>=20 > > contract between the RMD and AD logical components. For=20 </FONT><BR><FONT size=3D2>> > > AtMostOnce, the RMD is = permitted to=20 "drop" messages (e.g. </FONT><BR><FONT size=3D2>> > > in the = case where=20 the </FONT><BR><FONT size=3D2>> > > RMS has a limited store = for=20 unprocessed messages and it wants </FONT><BR><FONT size=3D2>> > = > to=20 effect a LIFO or FIFO algorithm to drop one or more of the = </FONT><BR><FONT=20 size=3D2>> > > received (and acknowledged) messages on the = floor.=20 </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>> > >=20 I have heard arguments that AtLeastOnce as a DA between RMD = </FONT><BR><FONT=20 size=3D2>> > > and AD makes no sense as there is already a = need for the=20 RMD </FONT><BR><FONT size=3D2>> > > to check for duplicates, = etc.=20 Whatever... </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT=20 size=3D2>> > > I think that for the most part, the DA that = will have=20 the </FONT><BR><FONT size=3D2>> > > most use will be = ExactlyOnce, but=20 there are valid use cases </FONT><BR><FONT size=3D2>> > > = where one=20 could certainly envisage AtMostOnce being quite relevant. = </FONT><BR><FONT=20 size=3D2>> > > </FONT><BR><FONT size=3D2>> > > To = Anish's point,=20 The use and purpose of Nacks is to optimize </FONT><BR><FONT = size=3D2>> >=20 > the protocol by taking an optimistic view of the inherent=20 </FONT><BR><FONT size=3D2>> > > reliability of the network. = e.g. the=20 frequency of acks could </FONT><BR><FONT size=3D2>> > > be = tuned way=20 down and nacks used to compensate for when the </FONT><BR><FONT = size=3D2>>=20 > > RMD knows it wants a particular message to be retransmitted. = </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>> > >=20 For the protocol to complete "correctly", a </FONT><BR><FONT = size=3D2>> >=20 > SequenceAcknowledgement with AcknowledgementRange elements=20 </FONT><BR><FONT size=3D2>> > > covering the complete range = of=20 MessageNumbers for the </FONT><BR><FONT size=3D2>> > > = Sequence MUST be=20 received by the RMS. </FONT><BR><FONT size=3D2>> > > = </FONT><BR><FONT=20 size=3D2>> > > A Nack is not an Ack. Just because the RMS = receives a=20 Nack </FONT><BR><FONT size=3D2>> > > does not mean by any = stretch of=20 the imagination that the </FONT><BR><FONT size=3D2>> > > = resultant=20 retransmission of the message will be successfully </FONT><BR><FONT=20 size=3D2>> > > received by the RMD. Of course the RMS is = required to=20 respond </FONT><BR><FONT size=3D2>> > > to successive Nacks = of the same=20 message. </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>>=20 > > In the case when the RMS does not have the message to be=20 </FONT><BR><FONT size=3D2>> > > retransmitted, then the = Sequence must=20 be terminated by the sender. </FONT><BR><FONT size=3D2>> > >=20 </FONT><BR><FONT size=3D2>> > > Cheers, </FONT><BR><FONT = size=3D2>>=20 > > </FONT><BR><FONT size=3D2>> > > Christopher Ferris=20 </FONT><BR><FONT size=3D2>> > > STSM, Emerging e-business = Industry=20 Architecture </FONT><BR><FONT size=3D2>> > > email: = chrisfer@us.ibm.com=20 </FONT><BR><FONT size=3D2>> > > blog: <A=20 href=3D"http://webpages.charter.net/chrisfer/blog.html"=20 target=3D_blank>http://webpages.charter.net/chrisfer/blog.html</A>=20 </FONT><BR><FONT size=3D2>> > > phone: +1 508 377 9295 = </FONT><BR><FONT=20 size=3D2>> > > </FONT><BR><FONT size=3D2>> > > Doug=20 Davis/Raleigh/IBM@IBMUS wrote on 07/25/2005 03:09:17 PM: = </FONT><BR><FONT=20 size=3D2>> > > </FONT><BR><FONT size=3D2>> > > >=20 </FONT><BR><FONT size=3D2>> > > > Hi, </FONT><BR><FONT = size=3D2>>=20 > > > No matter what the DA is, any unACK'd message needs to = be=20 resent. </FONT><BR><FONT size=3D2>> > > > DAs have no = impact on the=20 protocol itself. </FONT><BR><FONT size=3D2>> > > > thanks, = </FONT><BR><FONT size=3D2>> > > > -Doug </FONT><BR><FONT = size=3D2>>=20 > > > </FONT><BR><FONT size=3D2>> > > > = </FONT><BR><FONT=20 size=3D2>> > > </FONT><BR><FONT size=3D2>> > > >=20 </FONT><BR><FONT size=3D2>> > > > Anish Karmarkar=20 <Anish.Karmarkar@oracle.com> </FONT><BR><FONT size=3D2>> > = > >=20 07/25/2005 01:11 PM </FONT><BR><FONT size=3D2>> > > >=20 </FONT><BR><FONT size=3D2>> > > > To </FONT><BR><FONT = size=3D2>>=20 > > > </FONT><BR><FONT size=3D2>> > > > = tom@coastin.com=20 </FONT><BR><FONT size=3D2>> > > > </FONT><BR><FONT = size=3D2>> >=20 > > cc </FONT><BR><FONT size=3D2>> > > > = </FONT><BR><FONT=20 size=3D2>> > > > wsrx <ws-rx@lists.oasis-open.org>=20 </FONT><BR><FONT size=3D2>> > > > </FONT><BR><FONT = size=3D2>> >=20 > > Subject </FONT><BR><FONT size=3D2>> > > > = </FONT><BR><FONT=20 size=3D2>> > > > Re: [ws-rx] NEW ISSUE: semantics of "at = most once"=20 delivery </FONT><BR><FONT size=3D2>> > > assurance = </FONT><BR><FONT=20 size=3D2>> > > > </FONT><BR><FONT size=3D2>> > > = >=20 </FONT><BR><FONT size=3D2>> > > > </FONT><BR><FONT = size=3D2>> >=20 > > </FONT><BR><FONT size=3D2>> > > > Two related = questions=20 that need to be answered are: </FONT><BR><FONT size=3D2>> > > = > can=20 a RM receiver send a NACK in case of AtMostOnce DA? If = </FONT><BR><FONT=20 size=3D2>> > > yes, what is </FONT><BR><FONT size=3D2>> = > > >=20 the RM sender supposed to do when it receives such a NACK and it=20 </FONT><BR><FONT size=3D2>is </FONT><BR><FONT size=3D2>> > > = > never=20 going to retransmit the message (as it has already </FONT><BR><FONT=20 size=3D2>> > > thrown away the </FONT><BR><FONT size=3D2>> = > >=20 </FONT><BR><FONT size=3D2>> > > > message) -- i.e. to = prevent the RM=20 receiver from NACKing </FONT><BR><FONT size=3D2>> > > the = message=20 </FONT><BR><FONT size=3D2>> > > > repeatedly, should the = RM sender=20 send a specific fault? </FONT><BR><FONT size=3D2>> > > >=20 </FONT><BR><FONT size=3D2>> > > > -Anish </FONT><BR><FONT=20 size=3D2>> > > > -- </FONT><BR><FONT size=3D2>> > = > >=20 </FONT><BR><FONT size=3D2>> > > > Tom Rutt wrote: = </FONT><BR><FONT=20 size=3D2>> > > > > *Title*: Semantics of "At most = once"=20 Delivery assurance. </FONT><BR><FONT size=3D2>> > > > > = </FONT><BR><FONT size=3D2>> > > > > *Description*:=20 </FONT><BR><FONT size=3D2>> > > > > The semantics of = the "at most=20 once" delivery assurance </FONT><BR><FONT size=3D2>> > > are = not clear.=20 </FONT><BR><FONT size=3D2>> > > > > </FONT><BR><FONT = size=3D2>>=20 > > > > One interpretation is that at most once implies = that the=20 </FONT><BR><FONT size=3D2>> > > sender is not = </FONT><BR><FONT=20 size=3D2>> > > </FONT><BR><FONT size=3D2>> > > > = >=20 required to retransmit mesages which are not acked. </FONT><BR><FONT=20 size=3D2>> > > > > </FONT><BR><FONT size=3D2>> > = > >=20 > *Justification*: </FONT><BR><FONT size=3D2>> > > > = > It is=20 important to clarify whether the sender must retransmit = </FONT><BR><FONT=20 size=3D2>> > > > > unacknowledged messages when the "at = most=20 once" delivery </FONT><BR><FONT size=3D2>> > > assurance is=20 </FONT><BR><FONT size=3D2>> > > in </FONT><BR><FONT = size=3D2>> >=20 > > > use. </FONT><BR><FONT size=3D2>> > > > > = </FONT><BR><FONT size=3D2>> > > > > *Target*: (core | = soap | wsdl=20 | policy | schema | all) </FONT><BR><FONT size=3D2>> > > > = > all=20 </FONT><BR><FONT size=3D2>> > > > > </FONT><BR><FONT = size=3D2>>=20 > > > > *Type: *(design | editorial) </FONT><BR><FONT = size=3D2>>=20 > > > > design </FONT><BR><FONT size=3D2>> > > = > >=20 </FONT><BR><FONT size=3D2>> > > > > *Proposal*: = </FONT><BR><FONT=20 size=3D2>> > > > > </FONT><BR><FONT size=3D2>> > = > >=20 > Clarify the semantics. There are at least three possible=20 </FONT><BR><FONT size=3D2>> > > semantics </FONT><BR><FONT = size=3D2>>=20 > > > > associated with "at most once" </FONT><BR><FONT=20 size=3D2>> > > > > </FONT><BR><FONT size=3D2>> > = > >=20 > proposal 1) at most once means that the sender will never=20 </FONT><BR><FONT size=3D2>> > > retransmit a </FONT><BR><FONT = size=3D2>> > > </FONT><BR><FONT size=3D2>> > > > = >=20 message, regardless of whether it is acknolweged by the = </FONT><BR><FONT=20 size=3D2>> > > destination. </FONT><BR><FONT size=3D2>> = > > >=20 > </FONT><BR><FONT size=3D2>> > > > > Proposal 2) = The sender=20 may retransmis messages, but is </FONT><BR><FONT size=3D2>> > = > not=20 required to </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT=20 size=3D2>> > > > > to so, however the destination = will not=20 deliver duplicates </FONT><BR><FONT size=3D2>> > > > >=20 </FONT><BR><FONT size=3D2>> > > > > Proposal 3) the = sender must=20 retransmit messages, however the </FONT><BR><FONT size=3D2>> > = >=20 destination </FONT><BR><FONT size=3D2>> > > > > may = drop messages=20 in times of resource saturation, but will </FONT><BR><FONT = size=3D2>never=20 </FONT><BR><FONT size=3D2>> > > > > deliver a = duplicate.=20 </FONT><BR><FONT size=3D2>> > > > > </FONT><BR><FONT = size=3D2>>=20 > > > > *Related issues*: </FONT><BR><FONT size=3D2>> = > >=20 > > Issue 9 </FONT><BR><FONT size=3D2>> > > > >=20 </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>> > >=20 </FONT><BR><FONT size=3D2>> > > </FONT><BR><FONT = size=3D2>> >=20 </FONT><BR><FONT size=3D2>> > = </FONT></P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C59187.4F86E942--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]