[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 Clarify TimeToLive
Actually, you also need to take into consideration that TTL needs to be less than the persistDuration, no? Cheers, Chris "Burdett, David" wrote: > > 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 > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Wednesday, September 12, 2001 8:03 AM > To: ebXML Msg > Subject: RE: T2 Clarify TimeToLive > > >> I think adding this to the spec as a non-normative note is a good idea. > > Very Good. I mostly realized the potential for problems when I realized > this > could cause a recalculation of the signature. I guess the answer is: > > TimeToLive > SendTime + (Retries * RetryInterval) > > David Fischer > Drummond Group. > > -----Original Message----- > From: Burdett, David [mailto:david.burdett@commerceone.com] > Sent: Tuesday, September 11, 2001 11:50 PM > To: 'Arvola Chan'; David Fischer; ebXML Msg > Subject: RE: T2 Clarify TimeToLive > > Currently TimeToLive is defined in section 8.4.6.4 as ... > > The TimeToLive element indicates the time by which a message should be > delivered to and processed by the To Party. > > ... and in section 10.2.3 as ... > > The TimeToLive value indicates the time by which a message should be > delivered to and processed by the To Party. > > What I think you are suggesting is that we provide guidance on how it should > be set. There are two factors which can affect this: > 1. Setting it to a value long enough so that it is longer that the time > required to do all the retries on all the hops between the From and To > Parties. By definition this is not precisely computable. > 2. Setting it to a value that makes sense in a business context, e.g. if > this PO gets there in a day then it is fine. > > I think adding this to the spec as a non-normative note is a good idea. > > David > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Tuesday, September 11, 2001 5:12 PM > To: David Fischer; ebXML Msg > Subject: Re: T2 Clarify TimeToLive > > David: > > I agree with you that we need to clarify in the spec how TimeToLive > should be set for a given message. For reliably delivered messages, > I don't think we want to reset the the TimeToLive on every retry. It just > incurs unnecessary signature recomputation overhead. I would suggest setting > TimeToLive to current time (for the initial attempt) + (retry + 1) * > retryInterval. This must also be less than the receiver MSH's persist > duration. > > For messages delivered by BestEffort, the TimeToLive can either be > omitted, or perhaps set to the current time plus the > RequestingBusinessActivity's or RespondingBusinessActivity's > timeToReceiveAcknowledgment. > > Cheers, > -Arvola > > -----Original Message----- > From: David Fischer <david@drummondgroup.com> > To: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Date: Tuesday, September 11, 2001 4:52 PM > Subject: T2 Clarify TimeToLive > > I don't know if this is a problem or not. TimeToLive is a time, not an > interval, and should probably be set to current time plus 1/2 RetryInterval > (half of the round trip from sender to receiver back to sender). Won't this > have to be recalculated each retry? Won't this invalidate the signature? > > Maybe I'm getting the correct value of TimeToLive wrong? What in the world > should this be? Maybe this is more along the lines of "This PO is valid for > 30 > days" so this value should be set to current time plus 30 days? In any > case, we > probably need to clarify the spec. > > Regards, > > David Fischer > Drummond Group. > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;One Network Drive;Burlington;Ma;01803-0903;USA version:2.1 email;internet:chris.ferris@east.sun.com title:Senior Staff Engineer fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC