Re: Need volunteer to draft definition of reliablemessaging,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. >  >