Modulo QSPN - Dettagli Tecnici

Il presente documento assume che siano stati letti il documento di Analisi Funzionale e quelli in esso indicati (Esplorazione della rete e Percorsi disgiunti).

Requisiti

L'utilizzatore del modulo QSPN per prima cosa inizializza il modulo richiamando il metodo statico init di QspnManager. In tale metodo viene anche passata l'istanza di INtkdTasklet per fornire l'implementazione del sistema di tasklet.

Prima di iniziare ad usare il modulo QSPN, il nodo deve essere a conoscenza del suo indirizzo Netsukuku; deve essere un indirizzo non ancora preso nella rete; deve essere un indirizzo compatibile con gli archi del nodo, cioè tale che se il nodo entra in un g-nodo esistente g di livello i abbia almeno un arco verso un altro nodo appartenente a g. Di fatto per ottenere questo il nodo contatta i suoi vicini e raccoglie informazioni sui loro g-nodi di appartenenza ai vari livelli, compreso il livello più alto; poi sceglie uno di questi g-nodi per entrarvi, quindi contatta il Coordinator del g-nodo scelto e si accorda con lui per farsi assegnare un posto al suo interno. Tutta questa operazione, ripetiamo, non è di pertinenza del modulo QSPN.

La strategia che si adotta per la scelta del g-nodo non è di competenza del modulo QSPN. Viene descritta nel documento del modulo Migrations. TODO: inserire.

Dallo stesso Coordinator del g-nodo g il nodo ottiene anche altre informazioni che servono al modulo QSPN, come l'anzianità di g e dei suoi g-nodi superiori e l'anzianità del g-nodo che il nodo corrente costituirà, per poter produrre il proprio fingerprint di nodo. L'identificativo del fingerprint è generato dal nodo come numero random in uno spazio abbastanza grande di modo che sia presumibilmente univoco a livello di rete.

Quindi il nodo istanzia il suo QspnManager passando al costruttore:

Quando il QspnManager memorizza i suoi archi, per ognuno genera un identificativo, cioè un intero random in uno spazio grande. Memorizza in una lista gli archi, accertandosi che non ci siano archi ripetuti. Memorizza inoltre un dizionario (HashMap) che associa identificativi e archi.

Quando ci sono variazioni sugli archi, il nodo richiama sul QspnManager i metodi:

In questi metodi, in particolare in arc_add e arc_remove, il QspnManager gestisce sia la lista degli archi che il dizionario che associa identificativi e archi.

Inoltre il modulo non assume che anche il suo utilizzatore mantenga le istanze degli archi. Questo significa che per vedere se un arco è nella sua lista si basa sul metodo i_qspn_equals fornito dalla IQspnArc. Sul metodo arc_is_changed sostituisce l'istanza corrente nella sua lista (e nel suo dizionario degli identificativi) con quella passata (non assumendo che si tratti della stessa istanza) e dovrà fare lo stesso cambio su tutte le istanze della classe NodePath.

Deliverables

Quando viene costruito il QspnManager gli viene passata una lista di archi. Se non ci sono archi significa che il nodo sta generando una nuova rete, quindi il modulo considera da subito completato il suo bootstrap. Il modulo lo segnala attraverso il segnale qspn_bootstrap_complete di QspnManager.

Se invece ci sono degli archi il modulo li memorizza in una sua lista my_arcs e si considera in fase di bootstrap. In questo caso chiede ai vicini di comunicargli le loro mappe con un ETP completo.

Le richieste sono fatte su ogni singolo arco, in parallelo, con protocollo reliable. Se una richiesta fallisce (per problemi al link) il relativo arco viene rimosso dalla lista del modulo (my_arcs) e viene emesso il segnale arc_removed di QspnManager.

Alcuni dei nodi vicini possono rifiutare la richiesta perché il nostro nodo non risulta tra i loro archi. Anche per questi il relativo arco viene rimosso dalla lista del modulo (my_arcs) e viene emesso il segnale arc_removed di QspnManager.

Alcuni dei nodi vicini possono rifiutare la richiesta perché a loro volta non hanno ancora completato il loro bootstrap. Per questi non viene rimosso l'arco, ma semplicemente non abbiamo potuto ricevere da loro un ETP.

Quando tutte le richieste hanno terminato si avrà una lista di ETP. Se tale lista risultasse vuota allora il modulo emette il segnale failed_hook di QspnManager affinché il nodo consideri fallito l'ingresso nella rete e riprovi da capo. Quando viene emesso il segnale failed_hook l'utilizzatore del modulo è tenuto a scartare l'istanza di QspnManager.

Se invece la lista contiene uno o più ETP, il modulo li elabora. Poi considera completato il suo bootstrap, quindi emette il segnale qspn_bootstrap_complete di QspnManager.


Il modulo segnala quando rimuove dalla sua lista un arco non funzionante attraverso il segnale arc_removed di QspnManager.


Il modulo segnala l'inserimento di un nuovo g-nodo nella sua mappa attraverso il segnale destination_added di QspnManager e la rimozione di un g-nodo attraverso il segnale destination_removed di QspnManager.


Il modulo segnala l'inserimento di un nuovo percorso verso una destinazione attraverso il segnale path_added, la rimozione di un percorso attraverso il segnale path_removed e il cambio di qualche parametro in un percorso attraverso il segnale path_changed di QspnManager.


Il modulo segnala il cambio nel fingerprint di uno dei suoi g-nodi attraverso il segnale changed_fp di QspnManager.


Il modulo segnala il cambio nel numero di nodi stimati all'interno di uno dei suoi g-nodi attraverso il segnale changed_nodes_inside di QspnManager.


Il modulo segnala il rilevamento di uno split in un g-nodo di sua conoscenza attraverso il segnale gnode_splitted di QspnManager.


Il modulo permette di vedere se ha completato il suo bootstrap con il metodo is_bootstrap_complete di QspnManager.


Il modulo permette di ottenere la lista dei g-nodi nella sua mappa con il metodo get_known_destinations di QspnManager.


Il modulo permette di ottenere la lista di percorsi noti verso un certo g-nodo con il metodo get_paths_to di QspnManager.


Il modulo permette di leggere il fingerprint di uno dei suoi g-nodi con il metodo get_fingerprint di QspnManager.


Il modulo permette di conoscere la stima del numero di nodi all'interno di uno dei suoi g-nodi con il metodo get_nodes_inside di QspnManager.

Funzioni di appoggio

Alcune funzioni, definite e usate internamente al modulo, sono aggiunte alle classi così come sono state descritte nell'analisi funzionale. Le illustriamo ora perché nel seguito del documento sono riportati alcuni algoritmi che ne fanno uso.

Aggiunte alla classe NodePath:

Produzione e trasmissione di ETP

La costruzione e il passaggio di ETP quando necessario ai propri vicini è realizzata dal modulo in autonomia, senza necessitare di interventi dal suo utilizzatore.

Per sapere a chi deve inviare gli ETP e da chi deve riceverli il modulo si basa sugli archi che gli sono stati passati.

Quando riceve un ETP se non riesce ad associarlo ad uno degli archi che conosce (si intende anche dopo aver atteso il tempo di rilevamento) allora lo ignora. Quando riceve una richiesta di ETP se non riesce ad associarla ad uno degli archi che conosce allora risponde con l'eccezione QspnNotAcceptedError.

Il modulo assume che i nodi collegati ai suoi archi appartengano alla sua stessa rete.

L'elaborazione degli ETP ricevuti dai miei vicini che appartengono alla mia stessa rete da come risultato l'aggiornamento della mia mappa; allo stesso tempo mi permette anche di capire quali informazioni saranno di interesse anche per gli altri miei vicini, quindi mi consente di costruire un messaggio che sia esaustivo e allo stesso tempo più piccolo possibile. Il dettaglio di come tale elaborazione avviene è descritto nel documento esplorazione.

Metodi remoti

L'implementazione della trasmissione di ETP ai vicini avviene con l'uso di due metodi remoti: get_full_etp e send_etp .

Il metodo get_full_etp viene chiamato dal nodo n sul vicino v quando vuole ottenere da v un ETP completo . Il documento di esplorazione descrive cosa si intende per ETP completo. Quando un nodo chiede espressamente un ETP ad un suo vicino (o a tutti i vicini uno alla volta) si tratta sempre di un ETP completo.

Il metodo send_etp viene usato dal nodo n quando vuole spontaneamente inviare un ETP ad un suo vicino o a più vicini in broadcast. In questo caso può trattarsi di un ETP completo oppure no. Per questo il metodo send_etp prevede un parametro booleano che dice se l'ETP è completo.

Produzione del primo ETP

Prendiamo in esame un nodo che ha appena costituito una nuova rete. Il modulo QSPN cioè non riceve nessun arco. La sua mappa è vuota. Vediamo cosa deve fare per costruire un nuovo ETP completo, presumibilmente perché un nuovo nodo ha appena fatto ingresso nella rete e gli chiede un ETP.

Innanzi tutto la sua mappa è vuota, quindi la lista dei percorsi P è vuota.

Ci sono due informazioni che vanno inserite nell'ETP e che sono rappresentate con classi che il modulo non conosce: il fingerprint dei suoi g-nodi ai vari livelli e il suo indirizzo di nodo.

Al modulo viene passato l'indirizzo del nodo come istanza dell'interfaccia IQspnMyNaddr, che a sua volta richiede l'interfaccia IQspnNaddr. Nell'ETP va inclusa una istanza di IQspnNaddr, quindi questa istanza va bene. Il modulo assume che l'istanza sia anche un oggetto serializzabile.

Al modulo viene passato il fingerprint del nodo a livello 0 come istanza dell'interfaccia IQspnFingerprint. Anche questa si assume che sia un oggetto serializzabile. Inoltre, tramite il metodo i_qspn_construct chiamato sull'istanza del fingerprint a livello 0 e passando un set vuoto (ci riferiamo sempre ad un nodo con la mappa ancora vuota), gli viene restituita un'altra istanza di IQspnFingerprint che è il fingerprint del suo g-nodo a livello 1. Anche questa si assume che sia un oggetto serializzabile. E così via.

La lista del numero approssimativo di nodi all'interno dei propri g-nodi ai vari livelli, per un nodo con la mappa ancora vuota è banalmente una lista con l volte il valore 1.

Nell'ETP vi è anche una lista di HCoord che rappresenta il percorso di questo ETP. Un nodo che produce un ETP nuovo vi mette una List<HCoord> vuota.

In conclusione il modulo è in grado di costruire una istanza della classe EtpMessage con i dati necessari. Si tratta di un oggetto serializzabile, che quindi può essere usato nelle chiamate (o risposte) a metodi remoti.

Processazione di un set di ETP

Gli algoritmi illustrati nei successivi paragrafi, volti a processare un set di ETP, vengono eseguiti dal nodo n in queste possibili circostanze:

Rielaborazione dei percorsi in ogni ETP ricevuto

Sia m un ETP che il nodo n riceve dal nodo v attraverso l'arco a.

Quando il modulo riceve una istanza di EtpMessage che gli viene trasmessa in una chiamata a metodo remoto, questa contiene le istanze degli oggetti che l'utilizzatore del modulo (nell'altro nodo) ha costruito e che il modulo continua a conoscere solo in quanto implementazioni delle interfacce a lui note. Inoltre riconoscendo l'arco a da cui ha ricevuto il messaggio può ottenere l'istanza di IQspnCost che rappresenta il suo costo. Anche questa si assume che sia un oggetto serializzabile. Infine, sempre avendo individuato l'arco a, ha individuato l'identificativo id ( a ) , che è un intero.

Il nodo n calcola il livello i del minimo comune g-nodo tra n e v.

Il nodo n esamina la lista di hop percorsi da m. Per prima cosa esegue la Grouping Rule su tale lista per renderla coerente con i g-nodi a cui n appartiene. Poi esegue la Acyclic Rule sulla lista, e se vede che m era già passato per il mio nodo (o g-nodo) lo ignora del tutto.

Infine n esamina il set di percorsi P contenuto in m, ma deve renderli coerenti con i suoi g-nodi. Ecco come realizza questo:

Spieghiamo il punto 4. La ricezione di un ETP comporta sempre l'acquisizione di qualche informazione sulla rete, quindi contribuisce a popolare la mappa di n. Infatti, anche quando la lista P nell'ETP m fosse vuota, l'ETP contiene intrinsecamente un percorso verso il massimo distinto g-nodo di v per n, che indichiamo con vi-1. Per rappresentare questo percorso intrinseco, il modulo nel nodo n costruisce una istanza della classe EtpPath con questi dati:

Spieghiamo il punto 5. Siccome m è un ETP completo, tutti i percorsi che n può usare passando per v sono presenti in m.P . Quindi i vecchi percorsi che n conosceva e che non sono in m.P andranno rimossi dalla mappa di n .

Spieghiamo il punto 6. In tutte le istanze di EtpPath ricevute nell'ETP (più quella costruita come detto adesso per rappresentare il percorso intrinseco verso il g-nodo vicino) il costo del percorso rappresenta il costo da v alla destinazione. Invece il costo da n ad v è il costo dell'arco a. Questo dato è già memorizzato nell'oggetto arco che comunque il modulo deve mantenere associato al percorso, per questo nella mappa interna del nodo n ogni percorso è in realtà memorizzato come istanza della classe NodePath, la quale include l'istanza di EtpPath.

Variazioni nella mappa di n

Quando abbiamo descritto, nel documento esplorazione, la gestione degli eventi che portano a variazioni nel grafo della rete, abbiamo più volte usato diciture quali "n aggiorna la sua mappa" e "mette in P i percorsi che nella sua mappa hanno subito variazioni".

Qui riportiamo l'algoritmo che realizza queste macro-operazioni. Inoltre l'algoritmo riportato evita di occupare memoria con percorsi che non sono disgiunti da altri già noti, come richiesto nell'analisi funzionale. Infine si occupa di emettere i segnali di variazioni nella mappa del nodo (nuova destinazione, nuovo percorso, ...) e i segnali di g-nodi splittati.

Il rilevamento dello split di un g-nodo d si ha quando per raggiungere d vengono rilevati due percorsi che differiscono per il loro fingerprint e se questa situazione si mantiene per un certo lasso di tempo. Tale tempo di tolleranza è direttamente proporzionale alla somma delle latenze associate ai due percorsi che differiscono; ma il modulo QSPN non ha questa informazione in quanto il costo associato ad un percorso non sappiamo se sia espresso in latenza, in larghezza di banda o in altra metrica; quindi il calcolo di tale tempo di tolleranza va demandato all'utilizzatore del modulo il quale fornisce una callback attraverso l'istanza di IQspnThresholdCalculator. Per dare il massimo del supporto a questa callback vengono passate le istanze di IQspnNodePath che rappresentano i percorsi discordi. Da queste la callback potrà estrapolare i costi e sommarli se si tratta in effetti di latenze. Altrimenti la callback potrà leggere la destinazione e confrontarla con il proprio indirizzo per risalire al livello del minimo g-nodo comune, chiedere allo stesso modulo QSPN la stima dei nodi all'interno di tale livello e finalmente proporre un tempo di tolleranza sulla base di questo dato. Ricevuto questo tempo, il modulo si occupa di emettere alla sua scadenza il segnale gnode_splitted di QspnManager se la situazione si è mantenuta.

Algoritmo

Il nodo n, dopo aver rielaborato i percorsi nel set di ETP ricevuti, si trova infine con un set di percorsi nuovi che chiamiamo Q. Indichiamo con M l'insieme dei percorsi che già prima il nodo n conosceva, cioè la sua mappa.

Ora la mappa di n è aggiornata. Inoltre abbiamo in P l'elenco dei percorsi nella mappa di n che hanno subito variazioni.

Infine abbiamo in B tutte le destinazioni per cui si ritiene necessario inviare un nuovo flood. Quindi:

Variazioni nei propri g-nodi

Dopo aver completato un aggiornamento della propria mappa, il nodo n aggiorna anche le informazioni relative ai propri g-nodi, cioè fingerprint e numero di nodi all'interno. Se ci sono state variazioni n se ne accorge e questo è importante per decidere se l'ETP ricevuto va inoltrato ai suoi vicini.

Supponiamo che il nodo n riceve un percorso p verso la destinazione d che prima non conosceva. La destinazione d è un g-nodo di livello i all'interno del suo g-nodo di livello i+1. Nel percorso p è anche indicato il fingerprint di d e il numero di nodi interni al g-nodo d. Il fingerprint di d va ora incluso nel set di fingerprint di g-nodi di livello i da passare al metodo 'i_qspn_construct' del fingerprint del g-nodo di livello i di n per ottenere il fingerprint del g-nodo di livello i+1 di n. Analogamente, il numero di nodi interni a d va a sommarsi a quelli interni agli altri g-nodi di livello i e al numero di nodi interni al g-nodo di livello i di n per ottenere il numero di nodi interni al g-nodo i+1 di n.

Quando invece si riceve un percorso verso una destinazione d che già si conosceva attraverso altri percorsi, può capitare che le informazioni riguardo d differiscano.

Se per un g-nodo d vengono rilevati due percorsi che differiscono per il loro fingerprint e se questa situazione si mantiene per un certo lasso di tempo, questo è sintomo dello split del g-nodo d. Il modulo lo segnalerà con un evento, come descritto prima nell'algoritmo. Nel frattempo il modulo mantiene e trasmette tutti i percorsi verso d che conosce con il loro fingerprint, ma soltanto i percorsi con il fingerprint assegnato dal più anziano x all'interno di d vengono restituiti all'esterno del modulo con il metodo get_paths_to ( d ) .

Se per un g-nodo d vengono rilevati due percorsi che differiscono per il numero di nodi interni a d, invece, questo non indica che il g-nodo d sia splittato, infatti le variazioni nel numero di nodi possono venire ignorate se il cambiamento non è massiccio (per evitare eccessivo traffico). In questi casi il nodo prende per buono il numero di nodi come riportato dal percorso più veloce. Userà questa informazione per calcolare il numero di nodi (stimato) all'interno del suo g-nodo di livello i+1.

Quando si calcolano il fingerprint e il numero di nodi interni al proprio g-nodo di livello i, per ogni g-nodo noto di livello i-1 si usano i dati riportati dai percorsi verso quel g-nodo che riportano il fingerprint più anziano, in caso ce ne siano di discordi.

Un approccio particolare va attuato a livello i = 1. Considerando il proprio g-nodo di livello 1, i suoi componenti sono singoli nodi. Per i singoli nodi non ha senso pensare ad uno split, quindi se due percorsi verso una data destinazione di livello 0 riportano un fingerprint diverso può solo significare che il vecchio nodo è morto e un altro nodo ha preso la sua posizione; è solo questione di tempo prima che uno dei due fingerprint scompaia. Non avrebbe senso inoltre cercare di stabilire quale dei due fingerprint discordi sarebbe il più anziano, cercando di confrontare l'anzianità dei suoi g-nodi interni. Infine c'è da dire che si sa con certezza che il numero di nodi interni ad ogni singolo membro di un g-nodo di livello 1 (cioè il numero di nodi interni ad un singolo nodo) è 1. Queste osservazioni saranno chiare quando sotto verrà illustrato l'approccio per i livelli maggiori di 1.

Illustriamo l'approccio da usare a livello 1. E' noto il fingerprint fp0 del mio nodo. Poniamo nn0 = 1. Siano g1 , g2 , ..., gy i nodi di livello 0 presenti nella mia mappa. Il calcolo di fp1 dipende da fp0 e dai fingerprint fp(gj) degli altri g-nodi. Il calcolo di nn1 è dato da 1 (cioè nn0) più il numero degli altri nodi. Per ogni gj prendiamo solo il percorso più rapido che abbiamo nella mappa e diamo per buono il fingerprint da esso riportato.

Illustriamo l'approccio da usare ai livelli maggiori. Si parte dal livello i = 2 e si sale fino a l. Diamo per buono il fingerprint fpi-1 del mio g-nodo di livello i-1 e il numero di nodi al suo interno nni-1. Siano g1 , g2 , ..., gy i g-nodi di livello i-1 presenti nella mia mappa. Il calcolo di fpi dipende da fpi-1 e dai fingerprint fp(gj) degli altri g-nodi. Allo stesso modo il calcolo di nni dipende da nni-1 e dal numero di nodi nn(gj) all'interno degli altri g-nodi. Sia gj uno di questi e siano p1(gj) , p2(gj) , ..., px(gj) i percorsi noti verso gj. Raggruppiamo i percorsi in base al fingerprint che ciascuno riporta, che potrebbero essere diversi. Prendiamo solo il gruppo di percorsi che hanno il fingerprint che risulta essere stato assegnato dal g-nodo interno più anziano (metodo i_qspn_elder_seed). Consideriamo questo fingerprint come il fingerprint fp(gj) di gj. Inoltre da questo gruppo prendiamo il percorso più rapido e consideriamo il numero di nodi riportato da questo come il numero di nodi nn(gj) interni a gj. Ripetiamo per tutti i g-nodi di livello i-1 presenti nella mia mappa e usiamo questi valori per il calcolo delle analoghe informazioni relative al mio g-nodo di livello i.

Quando queste informazioni portano ad una variazione nel fingerprint di uno dei g-nodi del nodo corrente, il QspnManager emette il segnale changed_fp. Quando portano ad una variazione nel numero di nodi interni ad uno dei g-nodi del nodo corrente, emette il segnale changed_nodes_inside.

Algoritmo

Dopo aver aggiornato la sua mappa sulla base di un set di ETP, il nodo n procede così per ricalcolare le informazioni dei propri g-nodi:

Ora abbiamo in changes_in_my_gnodes se sono state apportate variazioni alle informazioni relative ai g-nodi di n.

Produzione di percorsi da mettere in un ETP da inviare

La valorizzazione dei dati in una istanza di EtpPath, cioè un percorso da includere in un ETP da inviare, si fa in due fasi.

La prima fase avviene durante l'algoritmo con cui il nodo n aggiorna la sua mappa partendo dai nuovi percorsi noti. In questa fase si valorizzano tutti i dati che possono essere ricavati dalla istanza di NodePath che è stata aggiunta/variata/rimossa nella mappa di n .

Sia q tale istanza di NodePath. Indichiamo con q.path l'istanza di EtpPath inclusa in q. Indichiamo con q.arc l'istanza di IQspnArc inclusa in q.

Il nodo n prepara una nuova istanza p di EtpPath. Copia tutte le informazioni da q.path a p; come costo indica q.cost, cioè la somma dei costi q.path.cost e q.arc.cost . Poi p viene messa in un set P con cui comporre l'ETP.

La seconda fase avviene alla fine degli aggiornamenti alla mappa. Questo perché in questa fase si valorizzano i dati che vanno ricavati non solo dalla istanza di NodePath in esame ma anche da altre informazioni contenute nella mappa di n .

Il nodo n cicla tutte le istanze p in P . Per ognuna, ricalcola tutti i valori booleani che indicano se il percorso p va ignorato all'esterno di un suo g-nodo.

Alla fine tutto il contenuto di P è pronto per essere messo nell'EtpMessage da inviare.

Proof of concept

Come proof of concept è stato realizzato un programma, qspnclient, che si avvale del modulo QSPN per stabilire come impostare le rotte nelle tabelle di routing del kernel di una macchina. Si tratta di un programma specifico per un sistema Linux.

Questo programma imposta le rotte del sistema. L'utente sarà quindi in grado di verificare che il sistema riesca effettivamente a stabilire connessioni con gli altri nodi della rete, che le rotte siano quelle che ci si attende, eccetera. Inoltre il programma interattivamente consente di chiedere al modulo QSPN le informazioni che ha raccolto e mostrarle all'utente.

Di seguito descriviamo le operazioni svolte da questo programma. Sarà interessante anche perché alcuni aspetti analizzati qui saranno ripresi nella realizzazione del demone ntkd completo.

Interazione del programma con l'utente

Il programma qspnclient prevede che l'utente immetta, come argomenti della riga di comando e in modo interattivo dalla console durante la sua esecuzione, tutti i requisiti del modulo. Anche i parametri che normalmente sarebbero individuati in modo autonomo dal demone ntkd (per esempio l'identificativo del nodo, gli indirizzi di scheda, ...) nel caso del qspnclient sono espressamente indicati dall'utente, questo per rendere più facilmente riproducibili gli ambienti di test.

Nel dettaglio questi sono i dati che il programma richiede all'utente:

In modo interattivo vengono anche avviate le operazioni del modulo QSPN. Per il primo nodo n0 che forma la rete, il comando di avvio operazioni viene dato subito dopo il lancio del programma, quando ancora il nodo non ha costituito alcun arco. Per gli altri nodi è necessario prima dare almeno un comando di costituzione di un arco con un vicino e poi dare il comando di avvio operazioni. Ad esempio si lancia il programma sul nodo n1, poi si da il comando interattivo (sulla console del nodo n1) di costituzione di un arco con n0, infine si da il comando interattivo (sulla console del nodo n1) di avviare le operazioni. E' inoltre necessario che il corrispettivo comando di costituzione dell'arco venga dato anche sulla console del nodo n0, dopo l'avvio delle operazioni di n1 ma in tempi rapidi. Il tempo massimo di rilevamento dell'arco è infatti fissato dal programma qspnclient a 10 secondi.

In generale quando si formano archi (all'avvio di un nuovo nodo nella rete, ma anche in seguito quando due nodi già entrati formano per qualche motivo un nuovo arco che prima non c'era) e quando si rimuovono archi occorre che i comandi vengano dati dalle console di entrambi i nodi. Queste rilevazioni infatti non sono compiti del modulo QSPN.

Al lancio del programma qspnclient l'utente indica attraverso appositi flag come vuole che il nodo si comporti riguardo le forme di contatto anonimo. Questo concetto verrà spiegato più sotto. Il comportamento di default del programma, se l'utente non indica alcun flag a riguardo, è di:

Indirizzi di scheda e archi verso i vicini

Fra le cose che il programma qspnclient deve gestire senza alcun intervento da parte del modulo QSPN, vi è la costituzione di archi con i vicini. Si tratta di archi che il modulo QSPN riceve come requisito, attraverso i quali deve essere messo in grado di comunicare con i vicini, anche in modo reliable, prima ancora di iniziare a trasmettere e ricevere messaggi ETP, quindi prima di sapere l'indirizzo Netsukuku dei suoi vicini o le destinazioni che possono essere raggiunte attraverso di essi. Questo viene realizzato dal programma qspnclient, e sarà così anche per il demone ntkd, con l'uso di indirizzi locali di scheda. Quindi il programma qspnclient, senza avvalersi del modulo QSPN, ha questi compiti:

Spazio di indirizzi Netsukuku

Gli indirizzi dei nodi nella rete Netsukuku, nella sua attuale implementazione, vanno ricavati nella classe IPv4 10.0.0.0/8.

La rete viene suddivisa in un numero arbitrario di livelli. La notazione CIDR usata per individuare classi di indirizzi nelle reti IPv4, ci obbliga ad usare come gsize ad ogni livello una potenza di 2. In teoria, ad esempio, potremmo avere un livello 0 di gsize 5. Ma quando vogliamo indicare nelle tabelle di routing tutti gli indirizzi di un g-nodo di livello 1 (ad esempio da 10.1.2.0 a 10.1.2.4) non potremmo farlo in forma compatta. Invece se usiamo un livello 0 di gsize 8, per riferirci agli indirizzi nel g-nodo da 10.1.2.0 a 10.1.2.7 possiamo usare la notazione 10.1.2.0/29; per gli indirizzi da 10.1.2.8 a 10.1.2.15 useremo 10.1.2.8/29; e così via.

Indichiamo con l il numero dei livelli. Indichiamo con gsize(i) la dimensione dei g-nodi di livello i+1. Tali dimensioni devono essere potenze di 2. Indichiamo con g-exp(i) l'esponente della potenza di 2 che dà la dimensione dei g-nodi di livello i+1. Il numero di bit necessari a coprire lo spazio di indirizzi è dato dalla sommatoria per i da 0 a l-1 di g-exp(i). 𝛴 0 ≤ i < l g-exp(i).

Questo numero di bit non può essere maggiore di 22. Gli indirizzi nella classe 10.0.0.0/8 hanno 24 bit, ma due di questi li riserviamo per notazioni particolari (routing interno ai g-nodi e forma anonima).

Inoltre dobbiamo assicurarci che gsize(l-1)l. Cioè che nello spazio destinato al livello più alto sia possibile rappresentare un numero da 0 a l-1. Questo pure ci serve per la notazione usata per il routing interno ai g-nodi.

Indirizzi del nodo

Per assegnarsi un indirizzo IPv4, un nodo parte dal suo indirizzo Netsukuku, che è una sequenza di posizioni all'interno dei vari g-nodi di appartenenza ad ogni livello. Il nodo calcola per prima cosa il suo indirizzo globale N, che è un indirizzo IPv4 che identificherà in modo univoco quel nodo in tutta la rete.

Poi il nodo calcola un indirizzo Ni, che è sempre un indirizzo IPv4, che identificherà in modo univoco quel nodo nel suo g-nodo di livello i; questo per ogni i da 1 a l-1.

Tutti questi indirizzi il nodo se li assegna.

Inoltre, opzionalmente, il nodo può calcolare per ognuno di questi indirizzi (N, N1, N2, ...) un altro indirizzo corrispettivo per i pacchetti che gli sono destinati in "forma anonima". Si tratta sempre di ulteriori indirizzi IPv4 che identificano questo nodo in modo univoco (a livello globale o all'interno di un suo g-nodo). Questi però saranno usati, come vedremo in seguito, dai client per contattare questo nodo senza rivelare il proprio indirizzo. Il nodo quindi può assegnarsi questi indirizzi oppure no. Se lo fa significa che vuole dare la possibilità ai client di usare questo meccanismo per contattarlo e fargli richieste senza essere identificati.

L'opzione di accettare richieste anonime è distinta e indipendente dall'opzione di rendere anonimi i pacchetti che transitano per il nodo nel percorso verso un'altra destinazione. Quest'altra opzione verrà discussa in seguito.

In un altro documento viene spiegato come questi indirizzi vengono calcolati a partire dall'indirizzo Netsukuku. TODO


Vediamo come queste impostazioni si configurano in un sistema Linux e quindi quali operazioni fa il programma qspnclient.

In un sistema Linux il sistema si assegna un indirizzo associandolo ad una interfaccia di rete. In realtà ogni interfaccia può avere più indirizzi e anche lo stesso indirizzo può essere associato a più interfacce; inoltre anche se un indirizzo x viene associato alla interfaccia nicA e non all'interfaccia nicB, un pacchetto destinato a x ricevuto tramite l'interfaccia nicB giunge ugualmente al processo che sta in ascolto sull'indirizzo x.

Fatta questa premessa, come si comporta il programma?

Il programma, all'avvio, computa tutti i suoi indirizzi (nello spazio Netsukuku) e li associa tutti a ognuna delle interfacce di rete che gestisce.

Inoltre, prima di terminare, li rimuove da tutte le iterfacce che gestisce.

Rotte nelle tabelle di routing

Il programma deve istruire le policy di routing del sistema (che di norma significa impostare delle rotte nelle tabelle di routing) in modo da garantire questi comportamenti:


Vediamo come queste impostazioni si configurano in un sistema Linux e quindi quali operazioni fa il programma qspnclient. Esaminiamo prima l'aspetto del source natting e poi del routing.

Source NATting

Il source NATting in un sistema Linux può essere realizzato istruendo il kernel con il comando iptables (utilizzando una regola con l'estensione SNAT nella catena POSTROUTING della tabella nat). Quando un pacchetto da inoltrare rientra nei parametri di questa regola (un esempio di parametro che si può usare è l'indirizzo di destinazione del pacchetto che rientra in un dato range) allora il kernel modifica l'indirizzo mittente nel pacchetto sostituendolo con uno dei suoi indirizzi pubblici. Inoltre compie una serie di altre operazioni volte a mantenere inalterate il più possibile le caratteristiche della comunicazione (ad esempio la connessione stabilita dal protocollo TCP).

Ad esempio, con il comando «iptables -t nat -A POSTROUTING -d 10.128.0.0/9 -j SNAT --to 10.1.2.3» si ottiene che tutti i pacchetti da inoltrare alle destinazioni 10.128.0.0/9 vanno rimappati al mio indirizzo 10.1.2.3

Fatta questa premessa, come si comporta il programma?

Il programma, all'avvio, opzionalmente, istruisce il kernel per il source natting. Con questa configurazione il nodo si rende disponibile ad anonimizzare i pacchetti che riceve e che vanno inoltrati verso una destinazione che accetta richieste anonime.

L'opzione di rendere anonimi i pacchetti che transitano per il nodo nel percorso verso un'altra destinazione è distinta e indipendente dall'opzione di accettare richieste anonime, che è stata discussa sopra.

Se il nodo decide di implementare il source natting, calcola lo spazio di indirizzi che indicano una risorsa da raggiungere in forma anonima. Una volta calcolato il numero di bit necessari a ricoprire i vari livelli della nostra rete -si rilegga il paragrafo sopra sullo spazio di indirizzi Netsukuku- vanno considerati altri 2 bit in testa; il primo di questi va impostato e tutti gli altri sono liberi. Se ad esempio si usano tutti i 22 bit a disposizione per gli indirizzi, allora il range di indirizzi che indicano una risorsa da raggiungere in forma anonima è 10.128.0.0/9.

Poi il range viene ulteriormente scomposto in un numero di sottoclassi pari al numero dei livelli nella rete. Il primo blocco costituisce gli indirizzi globali delle risorse da raggiungere in forma anonima; si caratterizza per avere NON impostato il secondo bit. Nel nostro esempio, il range di questo blocco è 10.128.0.0/10.

Prendiamo ora ogni livello i della nostra rete, da 1 a l-1 inclusi, dove l è il numero di livelli. Il blocco del livello i costituisce gli indirizzi interni al nostro g-nodo di livello i delle risorse (interne al suddetto g-nodo) da raggiungere in forma anonima; si caratterizza per avere impostato il secondo bit e per avere codificato il numero i nei bit destinati all'identificativo del livello più alto.

Riprendiamo il nostro esempio e supponiamo che ci siano nella rete 10 livelli e il più alto abbia dimensione 16, vale a dire gsize(9) = 16, g-exp(9) = 4. Allora il blocco del livello i ha impostato il primo e il secondo bit ed ha codificato il numero i nei 4 bit dalla posizione 3 alla 6 incluse. Questi sono quindi i blocchi:

Supponiamo ora che il nostro nodo sia nel g-nodo di livello 9 con posizione 5 e, per semplicità, supponiamo posizione 0 a tutti gli altri livelli. Quindi -si rilegga il paragrafo sopra sugli indirizzi del nodo- il nostro nodo ha assegnati a se questi indirizzi (in forma non anonima):

Allora il programma istruisce il kernel di modificare i pacchetti destinati ai seguenti range indicando come nuovo indirizzo mittente uno dei propri indirizzi, come segue:

Quando il programma termina, se aveva istruito il kernel per fare il source natting, rimuove le regole che aveva messe nella catena POSTROUTING della tabella nat.

Routing

In un sistema Linux le rotte vengono memorizzate in diverse tabelle. Queste tabelle hanno un identificativo che è un numero da 0 a 255. Hanno anche un nome descrittivo: l'associazione del nome al numero (che in realtà è il vero identificativo) è fatta nel file /etc/iproute2/rt_tables.

In ogni tabella possono esserci diverse rotte. Ogni rotta ha alcune informazioni importanti:

Quando un pacchetto va inviato ad una certa destinazione, ci sono delle regole che dicono al sistema su quali tabelle guardare. Queste regole, visibili con il comando ip rule list, di default dicono di guardare per prima la tabella "local", per penultima la tabella "main" e per ultima la tabella "default". Tra la regola che dice di guardare la "local" e quella che dice di guardare la "main" possono essere inserite altre regole.

Ogni regola può dire semplicemente di guardare una tabella, oppure di guardarla solo a determinate condizioni. Una particolare condizione che ci torna utile è questa: "guarda la tabella XXX se il pacchetto da trasmettere è marcato con il numero YYY". La marcatura del pacchetto è virtuale, nel senso che i dati del pacchetto non sono affatto modificati, ma solo il sistema locale lo vede come marcato; ed è sempre il sistema locale che lo ha precedentemente marcato. Questa marcatura viene fatta da una parte del kernel che può essere istruita usando l'azione MARK del comando iptables.

Fatta questa premessa, come si comporta il programma?

Per ogni arco verso un vicino, il programma memorizza una rotta diretta (cioè senza gateway) nella tabella "main", indicando come destinazione l'indirizzo di scheda del vicino e come mittente preferito il proprio indirizzo di scheda. Questo lo abbiamo visto poco sopra; infatti il comando "ip route add" senza specificare un nome di tabella si riferisce alla tabella "main".

Il programma crea una tabella "ntk" con identificativo YYY, dove YYY è il primo identificativo libero nel file /etc/iproute2/rt_tables. Tale tabella sarà inizialmente vuota; in essa il programma andrà a mettere le rotte di pertinenza della rete Netsukuku, cioè quelle con destinazione nello spazio 10.0.0.0/8. Inoltre aggiunge una regola che dice di guardare la tabella "ntk" prima della "main".

Il programma, per ogni suo arco, crea un'altra tabella chiamata "ntk_from_XXX" con identificativo YYY, dove XXX è il MAC address del nodo vicino, YYY è il primo identificativo libero nel file /etc/iproute2/rt_tables. Questa tabella conterrà rotte da esaminare solo per i pacchetti da inoltrare che ci sono pervenuti attraverso questo arco. Il programma quindi aggiunge una regola che dice di guardare la tabella "ntk_from_XXX" se il pacchetto da trasmettere è marcato con il numero YYY. Inoltre istruisce il kernel di marcare con il numero YYY i pacchetti che hanno XXX come MAC di provenienza.

Anche le varie tabelle "ntk_from_XXX" conterranno solo rotte di pertinenza della rete Netsukuku, cioè quelle con destinazione nello spazio 10.0.0.0/8.

Inoltre, sia la tabella "ntk" sia le varie "ntk_from_XXX" conterranno la rotta "unreachable 10.0.0.0/8". Questa rotta verrà presa in esame solo se un pacchetto ha una destinazione all'interno dello spazio di Netsukuku, ma per tale destinazione non esistono altre rotte valide con una classe più restrittiva. In altre parole, una destinazione per la quale non si conosce nessun percorso. Questa particolare rotta dice che il pacchetto non potrà giungere a destinazione e il suo mittente ne va informato.

Sulla base degli eventi segnalati dal modulo QSPN, e se necessario richiamando i suoi metodi pubblici, il programma qspnclient popola e mantiene le rotte nelle tabelle "ntk" e "ntk_from_XXX". I percorsi segnalati dal modulo QSPN contengono sempre un arco del nodo corrente come passo iniziale e da tale arco si può risalire all'indirizzo di scheda del vicino. Le rotte nelle tabelle "ntk" e "ntk_from_XXX" infatti devono avere come campo gateway (gw) l'indirizzo di scheda del vicino, non il suo indirizzo Netsukuku.

Per ogni percorso scelto dal programma qspnclient per entrare in una tabella, in realtà il programma inserisce nella tabella fino a 4 rotte. Sia i il livello del g-nodo destinazione del percorso. Queste sono le rotte:

Quando il programma ha finito di usare una tabella (ad esempio se un arco che conosceva non è più presente, oppure se il programma termina) svuota la tabella, poi rimuove la regola, poi rimuove il record relativo dal file /etc/iproute2/rt_tables.