Home arrow Blog arrow DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented... | Print |
Written by Akiba   
Sunday, 26 October 2008
After my last post, Adam Dunkels commented that the way I accessed the data in the managed memory was incorrect. This was causing the error case that I had written about, and also can possibly create dangling pointers. My original way to access the managed memory looked like this. This examples gets the next hop address from the routing tables:
mem_ptr = list_head(rte_tbl); // grab the first mem ptr from the list
rte_entry = (rte_entry_t *)mem_ptr->mmem_ptr.ptr; // de-ref the ptr
next_hop = rte_entry->next_hop; // get the next hop
That was incorrect because I should not have stored the de-referenced memory pointer. The reason is that the position of the pointer is un-reliable due to the memory compacting that the managed memory performs. So instead, the correct way to use the memory pointers was via the built-in memory macro. Here's the same code again using the correct access method:'
mem_ptr = list_head(rte_tbl); 
next_hop = ((rte_entry_t *)MMEM_PTR(mem_ptr->mmem_ptr))->next_hop;
It's actually more concise, but since the stack has a lot of tables and table accesses, having a freaky line of code like that sprinkled around the stack starts to look intimidating. Because of that, I decided to try to pretty up the code a bit more and created some macros for the various table entries. So now, it looks more like this:
mem_ptr = list_head(rte_tbl);
next_hop = RTE_ENTRY(mem_ptr)->next_hop;

There are other macros for other table entries as well. They are basically just convenience macros that handle the de-referencing of the memory pointers and typecasting them for the particular table element, but they make the code a bit more readable. And now, the code is (hopefully) 100% safe from dangling pointers...at least from the managed memory.

If you're interested to check out the modifications to the stack to go from statically allocated table elements to a dynamically allocated heap, you can access the subversion repository (version control) from the following address:

https://freakz.svn.sourceforge.net/svnroot/freakz

I haven't done a formal release for this code yet since I haven't fully tested the code and updated the documentation. But its already working for the long file test and multi-hop tests and you can grab it straight from the repository.

Email This
Hits: 985
Trackback(0)
Comments (0)Add Comment

Write comment

busy
 

Discuss (5 posts)
Alex
DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
Oct 27 2008 07:21:21
This thread discusses the Content article: DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...

The question is not referencing to this subject.
I don't know how the router or the coordinator recognizing a device's state.

If the device is in deep sleep mode and its sleeping time is very very long, how does the router or the coordinator know wheather it has leave their comunication range or it is sleeping yet.
For so long a time, the device would never send a message to others just like it is disappearing from the network.
 #323

Akiba
Re:DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
Oct 27 2008 09:42:08
There is a flag called rx_on_when_idle that the device sends to the parent when it is joining. This flag will specify if the device is a sleeping node or not. If its a sleeping node, the parent will buffer messages for it and when the device wakes up, it will ask the parent for any buffered messages for it.

In regards to the sleeping node, the parent will not remove a device just because it is inactive. The parent only removes a device if the device joins another parent. The opposite of your situation actually happens. If the end node wakes up and can't contact the parent, it will send out an orphan request. If the parent is still around, it will respond and things are just normal. If the parent is not around, the device will search for a new parent. After it joins the new parent, it will send out an end_device_announcement and broadcast it. When the old parent receives this, it will remove the device from its associated devices list.
 #324
Alex
Re:DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
Oct 30 2008 06:09:27
Then,how does a device rolled as a router work?
The routers and the coordinators always set the rxonidle on, and we don't choose the beacon mode, does the routers always send some data to its parents router or coordinator in a certain time?

I have a exampel,if I have a remote controller for the air condition, which also acts as a router.When I take it to another room, how does it rebuild the network dynamicly.
 #328

Akiba
Re:DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
Oct 30 2008 11:34:34
Once you move your router, and it goes out of earshot of its parent (or neighbors), then there will be gap in the network at that point. This is because all of the neighbors have the removed node in their routing tables, but it doesn't exist anymore. So when a frame is forwarded to the removed node, and no ACK is returned, then the forwarding node will send a network status frame back to the originator indicating that there was a link failure.

The originator of the frame will remove the destination address entry from its routing table, and then re-initiate route discovery. In the process of route discovery, all the nodes along the route to the destination will also have their tables updated.

This is how the mesh networking achieves its "self-healing" properties.
 #329
Alex
Re:DevJournal - Ok, Really...the dynamic allocation and managed memory is implemented...
Oct 31 2008 05:58:35
There is such a situation.
If the router device moves around the coordinator very fast, and now it is one of a routine lines.
Now a frame occured and it has arrived to the router's parent, suddenly, the router left and the frame was stucked.
So, I think a new route discovery have to start,when the self-healing work is starting, the moving router arrived to its old place again and become one of the routine line again.
The frame transfer again and when it come to the node's parent,the moving nodes disappear again.
Finally, the router always be one of the routine line for this frame,but it could never pass through.

So, I think its some use to know how long the network-rebuilding would take; we can assume the network's capcity was about 100 nodes.

There is some problems when communication in a fast moving car or other vichels.
Mostly they are only p2p mode,not a mesh network.
 #330


Discuss...
< Prev   Next >
[ Back ]