message_t(Tinyos系统知识点介绍)

Message_t介绍（TEP111英文文档翻译参考）

此文档描述了TinyOS2.x消息缓存的抽象类型"message_t"，介绍了消息缓存的设计考虑还有"message_t"在哪和怎样定义，以及数据链路层是应该如何使用它的。"message_t"类型的主要目的是允许报文作为内存的一个连续存储区域以零拷贝的方式在不同的链路层传输。

在TinyOS1.x中，消息缓存是"TOS_Msg".这个消息缓存类型包含了AM包和形如时间戳、应答位、信号长度等包的元数据。"TOS_Msg"是一个固定长度的结构，最大长度值默认为29字节。定长的缓存允许TinyOS1.x拥有零拷贝的语义：当一个组件接收到一个buffer后，它能为低层返回一个指向新buffer的指针，以便接受下一个数据包，而非将此buffer的内容拷贝出去来腾出空间。

一个问题出现了：什么定义了“TOS_Msg”结构，不同的链路层可能需要不同的布局。例如：802.15.4射频器可能需要802.15.4.头（好比CC2420，使用在Telos和micaZ平台），字节射频（例如CC1000，使用在mica2平台）需要定义它自己的包格式。这就意味着不同的平台可能有不同的"TOS_Msg"结构。

TinyOS1.x中的解决办法是只有一个标准的"TOS_Msg"定义，特定平台可以将其重新定义成符合它自己需要的结构，例如一个mica2节点使用如下标准定义：The solution to this problem in

typedef struct TOS_Msg{

//The following fields are transmitted/received on the radio.

uint16_t addr;

uint8_t type;

uint8_t group;

uint8_t length;

int8_t data[TOSH_DATA_LENGTH];

uint16_t crc;

//The following fields are not actually transmitted or received //on the radio!They are used for internal accounting only.

//The reason they are in this structure is that the AM interface //requires them to be part of the TOS_Msg that is passed to

//send/receive operations.

uint16_t strength;

uint8_t ack;

uint16_t time;

uint8_t sendSecurityMode;

uint8_t receiveSecurityMode;

}TOS_Msg;

在使用CC2420射频的平台上，“TOS_Msg”定义为：while on a mote with a CC2420radio(e.g., micaZ),``TOS_Msg``is defined as::

typedef struct TOS_Msg{

//The following fields are transmitted/received on the radio.

uint8_t length;

uint8_t fcfhi;

uint8_t fcflo;

uint8_t dsn;

uint16_t destpan;

uint16_t addr;

uint8_t type;

uint8_t group;

int8_t data[TOSH_DATA_LENGTH];

//The following fields are not actually transmitted or received //on the radio!They are used for internal accounting only.

//The reason they are in this structure is that the AM interface //requires them to be part of the TOS_Msg that is passed to

//send/receive operations.

uint8_t strength;

uint8_t lqi;

bool crc;

uint8_t ack;

uint16_t time;

}TOS_Msg;

这个方法存在2个基本问题。第一，暴露所有的链路层结构字段导致组件会直接存取包结构，这会给高层组件和底层机构之间引入依赖(注：高耦合)。例如，很多建立在数据链路层之上的网络层服务会是否收到已发包的应答，因此它们会检查TOS_Msg中的ack字段。如果某个链路层不提供应答机制，它也必须在结构中包含"ack"字段，并总是将其设置为0，这样就浪费了RAM 每个buffer中的一个字节。

第二，这个模型要支持多种数据链路层是困难的。射频芯片的实现会假设它们需要的字段以及在结构中得到了预定义，并会直接存取它们。如果一个平台有2个不同的数据链路层（例如同时拥有CC2420和CC1000射频），那么一个“TOS_Msg”需要为2个结构的头部字段分配正确合适的空间，以便它们能够直接存取这些头部字段。这在C语言中是相当困难的。Second,this model does not easily support multiple data link layers.Radio chip implementations assume that the fields they require are defined in the structure and directly access them.If a platform has two different link layers(e.g.,a CC1000*and*a CC2420radio),then a``TOS_Msg`` needs to allocate the right amount of space for both of their headers while allowing implementations to directly access header fields.This is very difficult to do in C.

数据负荷是更是问题多多。许多组件会访问此字段，因此它离结构的开头必须是定长的。对于不同的链路层，在数据字段之前的头部字段可能有不同的长度，而且对于报文式的射频（注：比如CC2420,相对于CC1000字节流）通常要求报文在内存中是一块连续的区域。总而言之，这些复杂行使得定义“TOS_Msg”的格式相当困难。

message_t