Netsukuku architecture overview
An important part of the program consist of map of routes management, which must be known by every node.
Netsukuku topology divides map in levels. Nodes are grouped in g(nodes), which once again are grouped in g(g(nodes)) and so on. Every element in level 0 represents a node, every element of level 1 represent a g(node), ...
In this way, even if there are 256^4 (potential) nodes, routes map has to contain only 256*4 nodes/g(nodes).
A map like this is implemented by class Map.
In particular, classe Map is a basis class. Infact, to represent all the routes known by a host (a route lead to a node, ora a g(node), a g(g(node)), etc) the class MapRoute (which is located in module route) is used.
One of main aims of Netsukuku is to provide a light routing mechanism, which can be executed by low performance host. One of means used to reach this scope is that the algorithm is a distributed algorithm.
This can be obtained implementing RPC (Remote Procedure Call) mechanisms (Remote Procedure Call).
Il RPC module provides basic methods for implementing a distributed algorithm.
Radar scan and Neighbourhood Management
Every host must be able to detect neighbour nodes, which means nodes part of its LAN. These nodes are the ones which can be reached directly, and they can be part of the same g(node) or not (in that case that node is called "border-node"). It must even be able to evaluate link quality.
At the moment, that quality is indicated only by RTT.
Multithread in Netsukuku
Program uses threads in many of its parts. In particular, microthreads has been used (they are provided by Phyton Stackless version).
These platform allows to create an indefinite number of threads without waste of memory or CPU. Using normal S.O. threads would be much more expensive in terms of overhead of memory and CPU.
To obtain a light implementation, able to work even on low-performance devices (like access points), is crucial to Netsukuku.
Multithread allow to implement single aspects of the program like they were managed by autonomous programs, and this is a great advantage.
A portion of code is responsible of an aspect, call it A. This part of code must be able to start an operation which is managed by another part of code, because it is about aspect B. This function call must be non-blocking to the algorithm which manages part A.
D'altro canto è necessario avere a disposizione delle tecniche che consentano di coordinare le operazioni dei diversi threads che sono in esecuzione contemporaneamente.
To avoid that many threads to use the same resource, even mantaining the possibility to have non-blocking calls, two technics have been implemented in Netsukuku: -dispatcher -atomic microthreads
These technics are explained in more detail in the micro module page.
QSPN is the algorithm used by Netsukuku to explore the net and to find most efficient routes. Like you can find in document qspn.pdf, it consists in the trasmission of so-called Extended Tracer Packets (ETP), which takes place when changes interest a link between two nodes.
In particular the document describes:
the algorithm that node A has to execute to generate an ETP in the case that its link to B changes its REM (its efficency) or in the case it is a new link; generated ETP is then sent to B (using remotable method Etp.etp_exec). the algorithm that node A has to execute to generate an ETP in the case that its link to B goes down; generated ETP is then sent to all of A neighbours (see previous). the algorithm that node C has to execute to process informations received by node N via ETP and to propagate them (C can be B, so N can be A)
All of these algorithms are implemented in QSPN module.
An overview of event module
An overview of package network
An overview of class Hook
An overview of p2p module
An overview of each of the basic services implemented as p2p coord module
Analize differences from branch networking-abstraction