La classe KrnlRoute

Viene istanziata nel costruttore della classe NtkNode.
Sta in ascolto degli eventi ROUTE_XXX generati dalla classe MapRoute e degli eventi NEIGH_XXX generati dalla classe Neighbour (vedi il modulo radar). In base a questi eventi richiama i metodi della classe Route (vedi il 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
ip route add 178.84.190.194/32 dev eth0 protocol ntk
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
ip route add 178.0.0.0/8 dev eth0 via 178.84.190.194 protocol ntk
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.
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 funzionamento del radar).
Generando gli eventi NEIGH_XXX avvia delle operazioni della classe Etp. Tra queste c'è l'aggiornamento delle route conosciute, con i metodi della classe MapRoute. Questi metodi generano gli eventi ROUTE_XXX.
Ci sono delle situazioni in cui questi eventi, nel tempo vicini tra loro, vanno gestiti in un preciso ordine cronologico.
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 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).
In questo modo, ad esempio, la gestione dell'evento ROUTE_NEW ... TODO: verificare