[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL)
Paolo Clarification on why we need a Message Expiration time and an upper bound (=absolute maximum) Message Duration time: 1. We should redefine ttl as the latest (actual) time, that the message can be delivered to the WS-RM client. [Let's rename it "message expiration time," instead of TTL]. This time includes message delivery/ transit time + retransmission time (if necessary)+ message persist (=store and hold) time at the WS-RM receive entity (if necessary). The WS-RM receive entity may have to be persist (=store) the received message up to the message expiration time if the WS-RM client is busy/ unavailable/used local (=inter-layer) flow control. 2. I proposed that "Maximum duration" should be a configuration/ subscription parameter that is urgently needed so we have an upper bound on Message Expiration time. This would prevent very long hold/persist and/or message delivery times. Message Expiration time= current time (at the sender) + maximum duration of this message (which is less than the absolute maximum duration time parameter set at subscription/ configuration time). 3. More importantly, if the WS-RM receive entity receives a message that has expired, it should be discarded. alan ----- Original Message ----- From: "Jun Tatemura" <tatemura@ccrl.sj.nec.com> Date: Wed, 9 Jul 2003 10:47:13 -0700 To: <Paolo.Romano@dis.uniroma1.it>, <wsrm@lists.oasis-open.org> Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL) > Paolo, > Let me state my understanding on what Alan said. > > > A simple question: why do we distinguish between maximum duration (i.e. maximum > > time in the persistent storage) and ttl (i.e. maximum time before the message is > > delivered to the final application, please correct me if I am wrong)? > > Why we do not just use one of them? I mean, if we define ttl as the maximum > > time before the message is delivered, then it will have to be persisted up to > > that time. What are the advantages of having both of them? Why should a message > > be persisted longer than ttl? The receiving rm-processor should anyway raise a > > fault. > > Maximum duration means that the receiver can not (will not) persist a message any longer > than it due to some limitation in its implementation. It indicates the upper limit of TTLs based on > the receiver's capability. For example, the receiver may not want to preserve a message for 100 year. > Such requests should be rejected (or ignored). The sender and the receiver should have agreement on > the maximum duration as one of the features of the receiver's service level. > > TTL (or Expiration Time), on the other hand, is specified for each message based on the > sender's business needs. > > Alan's 2(a) error means that, when the expiration time of a message is larger than a threshold > (i.e., max duration + current time), the receiver can say "hey, I can not hold your message that long." > (Alternative way is that the receiver silently ignores the TTL requested and sets a (default) TTL based > on its maximum duration) > > So, a message will not be persisted longer than TTL in any case. > > Regards, > Jun > > > > Alan Weissberger <ajwdct@technologist.com> ha detto: > > > > > > > All > > > > > > > > The Issues List indicates that Rel 44 Duplicate Elimination and Time to Live > > > (TTL)is CLOSED, but on last week's conference call I believe we decided to pursue > > as > > > follows: > > > > > > > > New Spec issue: What should receiver do if it receives an Expired message? > > > > Related issue: better define semantics of TTL > > > > > > > > > ------------------------------------------------------------------------------------ > > > > > > > > 1. Time To Live > > > > > > > > I always wondered how the receiver knows that the message it just received has TTL > > > expired? > > > > > > > > I was told by a colleague that TTL is not the duration of the message (as one > > > would expect from its meaning in networking), but it's the actual time that the > > > message expires. If that is the case than it should be renamed "message expiration > > > time." (It's like the "Expires" entity of an HTTP header) > > > > > > > > We make the following assumptions on the sender and receiver that can handle TTL > > > (or Expiration Time): > > > > > > > > (a) They have agreed on the Maximum Duration for expiration (the receiver does not > > > want to keep messages forever). This could be done as part of a subscription/SLA > > or > > > as a capability exchange/configuration message sequence at start-up time (i.e. > > prior > > > to sending WS data messages). > > > > > > > > Suggest we include this Maximum Duration value into the list of configurable > > > parameters. > > > > > > > > (b) Their clocks are properly synchronized to avoid pre-mature or late expiry of > > > the message (i.e. the time difference between sender and receiver clocke should be > > > less than some agreed upon threshold) > > > > > > > > > ------------------------------------------------------------------------------------ > > > > > > > > 2. What should receiver do if it receives an expired message > > > > > > > > (a) First, if the receiver detects the Message Expiration time (now known as TTL) > > > is greater than the agreed upon Maximum Duration, then the message should be > > > discarded and a Fault Message generated with Cause Code= Coding error in Message > > > Expiration field. This is detected by the receiver when Message Expiration (of > > > received message) - Current Time > Max duration. > > > > > > > > (b) Second, if the receiver detects Message Expiration time is later than current > > > time, then message should be discarded and Fault Message generated with Cause Code= > > > Message arrived after Expiration time. > > > > > > > > Unresolved Issue: If the message exchange pattern is 1-way only, then should we > > > still allow fault messages to be sent in opposite direction? In other words, > > permit > > > 1 way SOAP message transfer, but require 2-way control/ error messaging at WS-RM > > > layer (above SOAP). > > > > > > > > > > > > Alan Weissberger > > > > NEC Labs America > > > > 1 408 863 6042 voice > > > > 1 408 863 6099 fax
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]