[Tinyos-devel] Drip design review

David Gay dgay42 at gmail.com
Tue Feb 15 10:36:14 PST 2005

On Mon, 14 Feb 2005 20:51:02 -0800, Gilman Tolle <gilman.tolle at gmail.com> wrote:
> Instead, this is the approach Drip takes: the client component is
> responsible for managing the cache. This allows each client to
> allocate just enough space to hold its particular message.
> First, the client receives new messages with the standard Receive
> interface:
>   ClientM.Receive -> DripC.Receive[AM_CLIENTMSG]
>   event TOS_MsgPtr Receive.receive(TOS_MsgPtr msg, void* payload,
>                                    uint16_t payloadLen) {
>     // client acts on the message here
>     memcpy(&clientCache, payload, sizeof(clientCache));
>   }

This is not really much extra work (at worst, an extra line of code),
as you need to be notified of the new value anyway.

> The client is responsible for saving a copy of the message. Then, the
> client must provide that data upon request by Drip. This is done
> through the following interface:
>   ClientM.Drip -> DripC.Drip[AM_CLIENTMSG]
> The client implements an event:
>   event result_t Drip.rebroadcastRequest(TOS_MsgPtr msg, void* payload) {
>     memcpy(payload, &clientCache, sizeof(clientCache));
>     call Drip.rebroadcast(msg, payload, sizeof(clientCache));
>   }

Why is there a call here to rebroadcast, rather than just a return of
necessary information (the result could, e.g., be the length, or -1
for "don't do it")?

> Consider the following alternate approach:
>   command result_t StdControl.init() {
>     call Drip.init(&clientCache, sizeof(clientCache));
>   }
> The client provides Drip with a pointer to its cache at initialization
> time, and the size of that cache. In doing so, it transfers custody of
> that memory to Drip. Drip will save the pointer to the buffer, and
> will save the length, so that it can copy newly received messages into
> the correct cache and access that cache without bothering the client
> at all.

I will note that this design violates one of David's strongly-held
design-points for TinyOS: no sharing of data structures across
components. Personally, I don't feel *as* strongly, but I see his
point... Note that the 1st design (above) is ok: after some recent
discussion, we do allow "transfer/return of ownership" of data
structures (think what send/sendDone, or receive do). I believe the
coding convention TEP has (or will have) some discussion on this


More information about the Tinyos-devel mailing list