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

[Philip Levis]

Begin forwarded message:

> From: Miklos Maroti <mmaroti at math.u-szeged.hu>
> Date: March 13, 2009 10:18:26 AM PDT
> To: Jan Hauer <hauer at tkn.tu-berlin.de>
> Cc: tinyos-devel at millennium.berkeley.edu
> Subject: Re: [Tinyos-devel] message_t
>
> Hi Jan,
>
>> 1) I'm not sure if I understood the format() part correctly. Couldn't
>> the following happen: The app calls format(). The call propagates
>> downwards through all protocol layers. When it reaches the routing
>> protocol, the next hop must be chosen which, say, has a short address
>> (16-bit): by calling format() on the MAC the routing layer would
>> somehow tell the MAC to use/reserve 16-bit for the destination  
>> address
>> in the MAC header. Some time later the application decides to put  
>> some
>> data in the payload section and then call send(). Because send() is
>> split-phase it might take some more time until the send() call  
>> reaches
>> the routing layer (packet can be queued in a send-queue on upper
>> layers, etc.). By the time send() reaches the routing protocol the
>> original next hop has disappeared (was dropped from the forwarding
>> table). The next hop now has an extended address (64-bit), which
>> wouldn't fit in the MAC header anymore -- so the packet couldn't be
>> sent?
>
> Your analysis is correct, the message needs to be reformatted if you
> wait a lot of time between format() and send() and the routing layer
> decides to use a different layout.
>
>> 2) When a sendDone() returns FAIL and the application tries to resend
>> the same packet, then it might have to clear() the packet content and
>> write the same payload again, because this time format() might result
>> in a different layout?
>
> That is also correct if you add layers dynamically without the
> knowledge of the user.
>
>> 3) To forward a message it has to be copied as soon as the size of  
>> any
>> headers/footers changes and to be compatible with AM you'd also have
>> to copy, right?
>
> True.
>
> Now, let me tell you what the alternative is: Do not move the
> parameters from Send.send() to Packet.format() so you can change the
> layout at Send.send() time. This means that you have to include ALL
> parameters in the Send.send() command and you cannot mix in optional
> header components. For example, the PacketAcknowledgement interface
> cannot set the ACK bit in the 802.15.4 header because it does not know
> where the header is going to be when Send.send is called, so it must
> store that information in a metadata field and copy it to the header
> when that is constructed. The same goes for the security interface,
> you cannot store that 14 bytes in the header, so you must store it in
> the metadata and copy it when needed. This leaves you two options:
>
> 1) You pass ALL parameters in the Send.send() command including data
> stored/accessed with the PacketAcknowledgement, PacketLink,
> PacketSecurity, PacketTimeSync interfaces. This would require a
> routing layer to receive and move these bits of information around
> with the message_t separately. But where would it store this info?
> Somewhere it the metadata, so practically the routing layer has to do
> the next option implicitly:
>
> 2) Store all this mix in information in the metadata section, so you
> can mix them in the header when the header is constructed at
> Send.send() time. But then you are wasting a lot of RAM as every
> possible extension must reserve enough space in the metadata section
> to work properly.
>
> So this is the hard choice: with my proposal you need to reformat the
> message when the layout is changed, with your proposal you need to out
> mix in network layer configuration options in the metadata, thus
> wasting RAM in every message.
>
> Miklos
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel