[Tinyos Core WG] Fwd: [Tinyos-devel] message_t

[Philip Levis]

Begin forwarded message:

> From: Miklos Maroti <mmaroti at math.u-szeged.hu>
> Date: March 14, 2009 2:22:28 PM PDT
> To: Jan Hauer <hauer at tkn.tu-berlin.de>
> Cc: tinyos-devel at millennium.berkeley.edu
> Subject: Re: [Tinyos-devel] message_t
>
> 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
> section.
>
> 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
> passed.
>
>> 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.
>
> Miklos
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel