Re: Guaranteed duplicate elimination vs. upper bound on delays

[Martin W Sachs <mwsachs@us.ibm.com>]

Dan,

I have been doing a lot of thinking about this question lately.  I don't
have good answers but I am starting to think that a lot more attention has
to be paid to the timeouts at various levels, and to agreement on the
timeouts between the From and To parties. I am also begining to think that
the MSH's RM timeout must be exposed and probably be placed in the CPA.
Rules on the relationships among the timeout, retry interval, persist
duration, and time to live seem to be required and must err on the side of
killing a message rather than allowing a duplicate to propagate upward.

As I recall, there is a time to live associated with each IP packet, which
helps TCP manage these things.  I agree that a message service time to live
would help by killing the really long-delayed messages.

One thing is clear.  If reliable messaging can't give an absolute guarantee
that no duplicates will be sent to the application, reliable messaging
isn't onceAndOnlyOnce.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 08/13/2001 04:16:14 PM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:   ebxml-msg@lists.oasis-open.org
cc:
Subject:  Guaranteed duplicate elimination vs. upper bound on delays



I'm not sure whether we are claiming that ebXML reliable messaging
"guarantees" that duplicates will never be passed through to the
receiving application.

It would be hard to actually guarantee, in some sort of 100% sense,
that there is some upper bound on how long a message could be delayed
inside the Internet.  After all, perhaps the message is being sent via
SMTP and some store-and-forward mailer along the line receives the
message and then goes out of service for a few weeks before it gets a
chance to forward the message.

So for any actual reasonable value for persistDuration, it seems
possible that a second, duplicate message might arrive more (much
more) than persistDuration after the time when the first message was
first put into persistent storage, and so the receiving application
could see a duplicate message.

I am not sure how TCP itself deals with this problem.  I seem to
remember that there is supposed to be a realtime delay between closing
a connection on a port, and reusing the port, and presumably there is
an assumption about the maximum lifetime of an Internet packet in the
Internet.

I think it would be possible to solve this problem by requiring the
use of the TimeToLive value so that a message that was very delayed
would be quashed by the receiving MSH before the application could see
it.  But before I go on further, please let me know if I'm making
sense or whether I've overlooked something.

Thanks.
-- Dan

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org