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.

QSPN

TODO:
Una panoramica per il package network (vedi il package network)
Una panoramica per il modulo micro (vedi il modulo micro) nella quale va detto anche quali funzioni in netsukuku sono eseguite in microthread e di queste quali vengono eseguite da un unico dispatcher in sequenza e quali invece sono eseguite in parallelo.
Una panoramica per il modulo qspn (vedi il modulo qspn)
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 la modulo coord)
Analizzare le differenza apportate dal branch networking-abstraction