= Netsukuku architecture overview =

== Topology ==
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), ...
<<BR>>
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 [[../ClassMap|class Map]].

In particular, [[../ClassMap|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 [[../ClassMapRoute|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.
<<BR>>
This can be obtained implementing [[../RemotableFunctionsList|RPC (Remote Procedure Call) mechanisms]] (Remote Procedure Call).

Il [[../RPCModule|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.
<<BR>>
At the moment, that quality is indicated only by RTT.

This functionality is implemented by [[../RadarModule|Radar module]], which is build on mechanisms [[../RPCModule|RPC module]] because of its distributed nature. See also [[../RadarWorking|Radar working]]

[[../RadarModule|Radar module]] has to emit signals (events) that activates other modules (like [[../QSPNModule|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.
<<BR>>
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.
<<BR>>
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.
<<BR>>
D'altro canto è necessario avere a disposizione delle tecniche che consentano di coordinare le operazioni dei diversi threads che sono in esecuzione contemporaneamente.
<<BR>>
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 [[../MicroModule|micro module]] page.

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

== QSPN ==
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.
<<BR>>
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 [[../RemotableFunctionList|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)
<<BR>>
All of these algorithms are implemented in [[../QSPNModule|QSPN module]].



TODO:
<<BR>>
An overview of [[../EventModule|event module]]
<<BR>>
An overview of [[../PackageNetwork|package network]]
<<BR>>
An overview of [[../ClassHook|class Hook]]
<<BR>>
An overview of [[../P2PModule|p2p module]]
<<BR>>
An overview of each of the basic services implemented as p2p [[../CoordModule|coord module]]
<<BR>>
Analize differences from branch networking-abstraction
<<BR>>