[Tinyos-help] Snooping more than it should
Pedro Almeida
pedralm at gmail.com
Thu Jun 21 11:24:02 PDT 2007
Phil;
Thanks for the help!
After all I can't use the sequence number to prevent the flooding, as
they're unique for each mote...
But what I found strange was that the receiving blink kept accusing that
flurry or received packets, whilst the sending blink on the other motes
wasn't blinking any faster.
Anyway, it seems I can't help the situation and need to ensure the existance
of the root node.
Thank you!
Pedro
On 6/21/07, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Jun 20, 2007, at 6:00 PM, Pedro Almeida wrote:
>
> > Hello, Phil!
> >
> > I supposed it to be so, but the message that ends being snooped is
> > the repetition of the actual normal package that was last sent by
> > the TestNetwork nodes. I can see it not only from the contents of
> > the payload, but from the sequence number, that is the same during
> > the frenzy blinking and returns to normal counting once the root
> > note goes back up.
> > Shouldn't the messages from the route discovery be any different?
> > If they were any different, I could filter the return so the serial
> > port wouldn't be flooded (I guess I can do that as well, with the
> > sequence number, though...).
> >
>
> Ah, good point. The CTP link estimator uses data traffic to probe
> links. If you look at the ETX field of the packets you should see
> them going up. Basically, loops manifest as flurries of packets to
> discover and repair the loop. Since there is no possible repair, this
> approach runs into issues. Basically, CTP tries really hard to
> deliver packets, and so doesn't drop them except in extreme
> situations. So the nodes keep on sending...
>
> Phil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070621/f6de3e34/attachment.html
More information about the Tinyos-help
mailing list