Size: 1224
Comment:
|
Size: 3548
Comment: converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
== Netsukuku features list == |
|
Line 2: | Line 4: |
- distributed, not hierarchic mesh network | - The Netsukuku mesh network is: distributed, not hierarchic, and higly scalable. It isn't specifically designed for mobile nodes, since the stability of the net was prioritised. However it can be used for them if they are inside an area covered by other Netsukuku nodes. |
Line 4: | Line 10: |
- scalability: Netsukuku is specifically designed to handle an unlimited | - Scalability: Netsukuku is specifically designed to handle an unlimited |
Line 6: | Line 12: |
- The net isn't overloaded with discoveries packet - The size of the maps is fixed: about 4Kb for the int_map and 16Kb for the ext_map. - Not all the nodes sends a broadcast discovery. - There are few floods for each discovery. - When a node receives a flood it has already the routes that can be used to reach all the nodes traversed by the flood. It doesn't need to calculate anything about them. - A flood is synchronized: the same flood starts at the same time for all the nodes. - http://lab.dyne.org/Netsukuku_scalability |
|
Line 10: | Line 34: |
Line 13: | Line 38: |
- A node can register up to 256 hostnames. | - Any node can register up to 256 hostnames. - The registration is secure: it is based on asymmetric cryptography, thus it is very difficult to take hostnames which has been already registered by other nodes. |
Line 17: | Line 46: |
- DNS compatibility | - DNS compatibility: all the network programs are already compatible with ANDNA, because NetsukukuD comes with a DNS wrapper which converts DNS queries to ANDNA requests. |
Line 19: | Line 50: |
- All the resolved hostnames are kept, in the "resolved hostnames cache" to speed up the resolution process. The rhcache is synchronized with ANDNA, therefore its stored entries will expire exactly when the registered hostnames expire in ANDNA. |
|
Line 21: | Line 58: |
The SNSD is the ANDNA equivalent of the SRV Record of the Internet Domain Name System, which is defined here: http://www.ietf.org/rfc/rfc2782.txt SNSD isn't the same of the "SRV Record", in fact, it has its own unique features. |
|
Line 25: | Line 66: |
- multigw - traffic shaping |
* Multi-inet-gateways. The Netsukuku nodes will now automatically use multiple inet-gateways to connect to the Internet, therefore their Internet connection will be effectively load-balanced. * Anti-loop multi-igw shield. The nodes which share their Internet connection will also automatically use the shared connection of the other nodes. Through a simple marking system, death loops are avoided. * Traffic shaping. The nodes which share their Internet connection can now shape it, in this way they'll prioritize their local outgoingtraffic and the lowdelay one (f.e. SSH). |
Line 29: | Line 81: |
- routes based on bandwidth and latency | - Routes based on bandwidth and latency |
Line 42: | Line 94: |
multiple interfaces, use them all with a multipath route. | multiple interfaces, it uses them all with a multipath route. |
Netsukuku features list
- The Netsukuku mesh network is: distributed, not hierarchic, and higly scalable. It isn't specifically designed for mobile nodes, since the stability of the net was prioritised. However it can be used for them if they are inside an area covered by other Netsukuku nodes. - Scalability: Netsukuku is specifically designed to handle an unlimited number of nodes with minimal CPU and memory resources. - The net isn't overloaded with discoveries packet - The size of the maps is fixed: about 4Kb for the int_map and 16Kb for the ext_map. - Not all the nodes sends a broadcast discovery. - There are few floods for each discovery. - When a node receives a flood it has already the routes that can be used to reach all the nodes traversed by the flood. It doesn't need to calculate anything about them. - A flood is synchronized: the same flood starts at the same time for all the nodes. - http://lab.dyne.org/Netsukuku_scalability - zeroconf: the network builds itself, without need of human intervention - ANDNA: distributed and not hierarchic DNS - When the net becomes larger, ANDNA scales more because its DB will be distributed among the nodes. - Any node can register up to 256 hostnames. - The registration is secure: it is based on asymmetric cryptography, thus it is very difficult to take hostnames which has been already registered by other nodes. - Each hostname can be a string of maximum 512 bytes. - DNS compatibility: all the network programs are already compatible with ANDNA, because NetsukukuD comes with a DNS wrapper which converts DNS queries to ANDNA requests. - All the resolved hostnames are kept, in the "resolved hostnames cache" to speed up the resolution process. The rhcache is synchronized with ANDNA, therefore its stored entries will expire exactly when the registered hostnames expire in ANDNA. - Scattered Name Service Disgregation http://lab.dyne.org/Ntk_SNSD The SNSD is the ANDNA equivalent of the SRV Record of the Internet Domain Name System, which is defined here: http://www.ietf.org/rfc/rfc2782.txt SNSD isn't the same of the "SRV Record", in fact, it has its own unique features. - Internet compatibility - internet sharing * Multi-inet-gateways. The Netsukuku nodes will now automatically use multiple inet-gateways to connect to the Internet, therefore their Internet connection will be effectively load-balanced. * Anti-loop multi-igw shield. The nodes which share their Internet connection will also automatically use the shared connection of the other nodes. Through a simple marking system, death loops are avoided. * Traffic shaping. The nodes which share their Internet connection can now shape it, in this way they'll prioritize their local outgoingtraffic and the lowdelay one (f.e. SSH). - Routes based on bandwidth and latency http://lab.dyne.org/Ntk_bandwidth_measurement - NetsukukuD: - low memory and CPU usage - it can run smoothly on a small Access Point - Support for multipath routes: to reach a destination node, the packets will use, at the same time, more than one route. - support for multi network interfaces - Multi interfaces multipath: if the node can reach a rnode trough multiple interfaces, it uses them all with a multipath route.