[Tinyos-devel] Fwd: SendNotifier for Iris.

[Geoffrey Werner-Allen]

I agree with David.  I think that the SendNotifier interface is fantastic
and should be standardized.  By putting in this and a few other hooks it
becomes possible to implement a whole host of interesting logic *alongside*
the radio stack instead of having to embed it inside it.  In fact, I would
argue that the SendNotifier interface could be extended in the following
ways:

* something complementary on the receive side. Of course, I can just wire to
the bare receive interface and get every packet, but it's the ordering that
could be a concern if there are services that want a chance to rewrite or
otherwise process packets *before* any higher layers receive them.

* change the way that packet length is handled.  Currently this is passed as
an argument to functions through the Send.send() call chain, but this
prevents SendNotifier listeners from modifying the packet length.  This
could be remedied by moving the header->length assignment that currently
occurs in CC2420CsmaP.nc into CC2420ActiveMessageP.nc and then just passing
the message pointer through the rest of the call chain carrying the length
in the header, meaning that packet length changes done by SendNotifier
listeners are reflected through the rest of the stack.  This may be useful
for others pieces of metadata initialized in CC2420CsmaP.nc as well.

* provide an aboutToTransmit() upcall right before the packet is actually
being written to the wire.  This one is the one I'm least certain about
since, while I know how this could be useful for things like FTSP, I'm not
sure how many other services would use it.  It also becomes tricky because
changing the packet contents on the CC2420 requires wiring to a bunch of
other low-level interfaces which might mean that it becomes as ugly as just
burying it inside the stack itself.  Of course, some applications (like the
one that started this thread) might just want upcalls from this layer
letting them know when messages got sent and not want or need to modify the
packet contents.

Anyway, I just wanted to throw my oar in with David here.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner


On Mon, Nov 17, 2008 at 5:09 PM, David Moss <dmm at rincon.com> wrote:

> Should all applications and protocols use this pattern?  Only if it works
> for most people... all I'm saying is it works exceptionally well for what
> I'm trying to do in my deployments.
>
> If there's a better way to have this much control over outbound messages, I
> think we'd all be open to suggestions.  It also seems like if Ignacio
> really
> wants this interface built in, it's simple enough to implement locally
> without affecting the rest of the world.
>
> -David
>
>
>
> -----Original Message-----
> From: gnawali at gmail.com [mailto:gnawali at gmail.com] On Behalf Of Omprakash
> Gnawali
> Sent: Monday, November 17, 2008 1:37 PM
> To: David Moss
> Cc: Miklos Maroti; Philip Levis; TinyOS Development
> Subject: Re: [Tinyos-devel] Fwd: SendNotifier for Iris.
>
> On Mon, Nov 17, 2008 at 11:22 AM, David Moss <dmm at rincon.com> wrote:
> > My opinion may be a bit partial... but my app layer keeps a registry of
> AM
> > types and corresponding radios those types should be sent through, and
> uses
> > the SendNotifier interface to configure those outbound messages.  It's
> kind
> > of like dropping in a plug-in to give the system a new personality so you
> > don't have to edit generic libraries that should remain unmodified.
> >
>
> Sure but Ignacio did not implement CTP and he wants to be able to
> configure the messages generated by CTP. Are you saying all the
> applications and protocols should use the pattern you mention? If that
> is the case, it seems like that is an argument for pushing this
> functionality down to the generic libraries.
>
> - om_p
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081118/db69019a/attachment.htm