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.

Distributed Computing

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.

This functionality is implemented by Radar module, which is build on mechanisms RPC module because of its distributed nature. See also Radar working

Radar module has to emit signals (events) that activates other modules (like QSPN module when a new neighbour is detected.

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.

The usage of microthread stackless in cooperative mode, led to the implementation of technics for sleep (see xtime module) and I/O operation on sockets (see microsock module).


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:

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

Netsukuku/eng/notes (last edited 2010-03-12 08:26:20 by anonymous)