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

[culler]

Classically, on the inbound path you have a contiguous packet with the  
telescoping layers of encapsulation.  The trick is the outbound path,  
since each layer does not know what the layers around it want to wrap  
around it.  Classically, you build a list of these (mbufs) as you go  
down and perform a gather as it goes out.  Or, you need to determine  
from the layers below what they need.  All of addresses and header  
fields aree just encapsulating information.  Given that our processors  
are really fast compared to these paltry radios, it is not obvious  
that gather is a problem.  Very retro, but there is a reason that it  
was done in the old days.


On May 9, 2009, at 11:44 AM, Miklos Maroti wrote:

> 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
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel