Introduction of RPL non-storing mode #1404
Conversation
|
Due to exams and stuff there had been no progression on this PR in the last days. Although I thought of some restructuring - a new update is coming shortly. |
|
Implementation is now working with minus one thread :) However the two problems 1) integration of both storing/non-storing in one folder and 2) checksum stay the same. I will work on both shortly. Also rebased with master according to new kernel-pids etc. |
|
Everything is fixed. I will squash and rebase. |
|
At several places there are code fragments (lines) commented out via |
|
Sure thing. They will be gone after rebase. |
fabratu
force-pushed
the
rpl_nonstoring
branch
2 times, most recently
from
b8c8e5e to
473c3bb
Compare
| * @return 1 if root, 0 otherwise | ||
| * | ||
| * */ | ||
| uint8_t rpl_get_root_status(void); |
There was a problem hiding this comment.
I think something like rpl_is_root() would be a more appropriate name.
|
Please remove the merge commits and use the proposed license header from https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions#documentation. |
|
It's slightly unrelated to this PR, but can you fix the Edit: removing the actual file name after |
|
Obey coding conventions also regarding the maximum number of characters per line. |
| uint8_t type; | ||
| uint8_t length; | ||
| } rpl_opt_t; | ||
| } | ||
| rpl_opt_t; |
There was a problem hiding this comment.
Nope, the old version was the right RIOT style.
| return udp_packet_handler_pid; | ||
| } | ||
|
|
||
| kernel_pid_t get_tcp_packet_handler_pid(void) |
fabratu
force-pushed
the
rpl_nonstoring
branch
4 times, most recently
from
380825e to
ebf2c99
Compare
OlegHahm
removed
the
State: WIP
fabratu
force-pushed
the
rpl_nonstoring
branch
2 times, most recently
from
345cd2e to
e140331
Compare
| * | ||
| * @param[in] destination IPv6-address of the destination of the message. | ||
| * @param[in] payload Payload of the message. | ||
| * @param[in] len Length of the message |
There was a problem hiding this comment.
Should I wait for more or is this all? :)
This implementation is based on RFC 6550 with addition of RFC 6554 (Source Routing Header for RPL). Both can be found under the following links: - http://tools.ietf.org/html/rfc6550 - http://tools.ietf.org/html/rfc6554 The PR provides basic functionality for handling and forwarding packages in non-storing mode. In addition the structure of the previous implemented RPL storing mode is now revised, so that readability and modularity is increased. The following features are implemented: - building function for a SRH and integration in common packets - source-route build algorithm based on the structure of the DODAG - an RPL-based interpretation of the SRH and removal at destination - new structure for RPl-module with extracted beaconing-functionality - leaf nodes are now supported There are some missed goals and should be included in future updates: - building a common routing table structure for different types of routing protocols - routing tables are statically assigned via source code, future update should have an optional variable at build-time, which sets the size of the routing table depending on the desired functionality of a node in the network (root, node, leaf)
fabratu
force-pushed
the
rpl_nonstoring
branch
from
d1ad91d to
12cd62c
Compare
Introduction of RPL non-storing mode
|
Awesome - thanks for all the help :) |
|
congrats! |
In PR RIOT-OS#1404 addr_str was renamed to addr_str_mode, but at some places it was still referenced as addr_str. When enabling debug messages, the compiler complains.
As a result of PR RIOT-OS#1404, entries will not be added to the routing table when running in storing mode, although it is supposed to do so. You can verify by running rpl_udp and call *route* on the dodag-root. This PR fixes the wrong offset calculation.
This is the first commit for discussion. It works - but e.g. the checksum in UDP-packages is wrong because the length is zero (which it is not btw). In addition the design decisions concerning messages sending/relaying may be discuss-able - but I think they are as noninvasive as the network stack would allow them to be.
At last - the proposed fixes concerning storing/non-storing mode files with the same declaration-base in one directory from @Kijewski does not work. (Both - excluding files or moving them to a sub-directory) But I will see more into it. Maybe someone can help.