ebxml-msg — archive

[System]

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" <david.burdett@commerceone.com> on 09/12/2001 02:55:26 PM To: "'David Fischer'" <david@drummondgroup.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org> 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