|
Size: 775
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 3: | Line 3: |
| Questa classe ascolta --(i segnali {{{NODE_NEW}}} e {{{NODE_DELETED}}} di {{{MapRoute}}} e)-- i segnali {{{ETP_EXCEDED}}} e {{{NET_COLLISION}}} di {{{Etp}}}. Quando un segnale di {{{ETP_EXCEDED}}} viene emesso (gestito dalla microfunc [[../CommunicatingVessels|communicating_vessels]]), vengono inviati {{{old_node_nb}}} e {{{cur_node_nb}}}. Questi sono usati per tentare uno split del gnodo ([[../GnodesSplit|gnodes_split]]) e solo all'abbisogna viene eseguito il resto della funzione, che a sua volta all'abbisogna richiama la microfunc [[../MicrofuncHook|hook]]. | Questa classe ascolta i segnali {{{ETP_EXECUTED}}} e {{{NET_COLLISION}}} di {{{Etp}}}. Come detto nel [[../ModuloQSPN|modulo QSPN]], la classe {{{Etp}}} processa, nel suo metodo {{{etp_exec}}}, gli ETP ricevuti dai suoi vicini. |
| Line 5: | Line 7: |
| Quando un segnale {{{NET_COLLISION}}} viene emesso viene richiamata la microfunc [[../MicrofuncHook|hook]]. | Durante questa processazione potrebbe rilevare la collisione di due distinte reti Netsukuku. In questo caso genera l'evento {{{NET_COLLISION}}} e si interrompe. |
| Line 7: | Line 9: |
| La microfunc hook alla fine emette il segnale {{{HOOKED}}}. | 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}}}. 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 [[../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. 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.