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