RE: Reliable messaging

One way you might be able to determine that a message was NOT received,
would be to send a query to the destination that should have receieved the
message to ask if they had received it.
 
However you still have the problem that the destination might still receive
the message after they have sent a response to your query indicating that
they had not. In this case, what should the behavior of the destination be?
 
David

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:[email protected]]
Sent: Thursday, August 29, 2002 1:29 PM
To: 'Christopher B Ferris'; Mark Baker
Cc: Burdett, David; [email protected]; [email protected]
Subject: RE: Reliable messaging


I know of mechanisms that, if successful, will assure the sender that the
message HAS been received.  I do not know of any mechanism that will allow
the sender to know that the message has NOT been received.  The ebXML spec
most certainly does not.  So I believe that the word "whether" below is
inappropriate.
 
-----Original Message-----
From: Christopher B Ferris [mailto:[email protected]] 
Sent: Thursday, August 29, 2002 3:25 PM
To: Mark Baker
Cc: Burdett, David; [email protected]; [email protected]
Subject: Re: Reliable messaging



#1 in my definition reads: 

the ability of a sender to be able to determine whether a given 
message has been received by its intended receiver ... 

It doesn't speak of a mechanism, but there are many means of achieving this.


Cheers, 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: [email protected]
phone: +1 508 234 3624 

[email protected] wrote on 08/29/2002 04:01:41 PM:

> 
> On Thu, Aug 29, 2002 at 11:48:41AM -0700, Burdett, David wrote:
> > I like your definitions,  however, they do not address what I think is
the
> > certainty that although you can be sure a message was received, you can
> > never be absolutely sure that it was not.
> 
> How can you be sure that a message was received?  Because there's always
> a chance that the response to a message doesn't make it, and leaves the
> two parties out of synch (i.e. two army problem).
> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               [email protected]
> http://www.markbaker.ca        http://www.idokorro.com
>