[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] NEW ISSUE: Clarification on base retransmission interval
It wasn't the intent that keepalive messages be sent. The intent was that the timeout would apply in cases where a message was expected. e.g. RMS repeatedly sends message(s) and receives no acknowledgements in the specified interval. Cheers, Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com blog: http://webpages.charter.net/chrisfer/blog.html phone: +1 508 377 9295 "Vikas Deolaliker" <vikas@sonoasystems.com> wrote on 07/26/2005 07:01:48 PM: > > This helps, however, the submission says " If omitted, there is no implied > value". It should ideally take on a default value or everybody will use a > different timeout value. > > Another clarification required in light on this, is Do I now need to send > keep alive messages to keep this InactivityTimeout value from getting too > low? > > I see in submission the following: > > /wsrm:RMAssertion/wsrm:InactivityTimeout/@milliseconds > > Do I have to keep sending these message to keep the session alive longer? > > What if the underlying TCP times out? Can I hold a single RM session over > multiple TCP sessions? > > Thanks > > Vikas > > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Friday, July 22, 2005 12:28 PM > To: ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] NEW ISSUE: Clarification on base retransmission > interval > > Vikas, > > Actually, the two parameters do not share the same or similar semantic. > >From the submission: > /wsrm:RMAssertion/wsrm:InactivityTimeout > A parameter that specifies a period of inactivity for a Sequence. > If omitted, there is no implied value. > > The purpose and intent of this parameter is possibly underspecified, The > intent that the authors (well, certainly > my understanding) had is that a Sequence could be unilaterally terminated > by either the RMS or RMD should there be no > activity against the Sequence for a period of the specified duration. > Thus, should no messages be received by > the RMD for the specified wsrm:InactivityTimeout duration, it **could** > terminate the Sequence at its discretion. > (It does not need to do so). Likewise, should an RMS not receive any > SequenceAcknowledgements for the > specified wsrm:InactivityTimeout duration, despite having attempted to > transmit messages during that > period (hence it was likely expecting them) then it could unilaterally > terminate the Sequence. > > Of course, discretion should be used in selecting a suitable value for > this parameter, probably based on the > expected frequency of activity (and adding a suitably generous margin of > error). However, it is not the intent > that this parameter specify the frequency with which messages are to be > retransmitted by the RMS. > > The intent was to provide a means by which an RMD could reclaim resources > for which it appears that > the corresponding RMS has "left the building", "bit the dust", "rode off > into the sunset" (e.g. possibly come > to a horribly nasty and greusome end). > > Mr. Praline: 'Ello, I wish to register a complaint. > (The owner does not respond.) > > Mr. Praline: 'Ello, Miss? > > Owner: What do you mean "miss"? > > Mr. Praline: I'm sorry, I have a cold. I wish to make a complaint! > > Owner: We're closin' for lunch. > > Mr. Praline: Never mind that, my lad. I wish to complain about this parrot > what I purchased not half an hour ago from this very boutique. > > Owner: Oh yes, the, uh, the Norwegian Blue...What's,uh...What's wrong with > it? > > Mr. Praline: I'll tell you what's wrong with it, my lad. 'E's dead, that's > what's wrong with it! > > Owner: No, no, 'e's uh,...he's resting. > > Mr. Praline: Look, matey, I know a dead parrot when I see one, and I'm > looking at one right now. > > [...] > > Owner: No no! 'E's pining! > > Mr. Praline: 'E's not pinin'! 'E's passed on! This parrot is no more! He > has ceased to be! 'E's expired and > gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! > If you hadn't nailed 'im to the perch 'e'd > be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's > off the twig! 'E's kicked the bucket, > 'e's shuffled off 'is mortal coil, run down the curtain and joined the > bleedin' choir invisibile!! THIS IS AN > EX-PARROT!! > > (Sorry, couldn't resist!) > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > > "Vikas Deolaliker" <vikas@sonoasystems.com> wrote on 07/22/2005 02:39:46 > PM: > > > > > > > *Title*: RM Policy Assertion Model's Base Retransmission Interval > > Clarification Needed > > > > *Description*: > > The RM policy assertion model defines InactivityTimeout and > > BaseRetransmissionInterval. The text in the specification WS-RM Policy > (Page > > 5) implies that these two parameters are essentially serving the same > > purpose i.e. to trigger a retransmit based on a timeout value. If this > is > > the intention, the spec needs to clarify the pecking order for an > > implementation i.e. what if timeout occurs before base retransmission > > interval has expired. > > > > *Justification*: > > There is no obvious case mentioned in the spec that requires two timers > for > > retransmission upon timeout. > > > > *Target*: (core | soap | wsdl | policy | schema | all) > > Policy > > > > *Type: *(design | editorial) > > design > > > > *Proposal*: > > > > 1) Merge the two into one timer called Retransmission Timeout. > > > > *Related issues*: > > > > None > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]