= La classe KrnlRoute =

Viene istanziata nel costruttore della [[../ClasseNtkNode|classe NtkNode]].
<<BR>>
Sta in ascolto degli eventi {{{ROUTE_XXX}}} generati dalla [[../ClasseMapRoute|classe MapRoute]] e degli eventi {{{NEIGH_XXX}}} generati dalla classe {{{Neighbour}}} (vedi il [[../ModuloRadar|modulo radar]]). In base a questi eventi richiama i metodi della classe {{{Route}}} (vedi il [[../PackageNetwork|package network]]) per aggiornare le tabelle di routing del kernel.

Gli eventi {{{NEIGH_XXX}}} sono generati quando ci sono variazioni nei link tra questo nodo e i suoi vicini di LAN. Queste variazioni, in particolare quando un link nasce o muore, vanno gestite con dei comandi tipo
<<BR>>
{{{     ip route add 178.84.190.194/32 dev eth0 protocol ntk}}}
<<BR>>
che istruiscono il kernel sulla presenza di un link diretto verso quel nodo.

Gli eventi {{{ROUTE_XXX}}} sono generati quando ci sono variazioni nelle route conosciute da questo nodo verso gli altri nodi di tutta la rete. Queste variazioni, in particolare quando si conosce una nuova route o si cancella una vecchia, vanno gestite con dei comandi tipo
<<BR>>
{{{     ip route add 178.0.0.0/8 dev eth0 via 178.84.190.194 protocol ntk}}}
<<BR>>
che istruiscono il kernel sulla presenza di una route verso quel (g)nodo passando per il dato gateway.

 Notare che un mio vicino di LAN può essere un border node, cioè non essere parte del mio stesso gnodo di livello 1. Addirittura può non essere parte del mio gnodo di livello 2 o 3.<<BR>>
 Questo significa che io posso avere IP = 192.168.12.123, nella mia LAN vedere i nodi 178.84.190.194 e 192.168.6.7 - in questo caso Netsukuku dovrà istruire la tabella di routing del mio kernel con questi comandi:
 {{{
  ip route add 178.84.190.194/32 dev eth0 protocol ntk
  ip route add 178.0.0.0/8 dev eth0 via 178.84.190.194 protocol ntk
  ip route add 192.168.6.7/32 dev eth0 protocol ntk
  ip route add 192.168.0.0/16 dev eth0 via 192.168.6.7 protocol ntk
 }}}

In particolare c'è una relazione tra la generazione di eventi {{{NEIGH_XXX}}} e {{{ROUTE_XXX}}}. La generazione di eventi {{{NEIGH_XXX}}} è fatta dalla classe {{{Neighbour}}} che si accorge del cambiamento nei link perché esegue periodicamente dei radar (vedi [[../FunzionamentoDelRadar|funzionamento del radar]]).
<<BR>>
Generando gli eventi {{{NEIGH_XXX}}} avvia delle operazioni della [[../ModuloQSPN|classe Etp]]. Tra queste c'è l'aggiornamento delle route conosciute, con i metodi della classe {{{MapRoute}}}. Questi metodi generano gli eventi {{{ROUTE_XXX}}}.
<<BR>>
Ci sono delle situazioni in cui questi eventi, nel tempo vicini tra loro, vanno gestiti in un preciso ordine cronologico.
<<BR>>
Ad esempio non è bene aggiungere una route con un gateway ancora sconosciuto, o rimuovere un gateway prima di aver rimosso tutte le route che passano per lui.

Per realizzare questo sincronismo di gestione degli eventi si è implementato il meccanismo del decoratore {{{wakeup_on_event}}}, spiegato nella pagina del [[../ModuloEvent|modulo event]], e si sono previsti degli eventi generati dalla stessa classe {{{KrnlRoute}}} dopo aver effettivamente richiamato i metodi della classe {{{Route}}} per aggiornare le tabelle di routing del kernel (gli eventi {{{KRNL_XXX}}}).
<<BR>>
In questo modo, ad esempio, la gestione dell'evento {{{ROUTE_NEW}}} ... '''''TODO''': verificare''