[Tinyos-devel] message_t

Jan Hauer hauer at tkn.tu-berlin.de
Fri Mar 13 03:49:29 PDT 2009


Hi Miklos,

I have some questions about your proposal:

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?

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?

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?

Jan

On Thu, Mar 12, 2009 at 10:03 PM, Miklos Maroti
<mmaroti at math.u-szeged.hu> wrote:
> Guys,
>
> Here is may alternative proposal for the new message_t. Basically, I
> would require all message_t to be formated (the old Packet.clear with
> some parameters), then everyone knows where the payload is and where
> the other header and footer fields are, so we can flexibly set those
> values (64 bit addresses, security data), finally we send the message.
> You need to format a message only if you do not know (first use) or
> want to change its layout (forward).
>
> Comments are welcome.
>
> Miklos
>


More information about the Tinyos-devel mailing list