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

[culler]

I think that it is time we allowed ourselves more room to maneuver.  
The active message concept was important to establish how  
communication and computation need to be efficiently integrated.  The  
key elements of that are (i) event-driven dispatch on receipt and when  
the transmit buffer can be reclaimed, (ii) handler namespace, and  
(iii) not requiring arbitrary buffering in the communication  
subsystem.  The traditional sockets API and parallel program message  
passing interface, e.g., MPI, do not have these properties.  However,  
an event driven UDP interface can be created that does.  It means that  
Port serves as the AM handler ID.  It also means that we think about  
encapsulation from the beginning - transport / routing / link.  I  
realize that the message_t discussion can be had without taking a  
position that it is time to eliminate AM in favor of something that  
looks like sockets, but I think that it would serve us well to make  
that step and gain some focus.  Things like group_id were hacks we  
through in for the first TinyOS bootcamp in 2001.  It was not well  
architected.  Ports is a sufficiently large name space for tiny devices.


On May 5, 2009, at 11:11 PM, Philip Levis wrote:

> 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
>>>
> <T2_packet_proposal.txt>
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg