mmaroti at math.u-szeged.hu
Fri Mar 13 10:18:26 PDT 2009
> 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
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?
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.
More information about the Tinyos-devel