[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] NEW ISSUE: semantics of "at most once" delivery assur ance
Tom wrote: > Use case: a receiver might want to apply a monotonic filter on teh > incoming stream of messag ids for a sequence of stock quotes. > . It does not care if it loses a quote every now and then, but does not > want to receive the same or an older one than one it has already received. > > However, at most once, with no other assurances seems to be a weak > assurance, which should not require the sender to retransmit unacked > messages if it does not want to. However, the protocol as specified would never be able to complete a sequence if there are lost messages from the RMD perspective and the RMS is not retransmitting them. As I have said repeatedly, the protocol is an *AtLeastOnce* protocol between RMS and RMD. Period. You can use this to effect other levels of DA at the RMD in accordance with its contract with the AD. However, that does not change the oblications on the part of the RMS and RMD with regards to the protocol. Unacknowledged messages MUST be retransmitted or else the Sequence will never be able to be closed gracefully. Cheers, Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com blog: http://webpages.charter.net/chrisfer/blog.html phone: +1 508 377 9295 Tom Rutt <tom@coastin.com> wrote on 07/26/2005 05:59:55 PM: > Christopher B Ferris wrote: > > >Now, for my comments. > > > >Cheers, > > > >Christopher Ferris > >STSM, Emerging e-business Industry Architecture > >email: chrisfer@us.ibm.com > >blog: http://webpages.charter.net/chrisfer/blog.html > >phone: +1 508 377 9295 > > > >"Bergersen, Rebecca" <Rebecca.Bergersen@iona.com> wrote on 07/26/2005 > >11:06:09 AM: > > > > > > > >>Chris, > >> > >>I disagree. 'At Most' does not have the same semantics as 'Exactly'. > >> > >> > > > >I never claimed that it did. > > > > > > > >>'Once' does imply duplicate detection, as you said, but 'At Most' does > >>not imply best effort. It simply means 'maybe fewer but no more than'. > >> > >> > > > >Okay, I'll agree with that characterization as to what it *means*. But in > >practice, > >it is used to imply best effort coupled with duplicate detection. > > > > > > > >>If you think Best Effort should be the semantic, then AtMostOnce should > >>be dropped. A threshold on 'ExactlyOnce' such as you suggest can be set > >>by default at a Very Large Number thereby specifying the absolute best > >>effort with smaller values providing 'good enough effort' at delivering > >>a message exactly once. > >> > >> > > > >When I think of ExactlyOnce, I think of it as meaning, "short of some > >cataclysmic > >event in which either the RMD or AD can not be recovered, or in which the > >AD is decommissioned, the message will be delivered". > > > > > > > The protocol only ensures deliivery if both endpoints are cabable of > fulfilling the oblications associagted with a given DA level. > > Thus, exactly once, means that as long as the protocol machine is > working, that DA level will be met. > > >>That would give you what you want, but for different reasons I'm not > >>convinced that AtMostOnce has any place at all in a "Reliable Message' > >> > >> > > > >As I have said before, the DA is not reflected in the protocol at all. > >It is a function of the contract between the RMD and AD (and possibly > >between the AS and RMS). > > > > > Use case: a receiver might want to apply a monotonic filter on teh > incoming stream of messag ids for a sequence of stock quotes. > . It does not care if it loses a quote every now and then, but does not > want to receive the same or an older one than one it has already received. > > However, at most once, with no other assurances seems to be a weak > assurance, which should not require the sender to retransmit unacked > messages if it does not want to. > > Tom Rutt > > > > > > >>protocol. AtMostOnce (maybe zero but no more than one) implies the > >>message can be lost or dropped without significant consequence. As a > >>result, the sender can send it and forget it and the receiver can deal > >>with it if it gets it (and avoid more than one copy being given to the > >>application) but not worry about it if it doesn't get it. If less than > >>one is acceptable, there is no requirement for reliability here. This > >>type of message can be sent outside the 'Reliable Message' protocol. > >> > >> > > > >Which gets back to why I think that in the context of RM, best effort IS > >implied for AtMostOnce. Otherwise, I would agree. > > > > > > > >>Regards, > >>Rebecca Bergersen > >>Principal Architect, Middleware Standards > >>rebecca.bergersen@iona.com > >>------------------------------------------------------- > >>IONA Technologies > >>200 West Street Waltham, MA 02451 USA > >>Tel: (781) 902-8265 > >>Fax: (781) 902-8001 > >>------------------------------------------------------- > >>Making Software Work Together TM > >> > >>-----Original Message----- > >>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > >>Sent: Tuesday, July 26, 2005 6:43 AM > >>To: wsrx > >>Subject: RE: [ws-rx] NEW ISSUE: semantics of "at most once" delivery > >>assur ance > >> > >>Umit, > >> > >>I actually *do* see use cases for AtMostOnce DA observed between the RMD > >> > >>and AD. It relates to > >>best effort with duplicate detection, really. Again, consider an > >>endpoint > >>with constrained resources. > >>It will provide reliable delivery with ExactlyOnce semantics until or > >>unless the aggregate store of > >>unprocessed messages exceeds some threshold. > >> > >>Would I want that level of assurance for deposits to my bank account? > >>Probably not. However, > >>I suspect that there are probably quite a few applications for which a > >>best effort with duplicate > >>detection (AtMostOnce) would be more than adequate to the task. > >> > >>Cheers, > >> > >>Christopher Ferris > >> > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]