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

[Miklos Maroti]

Hi Jan,

On Mon, May 11, 2009 at 12:53 PM, Jan Hauer <jan.hauer at gmail.com> wrote:
>>> While a component "owns" the packet (after it has received it via
>>> send() and before it has passed it to some other component via some
>>> other send(), i.e. the send() commands typically differ in the control
>>> parameters), it can use any remaining unused memory inside the packet
>>> to store temporary variables/addresses, component state, etc., because
>>> at protocol layer N a packet never includes any information belonging
>>> to the layers < N, which it could override. So even if layer N calls
>>> send() on layer N-1 and passes/tunnels control information for layer
>>> N-2, then layer N-1 could typically temporarily store them in front of
>>> its own header inside the packet.
>>
>> This is the main difference between our proposals! I think at layer N
>> the packet has a payload and a valid header which consists of the
>> header segments of the layers below at layer N-1, N-2, etc.
>
> Why should an outbound packet at layer N already include all
> headers/footers of all the lower layers < N? Their header/footer
> layout can still change while the packet propagates down the stack.
> What if you have two different send-paths, e.g. two alternative
> protocols at layer N, and layer N+1 chooses dynamically where to pass
> the packet to -- how could you decide in advance, at the time the app
> writes its payload in the packet, whose headers (layouts) you put in
> the packet?

That is why I said that the network components form a TREE so at any
point you know what other layers are below you and they can reserve
the space accordingly and set some default values when you call
Packet.clear(). Most of the header fields are just reserved, and
written with AMPacket, Ieee165Packet or whatnot interfaces.

>> You want
>> to put all header information of the lower layers into the send
>> command.
>
> Ideally I'd like layer N to pass to N-1 only the parameters relevant
> to the service provided by N-1, nothing else (e.g. transport layer
> shouldn't ask for link layer acknowledgments). I'm not sure how
> realistic this is with the current implementations, maybe net2 people
> can speak up.

You have to decide what you want to do on the receiver side:

1) Remove the header fields and pass them with the receive command
(the logical thing to do as the analog of the sender case).  In this
case you no longer have the AMPacket and other interfaces, and
everything is presented to the user as an event parameter. However,
what should the user do with those parameters if he wants to process
the packet in a task? Save them somewhere in memory or put them back
at the head of the packet?

2) Keep the header fields and provide the AMPacket and friends
accessor interfaces just like we do today. These interfaces need to be
implemented and they need to know where the individual header fields
are. I propose to reuse these same interfaces for the sender path too.

Miklos