[Tinyos-devel] AMSend.cancel command clarification request

[Philip Levis]

On Mar 14, 2007, at 2:02 AM, Andreas Koepke wrote:

> Hi all,
>
> while writing a counter based flood protocol (CBF) for T2, I stumbled
> upon a problem with the cancel command.
>
> I use the cancel command quite frequently in the CBF -- it is so
> convenient to forward a message pretty immediatly and cancel it once
> enough duplicates were received.
>
> Trouble appeared, when I started to use the AMQueueImplP -- and more
> than one sending component: it somehow silently ignored messages that
> were put into the queue while a message was currently "in  
> transmission".
>
> This is when I noticed a difference in the interpretation of the
> AMSend.cancel command. From the interface description I concluded  
> that a
> successful cancel must result in a sendDone(ECANCEL) event. However,
> judging from AMQueueImplP a successful call to cancel must prevent a
> sendDone event to appear. Actually that is how I interpret the meaning
> code, it does not always work this way. The code as it is written will
> result in a retransmission of the just canceled message -- and hence a
> sendDone(SUCCESS) event, if the canceling client is also the currently
> transmitting client. If it is not, the sendDone event is suppressed -
> somehow contradicting the documentation of the AMSend.send command.
>
> The two interpretions (AMSend.cancel -> suppression of sendDone,
> AMSend.cancel -> sendDone(ECANCEL)) are contradicting, so I think  
> we are
>  in trouble here.
>
> I personally prefer the sendDone(ECANCEL) interpretation, as  
> canceling a
> message from inside a MAC is easier to do in split phase fashion.

This is a bug in AMQueueImplP. You're right -- sendDone(ECANCEL) is  
the right response. As a side note, currently (2.0.0) you can't  
cancel a packet after it's entered the MAC; it's only cancelled in  
AMQueueImpl. The next release (2.0.1) will support last-minute  
cancellation (essentially, up to the point at which you send a  
TXONCCA on TXON command to the radio).

I'm working on an SOSP paper right now, so the earliest I'll be able  
to fix this later next week. If you come up with  a fix before then,  
I can take a look and incorporate it into the tree. I think that  
doing this right will require adding a bit of state for whether a  
packet is cancelled, posting a a task, and not actually removing the  
packet until the sendDone(ECANCEL) handler.

Nice catch, by the way.

Phil