Re: Need volunteer to draft definition ofreliablemessaging,wasRE:reliable messaging - hop by hop

[christopher ferris <chris.ferris@east.sun.com>]

David,

This has been my point all along. Although I disagree as to "the only".

Fairlure to receive a DFN is a fairly good assurance, not proof but possibly
good enough for some. Receipt of the expected response message is another
form of proof. If the response is typically generated with little or
no delay, and the business request has a finite ttl, then maybe
that's good enough.

Also, even if the message is delivered with BestEffort, a receipt
(NRR) may be required to "prove" that the message was received.

I have not been arguing against a delivery receipt, just its
role (or in my case its non-role) in RM protocol.

Cheers,

Chris
David Fischer wrote:
> 
>         End-to-end acks don't ensure success, they can only report it.
> 
> The lack of an end-to-end ack does not necessarily mean failure but the arrival
> of an end-to-end ack is an assurance/report that there was success -- it is the
> only assurance.
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Tuesday, September 04, 2001 1:24 PM
> To: David Fischer
> Cc: Dan Weinreb; mwsachs@us.ibm.com; ebxml-msg@lists.oasis-open.org
> Subject: Re: Need volunteer to draft definition of reliable
> messaging,wasRE:reliable messaging - hop by hop
> 
> David Fischer wrote:
> >
> > Dan, Absolutely correct.  The ONLY way for ensuring success is end-to-end
> > reciepts/acks.  While this is obviously true for SMTP, it is also true for ALL
> > messaging methods.  Some methods are more reliable so this is not as intuitive
> > but it is still true.
> >
> > Say for example, I send an HTTP request and then my connection is dropped.
> > Since DFN and Acks are also governed by Retries then if I stay offline for a
> > period greater than the Retries * RetryInterval for the DFN or Acks, I will
> > never receive either.  Lack of a failure is not success.  We cannot guarantee
> > either an Ack or DFN on synchronous transports.  The only means for
> determining
> > success is an end-to-end Receipt/Ack.  Whatever we do in the middle is just to
> > increase reliability.
> 
> Acks are not governed by retries since they are not sent reliably.
> If a message is not acknowledged, then it is resent by the sending
> MSH after the retryInterval has expired without receipt of the Ack.
> The receiving node when it receives a duplicate message, would then
> respond with the Ack.
> 
> If the sending node never receives an Ack, it would then generate a
> DFN "message" and deliver it, in some implementation specific manner
> to the "From Party" which would then take some (external) action
> (like call the administrator of the receiving node to find out what
> the problem might be).
> 
> A DFN may be (and probably should be) delivered reliably, in which case
> it would be retried and acknowledged by the original sending MSH. If a
> DFN were never acknowledged, then again, some external action would need
> to be taken. From the perspective of an intermediary MSH node, a DFN is no
> different
> than any other message. I see no reason why a failure to deliver a DFN can't
> result in its own DFN in the reverse direction. Eventually, someone will
> get this and have to act upon it.
> 
> As for end-to-end receipts/acks/whatever, these are just messages. They
> cannot provide any greater reliability in and of themselves. If they cannot
> be delivered, they cannot be delivered. It is as simple as that. If a NRR/DR
> is not received, all that the sending party can infer is that it did not
> receive an NRR/DR. Nothing more, nothing less. The message may well have
> reached its destination and it may well have been processed.
> 
> It should be noted that what we're talking about here are extreem
> edge cases in any event. If the situation is such that either a delivery
> receipt or a DFN are not received by the From Party is extraordinarily
> remote. In fact, with reliable messaging, it is extraordinarily remote
> case that a message cannot be delivered after the stipulated retries.
> It points to something that the software cannot deal with without some manner of
> human intervention.
> 
> End-to-end acks don't ensure success, they can only report it.
> 
> Cheers,
> 
> Chris
> 
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> > Sent: Tuesday, September 04, 2001 7:24 AM
> > To: mwsachs@us.ibm.com
> > Cc: david@drummondgroup.com; rberwanger@btrade.com;
> > ebxml-msg@lists.oasis-open.org
> > Subject: Re: Need volunteer to draft definition of reliable
> > messaging,was RE:reliable messaging - hop by hop
> >
> > I agree.  We should allow the use of SMTP, and end-to-end reliable
> > messaging should take care of message losses inside SMTP.  This is a
> > special case of the principle that the network should be considered
> > capable of losing messages in general, just as TCP assumes that
> > a packet sent via IP can always be lost.
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard