[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
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]