|
Size: 4107
Comment:
|
Size: 1355
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| {{{ - Rnode RSA (creata per ogni hook). |
== NTK_RFC 0001 == |
| Line 4: | Line 3: |
| - Gnode contigui - Appena bnode si nota un gnode confinante non contiguo manda all'interno del suo gnode la richiesta di GNODE_CHALLENGE, in cui e' appeso il - Un nodo che la riceve manda un challenge al gnode confinante, se il challenge e' perso cambiera' l'ip, - Quando il nodo riceve la risposta al challenge manda in broadcast all'interno del suo gnode un pkt contenente la risposta. Il pacchetto viene firmato con la chiave privata dal nodo che la manda. Il nodo che la riceve verifica e rimuove la firma precedente ed appone la sua. - Quando un nodo ha ricevuto la risposta e le risposte di tutti i suoi nodi del suo gnode controlla l'esito del challenge: se l'esito e' positivo (ha vinto): non cambiera' gnode. al contrario: appena vede che l'rnode che e' utilizzato nella rotta migliore per raggiungere il gnode confinante muore e trova un nuovo rnode che fa parte del nuovo gnode, rifara' l'hook. - Rehook /*TODO*/ - /* TODO */ gid_torto == gid_ragione. - Ecco come funziona il challenge: Il gnode che ha il numero minore di nodi per verificare che effettivamente il gnode con cui confina abbia un numero minore di nodi gli manda un problema da risolvere. Questo problema ha una complessita' proporzionale al numero di nodi presenti nel gnode piu' piccolo (o presunto tale). In questo modo se il gnode che riceve il challenge riesce a risolvere il problema, distribuendo il calcolo tra suoi nodi, vuol dire che ha una quantita' di nodi maggiore o uguale a quella del gnode che ha mandato il challenge. Quando il gnode che ha meno nodi dell'altro riceve le risposte entro un tot di tempo determinato, cambiera' ip se le risposte ricevute sono corrette, altrimenti se non riceve le risposte o se sono errate, bannera' il gnode confinante, poiche' ha comunicato una quantita' di nodi superiore a quella effettiva, tentando cosi' di far cambiare l'IP all'altro gnode. Per convenienza chiamamo Checker il gnode che mandera' il problema al gnode Examinated. - Distribuzione del problema: Ogni nodo di Checker manda il seguente problema ai bnode di Checker che poi pensaranno a ridistribuirlo all'interno del gnode: f(x) mod k dove k e' un numero random compreso tra 2^16 < k < 2^32 e f(x) e' una funzione non facilmente calcolabile con il modulo di k. Anche il nodo Y che ha mandato il problema cerchera' la sua soluzione. La complessita' del problema dipende dalla grandezza di x, e viene scelta in modo proporzionale alla potenza di calcolo media di un computer. Y aspettera' per un tempo molto breve la risposta e una volta ricevuta la confrontera' con la sua soluzione. - Soglia del challenge: Il challenge viene mandato solo se i due gnode in questione hanno al loro interno una quantita' di nodi >= 2^16, quindi questo vale solo per i gnode di livello >= 2. I gnode piu' piccoli cambieranno IP senza verificare nulla. - Il qspn per i livelli alti deve avere un u_int per ogni entry che dice quando nodi ci sono in quel gnode. }}} |
Subject: Gnode contiguity --- This text describes a change to the Npv7 about the collision of IPs. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first. --- A collision of IPs happens when two gnodes with the same ID are born separately, so when they meet each trough a direct link or trough other nodes many problems arise since there are some ambiguities: - In the first case there can be nodes which have the same IP. - In the second: A <-> B <-> D <-> A After a qspn_round the node B will have two routes to reach the gnode A. But in this case the gnode A isn't a contiguous gnode, so when B wants to reach a node which belongs to A, it will send the packet using only one route which may lead to the A gnode which hasn't the wanted node. So these are the real problems. In order to solve them it is necessary that every time two gnodes meets each other for the first time, one of them will redo the hook, in fact, this was the cause of all. When a gnode meets for the first time another gnode is like when a new node joins the network: it hooks with the other nodes. The same must be done for the gnode. |
NTK_RFC 0001
Subject: Gnode contiguity --- This text describes a change to the Npv7 about the collision of IPs. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first. ---
A collision of IPs happens when two gnodes with the same ID are born separately, so when they meet each trough a direct link or trough other nodes many problems arise since there are some ambiguities:
- - In the first case there can be nodes which have the same IP. - In the second:
A <-> B <-> D <-> A
- After a qspn_round the node B will have two routes to reach the gnode A. But in this case the gnode A isn't a contiguous gnode, so when B wants to reach a node which belongs to A, it will send the packet using only one route which may lead to the A gnode which hasn't the wanted node.
So these are the real problems. In order to solve them it is necessary that every time two gnodes meets each other for the first time, one of them will redo the hook, in fact, this was the cause of all. When a gnode meets for the first time another gnode is like when a new node joins the network: it hooks with the other nodes. The same must be done for the gnode.