klueska at gmail.com
Thu Oct 18 10:43:00 PDT 2007
To do this, it would make more sense to define message_t with two
separate metadata fields. One for send metadata and one for receive
metadata. The semantics for Packet.clear() would then be to 0 out the
entire send metadata field, leaving the receive metadata field in
For things like the LPL stack that add fields to the metadata
depending on which layers in the stack are included, providing this
separation is essential. Othgerwise you have to explicitly name each
field you want cleared, but they aren't necessarily known ahead of
On 10/18/07, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> On 10/17/07, Philip Levis <pal at cs.stanford.edu> wrote:
> > On Oct 17, 2007, at 11:04 AM, David Gay wrote:
> > > On 10/17/07, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> > >> If the message to be sent is statically allocated in a component and
> > >> its ownership does not change (other than passing via Send.send),
> > >> then
> > >> Packet.clear need not be called. In this case ALL metadata used for
> > >> transmission MUST NOT be changed by the Send implementation.
> > >
> > > Presumablt this exception should be extended to only returning it via
> > > Receive.receive.
> > >
> > > And in both cases it should be clear that this only applies to "things
> > > going to the same comm stack", i.e., if you have 2 Send's, then you
> > > must use clear if you don't know that they go the same stack.
> > > Hopefully you should be able to switch between Receive and Send for
> > > the same comm stack...
> > This came up on the call briefly. I don't think that you can ever
> > safely say that you can switch between Receive and Send, because the
> > wiring of those two is outside your control. For example, it's
> > entirely possible to take CtpForwardingEngineP and hook its receive
> > up to the serial stack while its transmit is up to the radio stack.
> > Furthermore, this puts the onus on the receive side to clear out
> > these fields. Otherwise, they will be as they were the last time send
> > was called with that buffer, which might not have been this same
> > component. In that way, Receive by itself is not sufficient, because
> > it's possible you returned it to a queue, which then another
> > component uses for Receive.
> > I'm not sure what the exact correct usage should be.
> > Phil
> You cannot reuse a received message buffer as a message to be sent
> before you actually call Packet.clear EVEN IF the Send and Receive are
> on the same interfece. Imagine, that ComponentA is receiving messages
> into a buffer and it does nto care about metadata. These message
> buffers go into the communication stack and resurface into ComponentB
> at Receive.receive(). At this point the metadata of the message buffer
> could be either set incorrectly (the buffer might never have been used
> to send a message), or set according to somthing else (for example not
> requiring acknowledgements, etc). In this situation you MUST set up
> the send-metadata (e.g. ack requested, retries, etc), and if you do
> you might as well clear the packet with Packet.clear for metadata that
> ComponentB does not know or care about.
> There is a BIG assumption here. Packet.clear clears only the
> send-metadata, that is, stuff that is used to send the message. Maybe
> we should make it explicit that it should not touch receive-metadata,
> such as lqi and timestamps.
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
More information about the Tinyos-devel