OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Guaranteed duplicate elimination vs. upper bound on delays

Let me jump in briefly, Dan's question about when to delete a Message(ID) from
persistent storage seems to have two answers.  For IMs (VANs) which handle
massive numbers of messages from a large number of sources, this would be a
problem (grow forever) and needs to be addressed.  OTOH, a local system which
keeps only its own (send or receive) I can easily foresee keeping these IDs
virtually forever (or at least until the lawyers say there is a legal reason to
delete -- 7 years?).  Thus failure to detect duplicates might only be a problem
for IMs.


David Fischer
Drummond Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 13, 2001 3:38 PM
To: Dan Weinreb
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: Guaranteed duplicate elimination vs. upper bound on delays


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.



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
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

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.

-- 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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC