Wenjie, I believe you are correct. I probably should have verified this by looking at the code before making the statement. I had previously read through that code, and gotten the idea that sendDone(SUCCESS) was only signaled after an ack is received, but i guess i missed that case. It does signal sendDone(SUCCESS) when it receives an expected ack as originally thought in the function CC2420Receive.receive() in CC2420TransmitP.
Whether the current implementation is the desired behavior is another question altogether. -Paul Wenjie Zeng wrote: > Paul: > I found statement not entirely true in T-2.1. > > Once the sender receives an ack for this packet(with the ACK field set), > > only then will the sendDone function be called. > In /CC2420TransmitP/, /S_ACK_WAIT /is the state for waiting for a pending > ACK. However, after the back off timer fires in /BackoffTimer.fired()/, it > still fires a /signalDone(SUCCESS)/ even if the system state is still in > /S_ACK_WAIT/, i.e. even if Receive.receive has not received an ACK and set > msg_metadata->ack to TRUE. I traced the sendDone event upward through the > stack and found out that none of the upper level components actually checks > the /PacketAcknowledgements.wasAcked()/ flag before they sends a sendDone() > to the upper level. > As a result, I think for the 2.1 implementation, the CC2420 stack will fire a > sendDone with SUCCESS either earlier if a ACK is received or later until the > BackoffTimer fires. So, the only way to really make sure if a packet has been > is to check /PacketAcknowledgements.wasAcked()/. > However, I'm not 100% sure about this. Can someone confirm on this? > > Vikram, > > It's probably best to look at the code yourself to determine if your > > platform turns on acks by default or not. > > In general it is radio hardware specific, for example the CC1000 > doesn't > > perform MAC level acks. Other hardware such as the CC2420 have mac > acks > > enabled by default for unicast packets and disabled on broadcast > packets. > > As for your first question, normally acks are only enabled for unicast > > packets.(If they were enabled for broadcast packets, all the acks from > > multiple receiving nodes would likely collide) > > For your second question the requestAck() function sets a field in the > > packet header that indicates the sender requests an ack for this > packet. In > > general only when the intended node receives a packet with this > field set, > > will it send an ACK. Once the sender receives an ack for this > packet(with > > the ACK field set), only then will the sendDone function be called. > > -Paul > > On Mon, Dec 7, 2009 at 9:53 PM, Vikram vik76 <vik76 at sify.com > > <https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>> > wrote: > > > > > Hello, > > > > > > I would like to understand better the working of acknowledgments > in tinyos. > > > First, > > > Is MAC level acknowledgment implemented by default? for Unicast or > > > Broadcast? > > > > > > I also used the PacketAcknowledgements interface. When I use call > > > PacketAcknowledgements.requestAck(&pkt) does it explicitly > request the > > > receivers to send an acknowledgement, or it just captures the > > > acknowledgement that is sent by default by the receiver to the > sender? > > > > > > > > > Thanks > > > Vikram > > Best regards, > -- Wenjie Zeng > ------------------------------------------------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
