Hi Jon,
Thanks a lot for the quick reply.
I am yet to verify that if there is data traffic flowing on a
given link, the link stays in WW state. I shall verify this and post
any questions I have.
Another question which came to me is that if not a single packet
is received till link tolerance time, we move to RU [Reset-Unknow]
state. Till what time we maintain this state for a link? The other
node might have been removed from the network so till what time we
keep sending state messages?
Thanks & Regards,
Bharat
On 10/24/07, Jon Paul Maloy <[EMAIL PROTECTED]> wrote:
> Hi Bharat,
> See my answers below.
>
> Regards
> ///jon
>
> Bharat Joshi wrote:
> > Hi,
> >
> > I have a question on link-state events in TIPC. I understand that
> > a link state starts with Unknown-Unknown and becomes Working-Working
> > when the link is UP.
> >
> > I see a timer is created for timing out link state. This is set
> > to continuty interval which is around 250ms.
> >
> > Now I have enabled link debugs and see a link toggelling between
> > WW and WU with timeout events. Following debugs are seen:
> >
> > WW/TIM -> WU
> > WU/TRF-ACT -> WW
> > RR/ TIM
> >
> > I also see that when link is in working-working state and a
> > timeout event happens, we sent a 'State' message which when received
> > in Working-Unknown state by the peer, it moves to Working-Working
> > state.
> >
> > I am a little confused here. Is this mechanism used to verify if
> > link is up or not?
> >
> Yes, it is.
> A link endpoint remains in WW as long as it receives packets of any type
> from the peer endpint . If it hasn't received anything during a whole
> continuation interval, it sets the endpoint state to WU, meaning
> "own endpoint is working, but peer endpoint's state is unknown", and
> then sends out a 'state' message with the 'probe' bit set.
> This bit forces the other endpoint to respond immediately, so the link
> can be set back to WW. Note that the link is still usable when
> one of its endpoints is in WU, - packets can be sent and received as
> normal, and any packet reception will put the link back to WW.
> > Also It seems to me that 250 ms for continuty interval may be
> > small. What value people think could be a good value for this?
> >
> This value is only indirectly configurable. What you configure is "link
> tolerance",
> which is set by default to 1500 ms for Ethernet. The continuity interval is
> calculated as 1/4 of this. This is to allow the timer to expire several
> times,
> and hence send a number of probes within a tolerance interval, before
> the link is
> declared failed(=RU). If we relied on only one unresponde probe, the link
> would end up being reset unnecessarily, e.g. during periods of net
> congestion
> and high loss rate.
> > Thanks,
> > Bharat
> >
> > PS: I am not on the TIPC list so it would be great if you can reply to
> > this id as well.
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > tipc-discussion mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/tipc-discussion
> >
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
