[Tinyos-devel] AMSend.cancel command clarification request

[Andreas Koepke]

> 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).

So the MACs for the eyesIFX platform are already 2.0.1 compliant ;-)

> 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.

If I can rely on the fact that the MAC will also signal a
sendDone event, then I can get around it. The only catch is
that a sendDone(ECANCEL) may be signalled while the cancel command is
called. This should be safe in this case, though.

> Nice catch, by the way.
>
> Phil
>
>
>

I'm attaching a fixed version, where I also introduced some more changes:
- I changed the nextPacket function to start with current + 1
(instead of current), I guess that this caused messages to
be forgotten in the queue.
- the pointer bug dbg message is moved into the correct branch
- I removed the additional QUEUE_EMPTY constant, numClients already
contains this information
-  and unfortunately some changes in formatting - a side effect of the
debug instrumentation (that I hopefully removed completely ;-)

Best, Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AMQueueImplP.nc
Type: text/x-csrc
Size: 5999 bytes
Desc: not available
Url : http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20070314/6601bc0a/AMQueueImplP.c