Panoramica dell'architettura di netsukuku

Topologia

Una parte importante del programma consiste nella gestione della mappa delle route, che ogni nodo deve avere.

Secondo la topologia di Netsukuku la mappa si divide in livelli. I nodi si raggruppano in g(nodi), che si raggruppano in g(g(nodi)) e così via. Ogni punto del livello 0 rappresenta un nodo appartenente allo stesso g(nodo) dell'host corrente. Ogni punto del livello 1 rappresenta un g(nodo) appartenente allo stesso g(g(nodo)) dell'host corrente. E così via.
Alla fine, pur essendoci nella rete 256^4 (potenziali) nodi, la mappa di routes di ogni host deve contenere solo 256*4 nodi/gnodi.

Una mappa di questo tipo è implementata nella classe Map.

In particolare, la classe Map è una classe base. Per la rappresentazione della mappa delle routes che l'host corrente conosce per raggiungere i nodi e i g(nodi) si usa una sua derivata che è la classe MapRoute presente nel modulo route.

Distributed Computing

Un obiettivo che si prefigge Netsukuku è di essere un meccanismo di routing leggero, che possa essere eseguito da host con basse potenze di calcolo. Uno degli strumenti per raggiungerlo è il fatto che l'algoritmo di routing venga eseguito in modo distribuito.
Questo si ottiene con l'implementazione di meccanismi di RPC (Remote Procedure Call).

Il modulo RPC mette a disposizione i meccanismi di base per la costruzione di un algoritmo distribuito.

Radar Scan and Neighbourhood Management

Ogni host deve saper rilevare la presenza di nodi vicini, cioè altri nodi nella sua stessa LAN. Questi sono i nodi che si possono raggiungere direttamente, i quali possono essere dello stesso nostro g(nodo) ma anche no (cioè l'host può essere un cosidetto border-node)
Deve inoltre fare una valutazione sulla qualità del link verso quel suo vicino. Al momento la metrica usata per questa valutazione è solo il RTT.

La gestione di questa problematica è affrontata nel modulo radar, che la gestisce facendo uso dei meccanismi di distributed computing implementati ne il modulo RPC. Vedi anche la pagina Funzionamento del Radar.

Il modulo radar ha la responsabilità di emettere segnali (eventi) che attivino le funzioni di altri moduli (come il modulo qspn) quando vengono rilevati nuovi vicini.

Multithread in Netsukuku

Il programma fa uso di threads in diversi punti. In particolare si è adottato l'uso dei cosidetti microthreads, messi a disposizione dalla versione Python Stackless.

L'uso di questa particolare piattaforma consente di creare quanti microthreads si vogliono senza sprecare risorse di memoria o di CPU. L'uso dei classici threads implementati dal kernel del sistema operativo sarebbe molto più oneroso in termini di overhead di memoria e di CPU.
Ottenere una implementazione leggera, in grado di funzionare bene anche su dispositivi con basse risorse di calcolo (come gli access point) è cruciale per la riuscita del progetto Netsukuku.

L'uso del multithreading consente di implementare singoli aspetti del programma come se fossero gestiti da programmi autonomi e isolati. Questo è un grosso vantaggio.
Una parte di codice è responsabile di un aspetto dell'applicazione, chiamiamolo aspetto A. Questa parte di codice deve essere in grado di avviare una operazione che venga gestita da un'altra parte di codice, perché riguarda l'aspetto B. Questa chiamata deve essere non bloccante per l'algoritmo di gestione dell'aspetto A.
D'altro canto è necessario avere a disposizione delle tecniche che consentano di coordinare le operazioni dei diversi threads che sono in esecuzione contemporaneamente.
Per evitare che ci siano contemporaneamente molti thread che agiscono sulle stesse risorse, pur mantenendo la possibilità di sfruttare le chiamate "non bloccanti" di cui sopra, sono state implementate in Nestukuku due tecniche.

La prima è l'uso di dispatcher.

La seconda è l'uso di microthread atomici.

Queste tecniche sono dettagliate nella pagina che spiega il modulo micro.

L'uso di microthread stackless in modo cooperativo, inoltre, ha comportato la implementazione di tecniche per le sleep (vedi il modulo xtime) e per le operazioni di I/O sui socket (vedi il modulo microsock).

QSPN

Il QSPN è l'algoritmo usato da Netsukuku per la esplorazione della rete e la rilevazione delle routes più efficienti.
Come descritto nel documento qspn.pdf, esso consiste nella trasmissione dei cosidetti Extended Tracer Packets (ETP) che avviene in risposta a cambiamenti avvenuti nei link tra due nodi.
In particolare il documento descrive:

l'algoritmo che il nodo A deve eseguire per la produzione di un ETP nel caso in cui il link verso B cambi il suo REM, cioè la sua efficienza, oppure sia nuovo; poi A invia questo ETP a B (attraverso il remotable method Etp.etp_exec).
l'algoritmo che il nodo A deve eseguire per la produzione di un ETP nel caso in cui il link verso B venga completamente meno; poi A invia questo ETP a tutti i suoi vicini (vedi sopra).
l'algoritmo che il nodo C deve eseguire per processare le informazioni ricevute da N tramite un ETP e propagarle (C può essere lo stesso B e quindi N può essere A).

Questi algoritmi sono implementati nel modulo QSPN.

TODO:
Una panoramica per il modulo event (vedi il modulo event)
Una panoramica per il package network (vedi il package network)
Una panoramica per la classe hook (vedi la classe Hook)
Una panoramica per il modulo p2p (vedi il modulo p2p)
Una panoramica per ognuno dei servizi basilari implementati come p2p (vedi il modulo coord)
Analizzare le differenza apportate dal branch networking-abstraction