Hi Eric
thanks for your answer. In fact, I thought the same. Although there is 
something you pointed out that it just what I need: "The answer to your 
question depends on what the original caller of the enqueue wants done. [...] 
Simply dequeuing the message certainly isn't enough because that most likely 
leads to lost messages." Certeanly, what I need is that, if a message has to be 
dropped, then it counts as a lost message. So what I don't want to is being 
dequeuing messages and at the end, run out of memory because I did not manage 
it correctly handling these dequeued messages.
In any case, I have a possible answer which is simpler than I thought. I was 
addressing the problem wrong, thinking that a message that was enqueued, it was 
really a peace of dynamic/external memory that came (was transmitted) to the 
receiver node, so it increased the already occupied memory (there is a reason 
of why a thought this: I also work with Network Simulator 2 - NS2 - and there 
you use dynamic memory for messages). This is totally wrong with TinyOS, when 
you receive a data message and enqueue it, you are only copying the whole 
content to the corresponding memory location (you defined Queue as static 
memory) and increasing a counter of enqueued messages. Then you can use PoolC 
to return an empty message_t to the system. Thus, when you make a call to 
Queue.dequeue(), what this function returns is a pointer to a static portion of 
memory (of size message_t) as well as decreases the counter of messages 
enqueued. Therefore, when another message_t is enqueued, this occupies the same 
portion of memory so the node never run outs of memory because of what I what 
asking.
Am I right?
Thanks again, regards
David
Date: Mon, 26 Nov 2012 19:51:48 -0800
Subject: Re: [Tinyos-help] Drop packets in TinyOS
From: [email protected]
To: [email protected]
CC: [email protected]


Looking at this problem from the queueing mechanism is coming at the problem 
from the inside out.
So it is pretty difficult trying to answer the question you are asking.

To do so really requires looking at the data flow (message_t) and buffer flow 
at various points in packet transmission and reception.  
The answer to your question depends on what the original caller of the enqueue 
wants done.    And then there is the whole wiring issue and how to pull the 
whole thing together.

Simply dequeuing the message certainly isn't enough because that most likely 
leads to lost messages.  But the whole scheme needs to be worked out in a 
systemic fashion.   And it would be nice if it were documented.  It certianly 
is a hole.   Eventually I'll get to it.

I certainly understand what you are trying to accomplish.  Been there done 
that.    Sorry I don't have a better answer for you.
eric


On Mon, Nov 26, 2012 at 7:48 AM, David Rodenas <[email protected]> wrote:




Hi all

I would like to know how to discard a message which is stored in a queue 
(component QueueC of message_t). To better explain this, lets suppose we have a 
maximum number of retries during we are trying to forward a data message. This 
is stored in a queue waiting for being transmitted. A failed transmission can 
occur due to collisions, interferences, etc. So when this maximum number is 
reached, the data message should be discarded, making this same procedure with 
the following message (head of the queue). Here there is a simple code of what 
I'm asking:

maximum_retries = 3;num_retries = 0;
if (num_retries > maximum_retries){    message_t * drop_msg = call 
Queue.dequeue();    drop(drop_msg);
}
The point is that I'm not sure if just dequeuing the message_t is enough. This 
message occupies a piece of memory space and this has to be freed. Am I right? 
Should I use the function free as in any C-based language when dynamic memory 
allocation is used?

Thanks
David                                     

_______________________________________________

Tinyos-help mailing list

[email protected]

https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help



-- 
Eric B. Decker
Senior (over 50 :-) Researcher




                                          
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to