[Tinyos-devel] Request for comments: TEP-118

[Avinash Sridharan]

I apologize if I am raising this issue a bit late (and it is tangential to
the discussion between Phil and Om).

I was going through the description of TEP 118 and one thing that
immediately struck me was to use the dissemination interface 'primarily' for
querying in sensor networks ( this has been highlighted in the
introduction). After a closer look I realised that the interface is designed
to purely support flooding based querying mechanisms and not necessarily
mechanisms such as random waslks, acquire, expanding rin search  etc .. .
Moreover, the primary focus seems to be on applications such as "Deluge" and
not  querying.

Should the above fact be made explicit or am I being a bit picky over here ?

Thanks,
Avinash

On Feb 5, 2008 11:25 PM, Omprakash Gnawali <gnawali at usc.edu> wrote:

> On Feb 5, 2008 9:00 AM, Philip Levis <pal at cs.stanford.edu> wrote:
> >
> > On Feb 4, 2008, at 11:53 PM, Omprakash Gnawali wrote:
> >
> > >>> If multiple components can subscribe to updates for the same key,
> > >>> how
> > >>> will signaling the updates work?
> > >>>
> > >>
> > >> As per nesC wiring rules, it would be a simple fan-out. There's no
> > >> return value, so a combine function isn't needed.
> > >>
> > >
> > > Should we then disallow (in the writeup) set or change from within
> > > changed. Or maybe that is an obvious bad habit.
> >
> > Disallow might be too strong: strongly discourage makes more sense,
> > explaining why. The worst case is you have 2+ components fighting for
> > what the value should be. It would go like this:
> >
> > A changes value.
> > update signaled
> >    A handles event
> >    B handles event, changes value
> > update signaled
> >    A handles event, sees it's different, changes value
> >    B handles event, sees it's different, changes value
> > update signaled
> >    A handles event, sees it's different, changes value
> >    B handles event, sees it's different, changes value
> >
> > etc., ad infinitum.
> >
>
> And here is one scenario that seems like a problem, but in my opinion
> it is not a problem: In the first update, if A changes the value, by
> the time B handles the update, the value has already changed but
> losing updates like that is fine.
>
> - om_p
>  _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>



-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080207/635fc7a2/attachment.htm