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

[culler]

There are indeed several distinct issues here.

Inclusion of AM_ID and group in the frame format.  Yes, I do think  
that it is time we got beyond that.  AM_ID and Group are really layer  
4 concepts that are being encapsulated in a layer 2 position.  They  
identify the service endpoint.  The encapsulation should be
[link address [routing endpoint [ service end point [payload ]]]]

Programming interface.  Our use of destination addresses treats them  
as small integers, rather than as an addressing structure.  It is  
critical to maintain the event driven interface, so traditional  
sockets is not right.  Explicit notification of completion is key to  
determining when resources can be reused.  It is more natural with a  
datagram abstraction, like AM and UDP, than a sockets abstraction.

Fixed format packets: the goal of message_t and mx structs was to  
eliminate error prone runtime parsing and to avoid copies.  The  
challenge is that it is extremely difficult to represent a series of  
TLVs or the analogous sequence of fields is very difficult to fit into  
the struct static parsing model.  We are seeing this at layer 2 with  
short and long mac addresses, layer 2.5 with lowpan, layer 3 and 4  
with IP, and layer 7 as soon as you include a sequence of attribute/ 
values like in almost all the industrial instrumentation protocols.   
You need at least an iterator to run down the sequence of fields.  I  
would love to not reproduce the tons of broken code that exists  
outside tinyos with all the broken htons and noths and bogus parsers.   
But I don't see how just nested structs is enough.



On May 6, 2009, at 9:42 AM, Philip Levis wrote:

>
> On May 6, 2009, at 7:22 AM, culler wrote:
>
>> 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.
>
> AM ids are a link-layer dispatch mechanism for different layer 3  
> protocols. UDP provides transport layer dispatch for different  
> presentation, session, and application layer protocols. The former  
> does not preclude the latter, as blip demonstrates. As a lot of  
> TinyOS users want to operate at the link layer, eliminating access  
> to it is problematic. The term "port," after all, comes from  
> "transport."
>
> What the UDP interfaces look like is a wholly different question,  
> and something which net2 covers. Hammering out those interfaces so  
> they are simple and effective, such that systems and protocols  
> migrate to using them, is a more effective way to promote their use  
> than removing access to the link layer.
>
> Phil