Differences between revisions 4 and 5
Revision 4 as of 2009-05-22 14:42:56
Size: 2578
Editor: lukisi
Comment:
Revision 5 as of 2009-05-22 15:49:56
Size: 3217
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
Se sono diversi, quindi i due nodi appartengono a due reti prima separate, l'algoritmo è diverso nei due casi: Se sono diversi, i due nodi appartengono a due reti prima separate. Ognuno dei due nodi deve stabilire con certezza se appartiene alla rete che deve porre riparo. '''''TODO''': Al momento il criterio è "la rete più piccola o, in caso di parità, quella con netid minore". Questo è un criterio efficiente, ma ho il dubbio che non sia sicuro. Se usassimo il criterio "netid minore" staremmo sicuri, ma con grande probabilità di causare un rehook molto diffuso.''
Line 17: Line 17:
'''1)''' il nodo che ha la mappa più piccola o il {{{netid}}} minore calcola il livello (sia {{{level}}}) in cui i nodi hanno un gnodo padre con lo stesso ID. Ad esempio, se il mio IP è 1.2.3.4 e quello del mio vicino è 1.2.5.6 questi nodi sembrano appartenere allo stesso gnodo di livello 2. In realtà non è così perché appartengono a due reti diverse. '''1)''' il nodo che appartiene alla rete che deve porre riparo, calcola il livello (sia {{{level}}}) in cui i due nodi hanno un gnodo padre con lo stesso ID. Ad esempio, se il mio IP è 1.2.3.4 e quello del mio vicino è 1.2.5.6 questi nodi sembrano appartenere allo stesso gnodo di livello 2. In realtà non è così perché appartengono a due reti diverse.
Line 19: Line 19:
Esamina le destinazioni contenute nelle routes di livello {{{level}}} della porzione di mappa R dell'ETP ricevuto, per vedere se la rete del nodo vicino contiene già un gnodo di livello {{{level}}} con lo stesso (g)ID del mio (g)nodo di livello {{{level}}}. Esamina le destinazioni contenute nelle routes di livello {{{level}}} ('''''TODO''': dovrebbe essere level - 1'') della porzione di mappa R dell'ETP ricevuto, per vedere se la rete del nodo vicino contiene già un gnodo di livello {{{level}}} ('''''TODO''': dovrebbe essere level - 1'') con lo stesso (g)ID del mio (g)nodo di livello {{{level}}} ('''''TODO''': dovrebbe essere level - 1'').
Line 21: Line 21:
In questo modo ho scoperto se il gnodo (di qualsiasi livello) a cui appartengo è invalido nella rete che ho incontrato. '''''TODO''': però se non siamo a livello 4 questo non basta, perché probabilmente si formerebbe un gnodo di livello {{{level +1}}} non compatto. Giusto?'' In questo modo ho scoperto se il gnodo di livello {{{level - 1}}} a cui appartengo è invalido nella rete che ho incontrato. ''Notare'' che se il gnodo di livello {{{level}}} non è invalido nella rete che ho incontrato, questo garantisce anche che non stiamo formando un gnodo di livello {{{level}}} non compatto, perché siamo collegati con il vicino da cui abbiamo ricevuto l'ETP, il quale è di quel gnodo di livello {{{level}}}.

Network Collision

Quando due reti Netsukuku nate separatamente si incontrano si può verificare che diversi (g)nodi abbiano lo stesso (g)ID.

Per rilevare questa situazione e quindi prendere le misure necessarie a risolvere il problema si adotta la tecnica di assegnare ad una rete Netsukuku un identificativo, alla sua nascita.
Il nodo che al suo avvio si ritrova solo, genera un netid random - vedi il modulo hook e anche la fase di startup di un nodo.
Il nodo che al suo avvio ha dei vicini riceve il netid di questi - tramite il radar. TODO: proseguire
In conclusione, ogni singolo nodo conosce il netid della sua rete.

Quando un nodo riceve ulteriori ETP (vedi il Modulo QSPN) richiama il metodo collision_check; in esso verifica che il netid del suo vicino sia lo stesso del suo.
Se sono diversi, i due nodi appartengono a due reti prima separate. Ognuno dei due nodi deve stabilire con certezza se appartiene alla rete che deve porre riparo. TODO: Al momento il criterio è "la rete più piccola o, in caso di parità, quella con netid minore". Questo è un criterio efficiente, ma ho il dubbio che non sia sicuro. Se usassimo il criterio "netid minore" staremmo sicuri, ma con grande probabilità di causare un rehook molto diffuso.

1) il nodo che appartiene alla rete che deve porre riparo, calcola il livello (sia level) in cui i due nodi hanno un gnodo padre con lo stesso ID. Ad esempio, se il mio IP è 1.2.3.4 e quello del mio vicino è 1.2.5.6 questi nodi sembrano appartenere allo stesso gnodo di livello 2. In realtà non è così perché appartengono a due reti diverse.
Esamina le destinazioni contenute nelle routes di livello level (TODO: dovrebbe essere level - 1) della porzione di mappa R dell'ETP ricevuto, per vedere se la rete del nodo vicino contiene già un gnodo di livello level (TODO: dovrebbe essere level - 1) con lo stesso (g)ID del mio (g)nodo di livello level (TODO: dovrebbe essere level - 1).
In questo modo ho scoperto se il gnodo di livello level - 1 a cui appartengo è invalido nella rete che ho incontrato. Notare che se il gnodo di livello level non è invalido nella rete che ho incontrato, questo garantisce anche che non stiamo formando un gnodo di livello level non compatto, perché siamo collegati con il vicino da cui abbiamo ricevuto l'ETP, il quale è di quel gnodo di livello level.
Se il gnodo (di qualsiasi livello) a cui appartengo è invalido devo fare il rehook, altrimenti non è necessario che io lo faccia, posso semplicemente entrare nell'altra rete con il mio attuale IP. TODO: Serve in questo caso coordinarsi con il coordinator node? Direi di sì. Come ci si accerta che qualcun altro non sta facendo hook alla rete con lo stesso gnodo?

2) di verificare la reale presenza di (g)ID che collidono, e di riavviare se necessario la procedura di hooking. Tramite questa si vedrà ri-assegnato il netid.

TODO: approfondire / dettagliare

Netsukuku/ita/NetworkCollision (last edited 2009-05-25 21:34:46 by lukisi)