|
Size: 1368
Comment:
|
← Revision 5 as of 2009-05-08 14:26:39 ⇥
Size: 1431
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Come detto nel [[../ModuloQSPN|modulo QSPN]], la classe {{{Etp}}} genera un evento {{{ETP_EXECUTED}}} dopo aver processato un ETP ricevuto da un vicino. Questo potrebbe aver comportato delle modifiche alla propria mappa di route (vedi la [[../ClasseMapRoute|classe MapRoute]]). | Come detto nel [[../ModuloQSPN|modulo QSPN]], la classe {{{Etp}}} processa, nel suo metodo {{{etp_exec}}}, gli ETP ricevuti dai suoi vicini. |
| Line 7: | Line 7: |
| La classe {{{MapRoute}}} ha il membro {{{node_nb}}} che è una lista con il numero di nodi presenti nei vari livelli della mappa. Quando il modulo QSPN processa un ETP si memorizza una copia di questo elenco prima e dopo aver modificato la mappa. Questi due elenchi vengono passati come argomenti {{{old_node_nb}}} e {{{cur_node_nb}}} dell'evento {{{ETP_EXECUTED}}}. | Durante questa processazione potrebbe rilevare la collisione di due distinte reti Netsukuku. In questo caso genera l'evento {{{NET_COLLISION}}} e si interrompe. |
| Line 9: | Line 9: |
| Nel modulo hook, la classe Hook registra il suo metodo microfunc [[../CommunicatingVessels|communicating_vessels]] come gestore dell'evento. | Altrimenti prosegue e, se non ignora l'ETP perché lo aveva già incontrato, processa le informazioni. Questo può comportare delle modifiche alla propria mappa di route (vedi la [[../ClasseMapRoute|classe MapRoute]]). Alla fine genera un evento {{{ETP_EXECUTED}}}. |
| Line 11: | Line 11: |
| '''''TODO''': proseguire l'analisi'' - Cosa ci fa? li usa per tentare uno split del gnodo... | Entrambe queste situazioni portano a operazioni svolte dalla classe Hook. |
| Line 13: | Line 13: |
| In seguito ad un evento {{{ETP_EXECUTED}}}: * Si avvia l'esecuzione della microfunc communicating_vessels. Essendo una microfunc, essa viene avviata in un nuovo microthread. La prima cosa che esegue è la [[../GnodesSplit|funzione gnodes_split]], che quindi viene eseguita nel microthread appena creato. Se questa rileva uno split e avvia di conseguenza la [[../MicrofuncHook|microfunc hook]] (in un nuovo microthread), la communicating_vessels si ferma. * Altrimenti la [[../CommunicatingVessels|communicating_vessels]] prosegue. |
|
| Line 14: | Line 17: |
([[../GnodesSplit|gnodes_split]]) e solo all'abbisogna viene eseguito il resto della funzione, che a sua volta all'abbisogna richiama la microfunc [[../MicrofuncHook|hook]]. Quando un segnale {{{NET_COLLISION}}} viene emesso viene richiamata la microfunc [[../MicrofuncHook|hook]]. La microfunc hook alla fine emette il segnale {{{HOOKED}}}. |
In seguito ad un evento {{{NET_COLLISION}}}: * Si avvia l'esecuzione della [[../MicrofuncHook|microfunc hook]]. |
La classe Hook
Questa classe ascolta i segnali ETP_EXECUTED e NET_COLLISION di Etp.
Come detto nel modulo QSPN, la classe Etp processa, nel suo metodo etp_exec, gli ETP ricevuti dai suoi vicini.
Durante questa processazione potrebbe rilevare la collisione di due distinte reti Netsukuku. In questo caso genera l'evento NET_COLLISION e si interrompe.
Altrimenti prosegue e, se non ignora l'ETP perché lo aveva già incontrato, processa le informazioni. Questo può comportare delle modifiche alla propria mappa di route (vedi la classe MapRoute). Alla fine genera un evento ETP_EXECUTED.
Entrambe queste situazioni portano a operazioni svolte dalla classe Hook.
In seguito ad un evento ETP_EXECUTED:
Si avvia l'esecuzione della microfunc communicating_vessels. Essendo una microfunc, essa viene avviata in un nuovo microthread. La prima cosa che esegue è la funzione gnodes_split, che quindi viene eseguita nel microthread appena creato. Se questa rileva uno split e avvia di conseguenza la microfunc hook (in un nuovo microthread), la communicating_vessels si ferma.
Altrimenti la communicating_vessels prosegue.
In seguito ad un evento NET_COLLISION:
Si avvia l'esecuzione della microfunc hook.