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

[Miklos Maroti]

Hi Jan,

On Sat, May 9, 2009 at 8:26 PM, Jan Hauer <jan.hauer at gmail.com> wrote:
> On Fri, May 8, 2009 at 10:33 AM, Miklos Maroti <mmaroti at math.u-szeged.hu>
>> E.g. AMSender accepts a destination address as a parameter, sets the
>> address via AMPacket and the length of the message via Packet, keeps
>> the message around, then sends it via SubAMSend but first queries back
>> the destination, am type and length just to be able to call the
>> SubAMSend which in turn overwrites these values with the same one. How
>> do you implement this with Jan's proposal?
>
> The most natural would be to not have separate commands for passing
> the control information associated with a packet (addresses, flags,
> etc.) and sending the packet. Instead, the send() command would
> include both at the same time. In the send() command handler the
> callee would typically attach and populate its own header/footer (e.g.
> based on the passed control information), possibly queue the packet,
> later dequeue it and possibly reformat its header/footer, and then
> call send() on some other component.
>
> 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. You want
to put all header information of the lower layers into the send
command. However, if you add a new layer between N-1 and N which adds
some extra header info, then suddenly you cannot handle that with your
proposal without changing the code of layer N.

Of course there are mixed in layers that require metadata info (like
PacketLink), but you correctly realize that those parameters (even
though they are just message parameters) cannot be included into the
send command so you have to handle the metadata section separately
(that is why your flat buffer does not include the metadata section
and mine does) exactly the same way I want to do the header info too.

With your proposal it would be impossible to write an ActiveMessage
layer which just adds a single am_type header byte and works both with
IEEE 802.15.4 packets that require 32-bit addresses in the send
command, and with the compact header used for CC1000 which uses 16-bit
addresses. Just because the lower layers are different and take
different parameters you HAVE TO handle all those parameters at the
ActiveMessage layer or AMSenderC, store then, retrieve them and pass
them down, and in effect you need to rewrite the ActiveMessage layer.

I am NOT saying that the user cannot use the familiar AMSend.send
command that is dear to him. But in my opinion the AMSend interface is
just a syntactic sugar at the application layer.

Miklos