[Tinyos-devel] message_t

Miklos Maroti mmaroti at math.u-szeged.hu
Sat Mar 14 14:22:28 PDT 2009

Hi Jan,

> With my proposal you wouldn't need to (temporarily) store
> control/address information in a separate metadata buffer, the
> metadata part is optional: if none of the components in the
> send/receive path are using metadata (e.g. no timestamps, no RSSI,
> etc.) then the matadata buffer size would be 0 byte. The message
> buffer would still only be MAX_PACKET_SIZE byte, e.g. 127 for
> 802.15.4. The send() interface either includes the address/control
> parameters or they are set via a different protocol-specific interface
> and then send() only takes the packet_t as parameter. I.e. either
>  call Send.send(packet, address, ackrequest, ...);
> or
>  call Protocol.setControl(packet, addresses, ackrequest, ...);
>  call Send.send(packet);

My problem is that you cannot do

call PacketAcknowledgement.requestAck(msg);
call PacketSecurity.setKeyOrWhat(msg, key);
call PacketYourProtocol. setShortHeader(msg, address);
call Send.send(msg);

You see that the PacketAcknowledgement cannot know where that part of
the header is going to be. In your examples you either had all of your
arguments in the Send.send call, or moved that to a separate call just
before, but the two are the same. So you will have 2^N flavors of
Send.send calls, each with a different set of arguments.

The second problem is this: assume that you have a routing layer, but
below that we have some other layer, say security or low power
listening or some piggy backing stuff, which requires an extra
patameter. So your call would be

Call Control.setPayload(payloadLength); // or something similar
Call Send.send(msg, multiHopTarget, extraParameter);

Then the routing layer cannot send the message immediately, so it has
to store the extra parameterssomewhere. This extra parameter is for a
lower layer than routing, so it cannot store it in the message_t
without later changing the layout (and express knowledge of what the
extraParameter is) when a short address needs to be used instead of a
long one. So this extra parameter will be stored in the metadata

I do not see how you can create a generic routing layer that does not
care what other layers are below and what other parameters need to be

> So... I agree with you that both proposals have their individual drawbacks
>  -- it seems like there is no solution that has all the nice properties of
> message_t (buffer swapping, zero-copy-semantics, direct buffer access)
> and at the same time supports variable-sized headers/footers.

True. Maybe someone can come up with a better one. I was thinking of
formatting the message_t for the worst case with my format command
(using long address), and at send time we could compact the message
(switching to short address). The layout of the message before send
could be completely different (more verbose or generic), but then we
would either have to parse incoming messages as well to move
everything back to the largest possible case. Of course this would
require memory coping, but only once.

By the way, the ring buffer and format ideas are complementary. The
first one solves the copying part, the second one solves the problem
of mixing in protocols and their parameters.


More information about the Tinyos-devel mailing list