Differences between revisions 4 and 5
Revision 4 as of 2009-05-07 18:44:58
Size: 1974
Editor: lukisi
Comment:
Revision 5 as of 2009-05-07 18:57:44
Size: 1874
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
Quando il nodo corrente assiste a questo split e scopre di essere nel blocco più piccolo, oppure in caso di parità quello con vita minore, deve procedere ad un re-hook. Quando il nodo corrente assiste a questo split e scopre di essere nel blocco più piccolo deve procedere ad un re-hook.
Line 11: Line 11:
Partendo dal secondo livello più alto della mappa di route - il livello più alto non viene preso in considerazione perché saremmo in presenza della divisione dell'intera rete Netsukuku - la funzione cerca il primo livello in cui il numero di nodi raggiungibili ora si è più che dimezzato rispetto al momento prima della processazione dell'ETP. Partendo dal secondo livello più alto della mappa di route - il livello più alto non viene preso in considerazione perché saremmo in presenza della divisione dell'intera rete Netsukuku - la funzione cerca il primo livello in cui il numero di nodi raggiungibili ora è '''minore o uguale''' al numero di nodi non più raggiungibili rispetto al momento prima della processazione dell'ETP.
Line 13: Line 13:
'''''TODO''': Verificare la correttezza del calcolo, in particolare nb_node tiene conto anche del nodo corrente? Inoltre cosa avviene se lo split è proprio a metà a causa di un link rotto? e cosa se lo split è a metà a causa di un nodo che si spenge?'' '''''TODO''': Verificare la correttezza del calcolo, in particolare nb_node tiene conto anche del nodo corrente? Se entrambi i tronconi fanno rehook è un problema?''

La funzione gnodes_split

Nel caso in cui, con la perdita di un link, il nodo corrente perde tutte le route disponibili per un certo numero di nodi, siamo di fronte allo split di un gnodo. Questo vale sia a livello 0 sia ai livelli superiori. Al livello 0 si tratta di nodi che non sono più raggiungibili per via dello split del gnodo di livello 1. Al livello 2 si tratta di gnodi di livello 1 non più raggiungibili per via dello split di un gnodo di livello 2. E via dicendo.

Quando il nodo corrente assiste a questo split e scopre di essere nel blocco più piccolo deve procedere ad un re-hook.

Vediamo come si implementa questa verifica.

La funzione gnodes_split viene richiamata dalla communicating_vessels quando questa è stata chiamata per via dell'esecuzione di un ETP ricevuto. E riceve da essa come argomenti old_node_nb e cur_node_nb, il numero di nodi nella mappa di routes, per ogni livello, che erano presenti prima della processazione dell'ETP e che sono presenti ora.
Partendo dal secondo livello più alto della mappa di route - il livello più alto non viene preso in considerazione perché saremmo in presenza della divisione dell'intera rete Netsukuku - la funzione cerca il primo livello in cui il numero di nodi raggiungibili ora è minore o uguale al numero di nodi non più raggiungibili rispetto al momento prima della processazione dell'ETP.
TODO: Verificare la correttezza del calcolo, in particolare nb_node tiene conto anche del nodo corrente? Se entrambi i tronconi fanno rehook è un problema?
Se questo livello esiste è il livello al quale va fatto un rehook.
La funzione avvia in un microthread la microfunc hook e poi restituisce True.

Se invece non siamo in questa situazione, la funzione restituisce False.

Netsukuku/ita/GnodesSplit (last edited 2009-05-08 07:32:27 by lukisi)