[Tinyos-help] CTP not reporting NET_C_FE_DST_MSG and NET_C_TREE_RCV_BEACON

Morten Tranberg Hansen mth at cs.au.dk
Thu Nov 18 14:39:22 PST 2010

Oh I didn't realize you were talking about the RCV_MSG event.  Yeah the only
unlogged event between the RCV_MSG event and a possible DST_MSG event at the
root would be if the max payload length test fails.  I'm not sure when/if
this test fails, but maybe it should be logged for correctness.


On Fri, Nov 19, 2010 at 2:42 AM, Philip Levis <pal at cs.stanford.edu> wrote:

> On Nov 17, 2010, at 8:36 PM, Morten Tranberg Hansen wrote:
> > I argue that the application, which is signaled receive from the ctp
> forwarding engine, should not necessarily have to tell anybody that it
> received this event, and hence CTP should debug the NET_C_FE_DST_MSG.  In
> case the application, whichever one is used, decides to report the receive
> event (this is application dependent), one of the two "reports" is
> redundant.  I just think its wrong to assume that all applications report
> the receive event signaled from the ctp forwarding engine.
> I feel like we're talking in circles, or completely misunderstanding each
> other.
> The application doesn't need to report the event. If a node is a root and
> receives a packet to forward, it signals receive(). Correspondingly, if you
> see a NET_C_FE_RCV_MSG event, and a node is a root, Receive.receive will be
> signaled. For a root, you would always see RCV_MSG log message followed by
> the receive event log message. Or is your concern the max payload length
> test?
> Whether or not this reaches an application (the app has wired to the
> particular receive event ID) is a wholly separate concern. E.g., it could be
> that the application does not handle that CTP data type.
> Phil

Morten Hansen, http://mortent.dk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20101119/0885ba93/attachment.htm 

More information about the Tinyos-help mailing list