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

[Philip Levis]

Apologies: Jan should also have been on the message_t list of  
discussants.

Phil

Begin forwarded message:

> From: Jan Hauer <hauer at tkn.tu-berlin.de>
> Date: March 11, 2009 12:36:48 PM PDT
> To: TinyOS Development <tinyos-devel at millennium.berkeley.edu>
> Subject: Re: [Tinyos-devel] message_t
>
> Attached is a proposal for an alternative message buffer abstraction
> that allows variable-sized protocol headers/footers, but still uses
> static allocation of the message buffer. We have not discussed this in
> detail, so ... go on and take it apart :)
>
> Jan
>
> On Wed, Mar 11, 2009 at 6:53 PM, Philip Levis <pal at cs.stanford.edu>  
> wrote:
>> As developers have started implementing standards on TinyOS,  
>> message_t
>> has started to show some limitations. The goal of message_t was to
>> allow software to pass messages between different AM link layers
>> without copying, and this involved several simplifying assumptions.  
>> As
>> systems need more complex link layers (e.g., more than one 15.4
>> addressing mode, security support, IPv6 on top of 15.4), some of the
>> design decisions have started to become problematic.
>>
>> For example, message_t requires that the header, data, and footer be
>> allocated separately. Depending on your 15.4 addressing and other
>> options, the header can be anywhere from 3 to 30 bytes or so.
>> Correspondingly, the payload can be anywhere from 120 to 95 bytes or
>> so. While the two of them have, in combination, a maximum length
>> (125), you have to allocate the maximum of each of them separately,
>> leading to about a 20% waste (150 bytes).
>>
>> This has led core to start looking at other message abstractions.  
>> It's
>> important to note that changing the underlying buffer abstraction  
>> used
>> by radio drivers does not mean we have to break AM-based software
>> compatibility: many of these issues are arising exactly because  
>> TinyOS
>> needs more than just AM. At the worst case, you just make a single
>> copy between the AM layer (message_t) and other buffer abstraction
>> that drivers and other stacks use.
>>
>> Jan (TU Berlin) is going to send out one proposal he's come up with.
>> Stephen (Berkeley) also has some thoughts, and I encourage everyone  
>> to
>> examine the proposals. This is hopefully something that will change
>> for 2.1.1, or if more involved than anticipated, maybe a later  
>> version.
>>
>> Thanks,
>>
>> Phil
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: T2_packet_proposal.txt
Url: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20090505/897acd8d/attachment-0001.txt 
-------------- next part --------------
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel