That's still not good enough. We do not define the actual timeout that the
MSH uses to determine when to retry. That timeout could be longer or
shorter than RetryInterval. We also do not say whether RetryInterval is
measured from the sending of the message or the expiration of the MSH
timeout. I recommend defining the MSH timeout and adding it to the CPA.
In addition, the send time is really unknown since it depends on properties
of the network as well as MSH processing times, which are system dependent.
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
*************************************************************************************
"Burdett, David" <> on 09/12/2001 02:55:26 PM
To:
"'David Fischer'" <>, ebXML Msg
<>
cc:
Subject: RE: T2 Clarify TimeToLive
Almost. I think that really it should be ...
TimeToLive
> Sum Of [SendTime + (Retries * RetryInterval)] over
all hops + some percentage
As you cannot always know how many hops there will be nor how fast each hop
would be, you really should make TimeToLive a lot more than the figure
above. In practice, I think that feedback from actual use is likely to be
the most effective way to work out the values to use.
David
