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

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

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>