[Tinyos-devel] Current status of the message buffer discussion

[Martin Turon]

Some thoughts regarding the message_t thread: 

In thinking about how to make message_t a more general internal type for 
handling multi-layer marshaling of packet structure, it is helpful to
review the current definition:

http://www.tinyos.net/tinyos-2.x/doc/html/tep111.html

It looks like the current message_t is essentially hard-coded by the 
platform to handle the first (PHY) layer header/payload/footer/metadata
combo.  To expand this to multiple layers, it seems logical to allow 
definition of custom message_t types by generalizing the mechanism 
for defining them:

typedef my_message_t message_class_t< my_header_t, my_footer_t >;

Then this custom type can be used to define the payload of the N-1 layer.

template <type message_header_t, type message_footer_t, type message_meta_t>
nx_struct message_class_t {
  nx_uint8_t header[sizeof(message_header_t)];
  nx_uint8_t data[TOSH_DATA_LENGTH 
  	     	  - sizeof(message_header_t)
		  - sizeof(message_footer_t)
		  - sizeof(nx_uint8**)		// See note below
		  ];
  nx_uint8_t footer[sizeof(message_footer_t)];
  nx_uint8_t **metadata;
} message_t;

Note: the payload size may need to be automatically calculated based on a 
forth parameter which is the message_t this layer is encapsulated in.

Granted this would be some serious tools work on the part of nesC, but
it may even be conceivable that the metadata portion would be pushed out
of the packet itself (attached to the end) and referenced by the application
through a pointer (or single byte offset) maintained by nesC (only accessible
via nesC api).  This would eliminate fragmentation within the packet itself
at the cost of a few bytes at the end to reference the metadata chunks.
Fragmentation would only occur when footers are used with the metadata
offsets inbetween each footer.

So what would the interface to all this look like?  Well, it should be pretty
similar to message_t as we know it now, except with custom messages defined
at each protocol layer:

[platform_message.h]
// Same as before, but defined the new way, 
// and isolated to essential PHY fields.
typedef message_t message_class_t<phy_header_t, phy_footer_t, phy_meta_t>;
typedef phy_message_t message_t;  // Clarify intended usage in new code.

[platform_mac.h>
// Optimized, packed mac message for 16-bit addressing
typedef mac16_message_t message_class_t
	<mac16_header_t, mac16_footer_t, mac16_meta_t>;

// Statically typed 64-bit addressing
typedef mac64_message_t message_class_t
	<mac64_header_t, mac64_footer_t, mac64_meta_t>;

// One message that handles all permutations but with fragmentation.
typedef mac_message_t message_class_t
	<mac_union_header_t, mac_union_footer_t, mac_union_meta_t>;

[network_am.h>
typedef am_message_t message_class_t
	<am_header_t, am_footer_t, am_meta_t>;

[network_ipv6.h>
typedef ipv6_message_t message_class_t
	<ipv6_header_t, ipv6_footer_t, ipv6_meta_t>;

typedef ipv6_mesh_message_t message_class_t
	<ipv6_mesh_header_t, ipv6_mesh_footer_t, ipv6_mesh_meta_t>;

typedef ipv6_frag_message_t message_class_t
	<ipv6_frag_header_t, ipv6_frag_footer_t, ipv6_frag_meta_t>;

typedef ipv6_udp_message_t message_class_t
	<ipv6_udp_header_t, ipv6_udp_footer_t, ipv6_udp_meta_t>;

Now given all these strongly typed marshalling structures, the rough API
would be:

RECEIVE : layer parses its header/footer and returns a strongly typed
message to the next layer up.  That layer would then use the corresponding
Packet interface to access the fields.  

SEND: layer casts the payload pointer to the proper message type.  It fills
in the fields with the corresponding Packet interface, and passes that down.
Lower layer shouldn't care about payload contents in most cases.  If 
upper layer needs to fill in fields for the lower layer, a similar method is
used: cast, fill, send.
 
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090520/779be6db/attachment.htm