Network Collision

Quando due reti 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 un identificativo.

Le problematiche da tenere in considerazione sono:

  1. Assegnazione di un netid ad una rete alla sua nascita
  2. Gestione della collisione di due reti nate separatamente
  3. Gestione della separazione (split) di una rete in due reti disgiunte

Assegnazione di un netid alla nascita di una rete

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 attivi (che hanno già superato la fase di startup) vede il netid di questi.
Non può subito appropiarsene, deve prima aver completato con successo il primo hook.
Per diventare membro a tutti gli effetti della rete deve aver ricevuto almeno il primo ETP da un vicino, tramite il quale viene a conoscenza immediatamente di tutti i nodi e g-nodi che ne fanno parte. TODO: proseguire

A regime, ogni singolo nodo che ha superato la fase di startup deve conoscere il netid della sua rete.

Collisione di due reti nate separatamente

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 livello level - 1 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ì, per accertarsi che qualcun altro non sta facendo hook alla rete con lo stesso gnodo.
Se entro senza fare il rehook, faccio anche...
Se invece è necessario fare il rehook, il metodo collision_check restituisce True. Di seguito il metodo etp_exec emette il segnale NET_COLLISION con argomento la lista dei suoi vicini (oggetti Neigh) che appartenevano alla rete che deve porre riparo. Questo avvia per il nodo corrente la microfunc hook escludendo tali nodi vicini.

2) il nodo che appartiene all'altra rete (che ha diritto a restare valida) TODO: proseguire

Split di una rete in due reti disgiunte

TODO