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