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:
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
"Vikas Deolaliker" <> 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:]
> Sent: Friday, July 22, 2005 12:28 PM
> To:
> 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:
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
>
> "Vikas Deolaliker" <> 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
> >
> >
>
>
