6587
Comment:
|
8970
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
= Modulo Neighborhood = | = Modulo Neighborhood - Analisi Funzionale = Rileva i nodi vicini raggiungibili attraverso una (o più) interfacce di rete e ne reperisce l'identificativo. |
Line 3: | Line 4: |
Rileva i nodi vicini raggiungibili attraverso una (o più) interfacce di rete e ne reperisce l'identificativo. Con ogni vicino, poi, si accorda per la creazione (o meno) di un arco. L'accordo potrebbe non essere raggiunto perché uno dei due vertici ha già un numero di archi elevato, tutti con costo inferiore a questo. Oppure, più frequentemente, se i due vertici appartengono a reti distinte. |
Con ogni vicino, poi, si accorda per la creazione (o meno) di un arco. L'accordo potrebbe non essere raggiunto perché uno dei due vertici ha già un numero di archi elevato, tutti con costo inferiore a questo. Oppure, più frequentemente, se i due vertici appartengono a reti distinte. |
Line 13: | Line 8: |
Nel tempo, gestisce la costituzione di nuovi archi, la rimozione di archi, i cambiamenti del costo degli archi. |
Nel tempo, gestisce la costituzione di nuovi archi, la rimozione di archi, i cambiamenti del costo degli archi. |
Line 17: | Line 11: |
Tra due nodi vicini ci possono essere 2 o più archi, ma solo se sono su diversi domini di collisione. | |
Line 18: | Line 13: |
Tra due nodi vicini ci possono essere 2 o più archi, ma solo se sono su diversi domini di collisione. Da questo deriva che i messaggi inviati in UDP Unicast vanno elaborati dal solo nodo destinatario e solo una volta, cioè quando sono ricevuti dall'arco che li invia. Per questo il nodo che li invia su un certo arco compone l'oggetto UnicastID con l'identificativo del nodo destinatario e il MAC del nodo destinatario associato a quell'arco. |
Da questo deriva che i messaggi inviati in UDP Unicast vanno elaborati dal solo nodo destinatario e solo una volta, cioè quando sono ricevuti dall'arco che li invia. Per questo il nodo che li invia su un certo arco compone l'oggetto UnicastID con l'identificativo del nodo destinatario e il MAC del nodo destinatario associato a quell'arco. |
Line 28: | Line 16: |
Quando si crea un arco esso esiste per entrambi i nodi. Quindi ogni nodo può inoltrare i suoi pacchetti all'altro e deve inoltrare i pacchetti che provengono dall'altro. |
Quando si crea un arco esso esiste per entrambi i nodi. Quindi ogni nodo può inoltrare i suoi pacchetti all'altro e deve inoltrare i pacchetti che provengono dall'altro. |
Line 33: | Line 19: |
Il costo di un arco in una direzione ( da A verso B ) può essere diverso dal costo nella direzione inversa. Questo non è utile quando il costo rappresenta il RTT, ma può esserlo se rappresenta la larghezza di banda in uscita. |
Il costo di un arco in una direzione ( da A verso B ) può essere diverso dal costo nella direzione inversa. Questo non è utile quando il costo rappresenta il round-trip time, ma può esserlo se rappresenta la larghezza di banda in uscita. |
Line 39: | Line 22: |
Quando un nodo rimuove un arco tenta di comunicarlo al vertice collegato perché faccia altrettanto. |
Quando un nodo rimuove un arco tenta di comunicarlo al vertice collegato perché faccia altrettanto. |
Line 44: | Line 25: |
Line 47: | Line 27: |
* il nome della interfaccia ( wlan0 ) * il MAC address della interfaccia ( CC:AF:78:2E:C8:B6 ) * Callback per misurare il RTT (ping) con un vicino. |
* il nome della interfaccia ( wlan0 ) * il MAC address della interfaccia ( CC:AF:78:2E:C8:B6 ) * Callback per misurare il RTT (ping) con un vicino. |
Line 52: | Line 32: |
* Manager di indirizzi e rotte. | |
Line 55: | Line 36: |
Quando si aggiunge una interfaccia al modulo, esso verifica che non sia un duplicato; se nome e MAC coincidono con una già inserita allora ignora la richiesta; se uno coincide e l'altro no, allora errore fatale. |
Quando si aggiunge una interfaccia al modulo, esso verifica che non sia un duplicato; se nome e MAC coincidono con una già inserita allora ignora la richiesta; se uno coincide e l'altro no, allora errore fatale. |
Line 61: | Line 39: |
Line 63: | Line 40: |
* rilevamento di una collisione con altra rete; questo evento scatenerà la procedura di fusione delle due reti su un altro modulo. * costituzione di un arco. * rimozione di un arco. * variazione del costo di un arco. |
* rilevamento di una collisione con altra rete; questo evento scatenerà la procedura di fusione delle due reti su un altro modulo. * costituzione di un arco. * rimozione di un arco. * variazione del costo di un arco. |
Line 68: | Line 45: |
* elenco degli archi ora presenti. * dato il nome di una interfaccia di rete (e.g. wlan0) [che di norma si ottiene dal parametro _rpc_caller di un metodo remoto che è in esecuzione, il che fa presumere che la suddetta interfaccia è gestita dal modulo] l'oggetto interfaccia che la rappresenta, se tale interfaccia è al momento gestita dal modulo. Altrimenti un RPCError? * dato un UnicastID (identificativo di un unicast) ricevuto da una data interfaccia di rete, stabilire se è un messaggio da processare. * dato un arco, un oggetto stub utilizzabile per inviare un messaggio tramite questo arco al vicino (chiamare un metodo remoto in unicast) * un oggetto stub utilizzabile per inviare un messaggio (chiamare un metodo remoto in broadcast) a tutti i vicini; oppure, dato un identificativo di un vicino, a tutti i vicini tranne quello; oppure, data una interfaccia di rete, a tutti i vicini raggiungibili tramite quella. <<BR>> Quando si invia un messaggio tramite questo oggetto l'invio del messaggio è asincrono: procederà in una nuova tasklet, mentre il metodo non fornirà alcuna risposta al chiamante. E' possibile fornire una callback che verrà richiamata dopo un certo tempo se per qualcuno degli archi noti al modulo non si avrà ricevuto un messaggio di ACK dal vicino collegato. Questo controllo viene fatto sugli archi che sono esistenti al momento dell'invio AND sono ancora presenti alla scadenza del timeout. La callback viene chiamata una volta per ogni arco che fallisce e avrà quell'arco come argomento, così che il chiamante possa prendere un provvedimento, ad esempio forzando la rimozione dell'arco. <<BR>> Quando si invia un broadcast a più vicini può essere necessario inviarlo in broadcast su una o più interfacce di rete. |
* elenco degli archi ora presenti. * dato il nome di una interfaccia di rete (e.g. wlan0) [che di norma si ottiene dal parametro _rpc_caller di un metodo remoto che è in esecuzione, il che fa presumere che la suddetta interfaccia è gestita dal modulo] l'oggetto interfaccia che la rappresenta, se tale interfaccia è al momento gestita dal modulo. Altrimenti un RPCError? * dato un UnicastID (identificativo di un unicast) ricevuto da una data interfaccia di rete, stabilire se è un messaggio da processare. * dato un arco, un oggetto stub utilizzabile per inviare un messaggio tramite questo arco al vicino (chiamare un metodo remoto) in UDP unicast oppure in TCP (reliable). * un oggetto stub utilizzabile per inviare un messaggio (chiamare un metodo remoto in broadcast) a tutti i vicini; oppure, dato un identificativo di un vicino, a tutti i vicini tranne quello; oppure, data una interfaccia di rete, a tutti i vicini raggiungibili tramite quella. <<BR>> Quando si invia un messaggio tramite questo oggetto l'invio del messaggio è asincrono: procederà in una nuova tasklet, mentre il metodo non fornirà alcuna risposta al chiamante. E' possibile fornire una callback che verrà richiamata dopo un certo tempo se per qualcuno degli archi noti al modulo non si avrà ricevuto un messaggio di ACK dal vicino collegato. Questo controllo viene fatto sugli archi che sono esistenti al momento dell'invio AND sono ancora presenti alla scadenza del timeout. La callback viene chiamata una volta per ogni arco che fallisce e avrà quell'arco come argomento, così che il chiamante possa prendere un provvedimento, ad esempio forzando la rimozione dell'arco. <<BR>> Quando si invia un broadcast a più vicini può essere necessario inviarlo in broadcast su una o più interfacce di rete. |
Line 76: | Line 53: |
La stub factory è un oggetto di cui il modulo conosce l'interfaccia INeighborhoodStubFactory. Tramite essa il modulo può: | |
Line 77: | Line 55: |
La stub factory è un oggetto di cui il modulo conosce l'interfaccia IStubFactory. Tramite essa il modulo può: * ottenere uno stub per chiamare un metodo in broadcast; il modulo può specificare l'oggetto BroadcastID per indicare quali vicini sono interessati; può inoltre indicare una callback da richiamare sugli archi per i quali non riceve il messaggio di ACK. * ottenere uno stub per chiamare un metodo su uno specifico vicino; il modulo specifica l'oggetto UnicastID e può specificare se si vuole ricevere una risposta o no. |
* ottenere uno stub per chiamare un metodo via UDP in broadcast (metodo 'i_neighborhood_get_broadcast'); il modulo può specificare una o più interfacce di rete sulle quali desidera che il messaggio venga inviato; il modulo può specificare l'oggetto BroadcastID per indicare a ogni vicino che riceve il messaggio se debba considerarsi tra i destinatari; può inoltre indicare una callback da richiamare sugli archi per i quali non riceve il messaggio di ACK. * ottenere uno stub per chiamare un metodo via UDP su uno specifico vicino (metodo 'i_neighborhood_get_unicast'); il modulo specifica l'interfaccia di rete e l'oggetto UnicastID e può specificare se si vuole ricevere una risposta o no. * ottenere uno stub per chiamare un metodo via TCP su uno specifico vicino (metodo 'i_neighborhood_get_tcp'); il modulo specifica l'indirizzo di scheda (vedi [[Netsukuku/ita/docs/ModuloNeighborhood/Appunti#IndirizzoDiScheda|appunti]]) e può specificare se si vuole attendere l'esecuzione del metodo da parte del vicino o no; in ogni caso se il metodo ritorna senza errori la ricezione da parte del vicino è garantita. |
Line 83: | Line 60: |
Il manager di rotte e indirizzi è un oggetto di cui il modulo conosce l'interfaccia INeighborhoodIPRouteManager. Tramite essa il modulo può: | |
Line 84: | Line 62: |
L'identificativo del proprio nodo, come anche l'identificativo di ogni vertice rilevato, è un oggetto il cui contenuto non è noto al modulo neighborhood. L'interfaccia di questo oggetto nota al modulo gli consente di: * verificare se due identificativi sono identici (metodo 'equals'). * verificare se due identificativi appartengono alla stessa rete (metodo 'is_on_same_network'). |
* aggiungere un indirizzo IP ad una interfaccia di rete (metodo 'i_neighborhood_add_address'); * aggiungere un vicino su una interfaccia (metodo 'i_neighborhood_add_neighbor'); * rimuovere un vicino da una interfaccia (metodo 'i_neighborhood_remove_neighbor'); * rimuovere un indirizzo IP da una interfaccia (metodo 'i_neighborhood_remove_address'). Il modulo lo usa per rendere possibile la comunicazione via TCP coi vicini tramite un indirizzo fisso (vedi [[Netsukuku/ita/docs/ModuloNeighborhood/Appunti#IndirizzoDiScheda|appunti]]). |
Line 91: | Line 70: |
L'identificativo del proprio nodo, come anche l'identificativo di ogni vertice rilevato, è un oggetto il cui contenuto non è noto al modulo neighborhood. L'interfaccia di questo oggetto nota al modulo (INeighborhoodNodeID) gli consente di: | |
Line 92: | Line 72: |
Un arco è un oggetto noto al modulo. Grazie alle informazioni memorizzate in esso (my_nic) il modulo è in grado di produrre l'oggetto che realizza la chiamata di un metodo remoto in unicast. |
* verificare se due identificativi sono identici (metodo 'i_neighborhood_equals'). * verificare se due identificativi appartengono alla stessa rete (metodo 'i_neighborhood_is_on_same_network'). |
Line 96: | Line 75: |
L'interfaccia dell'oggetto arco nota all'esterno del modulo, invece, permette solo un sottoinsieme di operazioni: |
---- Un arco è un oggetto (!NeighborhoodRealArc) noto al modulo. Grazie alle informazioni memorizzate in esso (my_nic + mac o nic_addr) il modulo è in grado di produrre lo stub che realizza la chiamata di un metodo remoto in UDP unicast o in TCP (reliable). L'interfaccia dell'oggetto arco nota all'esterno del modulo, invece, permette solo un sottoinsieme di operazioni: |
Line 100: | Line 82: |
* ottenere l'indirizzo IPv4 di scheda (vedi appunti, metodo 'string get_local_address') | |
Line 106: | Line 87: |
Il costo di un arco può essere rappresentato con diverse metriche (latenza, larghezza di banda, ...). Perciò il costo di un arco esposto dall'interfaccia INeighborhoodArc è una istanza della classe astratta REM, che può venire specializzata in vari modi. Attualmente l'implementazione del modulo misura la latenza e la esprime con la classe RTT. | |
Line 107: | Line 89: |
Il costo di un arco rilevato è la latenza, cioè il tempo che impiega un messaggio da noi a raggiungere il vertice collegato. In realtà quello che si può misurare, quindi quello che il modulo memorizza come costo, è il round-trip time (RTT). |
Il costo di un arco rilevato è la latenza, cioè il tempo che impiega un messaggio da noi a raggiungere il vertice collegato. In realtà quello che si può misurare, quindi quello che il modulo memorizza come costo, è il round-trip time (RTT). Il costo di un arco è un valore frutto di una reale misurazione. Mentre una path può avere un costo fittizio per indicare una certa situazione – come ''null'' per indicare che la destinazione sono proprio io, o ''dead'' per indicare che la path non è più funzionante (si vedano dettagli nella trattazione del modulo Qspn – il costo di un arco come segnalato dagli eventi del modulo Neighborhood è sempre una valore reale. Infatti non ha alcun significato un arco verso me stesso, e un arco rimosso viene segnalato con un evento preciso. |
Modulo Neighborhood - Analisi Funzionale
Rileva i nodi vicini raggiungibili attraverso una (o più) interfacce di rete e ne reperisce l'identificativo.
Con ogni vicino, poi, si accorda per la creazione (o meno) di un arco. L'accordo potrebbe non essere raggiunto perché uno dei due vertici ha già un numero di archi elevato, tutti con costo inferiore a questo. Oppure, più frequentemente, se i due vertici appartengono a reti distinte.
Per ogni arco mantiene l'identificativo del vertice collegato e il costo.
Nel tempo, gestisce la costituzione di nuovi archi, la rimozione di archi, i cambiamenti del costo degli archi.
Note
Tra due nodi vicini ci possono essere 2 o più archi, ma solo se sono su diversi domini di collisione.
Da questo deriva che i messaggi inviati in UDP Unicast vanno elaborati dal solo nodo destinatario e solo una volta, cioè quando sono ricevuti dall'arco che li invia. Per questo il nodo che li invia su un certo arco compone l'oggetto UnicastID con l'identificativo del nodo destinatario e il MAC del nodo destinatario associato a quell'arco.
Quando si crea un arco esso esiste per entrambi i nodi. Quindi ogni nodo può inoltrare i suoi pacchetti all'altro e deve inoltrare i pacchetti che provengono dall'altro.
Il costo di un arco in una direzione ( da A verso B ) può essere diverso dal costo nella direzione inversa. Questo non è utile quando il costo rappresenta il round-trip time, ma può esserlo se rappresenta la larghezza di banda in uscita.
Quando un nodo rimuove un arco tenta di comunicarlo al vertice collegato perché faccia altrettanto.
Requisiti
- Identificativo del proprio nodo.
La (o le) interfaccia di rete da monitorare.
Una interfaccia nic_xy è un oggetto che comprende:- il nome della interfaccia ( wlan0 )
il MAC address della interfaccia ( CC:AF:78:2E:C8:B6 )
- Callback per misurare il RTT (ping) con un vicino.
- Numero massimo di archi da realizzare.
- Factory per ottenere uno "stub" per invocare metodi remoti nei nodi vicini.
- Manager di indirizzi e rotte.
Durante le operazioni del modulo è possibile aggiungere o rimuovere una interfaccia di rete da monitorare.
Quando si aggiunge una interfaccia al modulo, esso verifica che non sia un duplicato; se nome e MAC coincidono con una già inserita allora ignora la richiesta; se uno coincide e l'altro no, allora errore fatale.
Deliverables
- Emette un segnale per:
- rilevamento di una collisione con altra rete; questo evento scatenerà la procedura di fusione delle due reti su un altro modulo.
- costituzione di un arco.
- rimozione di un arco.
- variazione del costo di un arco.
- Fornisce on demand:
- elenco degli archi ora presenti.
- dato il nome di una interfaccia di rete (e.g. wlan0) [che di norma si ottiene dal parametro _rpc_caller di un metodo remoto che è in esecuzione, il che fa presumere che la suddetta interfaccia è gestita dal modulo] l'oggetto interfaccia che la rappresenta, se tale interfaccia è al momento gestita dal modulo. Altrimenti un RPCError?
- dato un UnicastID (identificativo di un unicast) ricevuto da una data interfaccia di rete, stabilire se è un messaggio da processare.
- dato un arco, un oggetto stub utilizzabile per inviare un messaggio tramite questo arco al vicino (chiamare un metodo remoto) in UDP unicast oppure in TCP (reliable).
un oggetto stub utilizzabile per inviare un messaggio (chiamare un metodo remoto in broadcast) a tutti i vicini; oppure, dato un identificativo di un vicino, a tutti i vicini tranne quello; oppure, data una interfaccia di rete, a tutti i vicini raggiungibili tramite quella.
Quando si invia un messaggio tramite questo oggetto l'invio del messaggio è asincrono: procederà in una nuova tasklet, mentre il metodo non fornirà alcuna risposta al chiamante. E' possibile fornire una callback che verrà richiamata dopo un certo tempo se per qualcuno degli archi noti al modulo non si avrà ricevuto un messaggio di ACK dal vicino collegato. Questo controllo viene fatto sugli archi che sono esistenti al momento dell'invio AND sono ancora presenti alla scadenza del timeout. La callback viene chiamata una volta per ogni arco che fallisce e avrà quell'arco come argomento, così che il chiamante possa prendere un provvedimento, ad esempio forzando la rimozione dell'arco.
Quando si invia un broadcast a più vicini può essere necessario inviarlo in broadcast su una o più interfacce di rete.
- Ha un metodo per forzare la rimozione di un arco.
Classi e interfacce
La stub factory è un oggetto di cui il modulo conosce l'interfaccia INeighborhoodStubFactory. Tramite essa il modulo può:
- ottenere uno stub per chiamare un metodo via UDP in broadcast (metodo 'i_neighborhood_get_broadcast'); il modulo può specificare una o più interfacce di rete sulle quali desidera che il messaggio venga inviato; il modulo può specificare l'oggetto BroadcastID per indicare a ogni vicino che riceve il messaggio se debba considerarsi tra i destinatari; può inoltre indicare una callback da richiamare sugli archi per i quali non riceve il messaggio di ACK.
- ottenere uno stub per chiamare un metodo via UDP su uno specifico vicino (metodo 'i_neighborhood_get_unicast'); il modulo specifica l'interfaccia di rete e l'oggetto UnicastID e può specificare se si vuole ricevere una risposta o no.
ottenere uno stub per chiamare un metodo via TCP su uno specifico vicino (metodo 'i_neighborhood_get_tcp'); il modulo specifica l'indirizzo di scheda (vedi appunti) e può specificare se si vuole attendere l'esecuzione del metodo da parte del vicino o no; in ogni caso se il metodo ritorna senza errori la ricezione da parte del vicino è garantita.
Il manager di rotte e indirizzi è un oggetto di cui il modulo conosce l'interfaccia INeighborhoodIPRouteManager. Tramite essa il modulo può:
- aggiungere un indirizzo IP ad una interfaccia di rete (metodo 'i_neighborhood_add_address');
- aggiungere un vicino su una interfaccia (metodo 'i_neighborhood_add_neighbor');
- rimuovere un vicino da una interfaccia (metodo 'i_neighborhood_remove_neighbor');
- rimuovere un indirizzo IP da una interfaccia (metodo 'i_neighborhood_remove_address').
Il modulo lo usa per rendere possibile la comunicazione via TCP coi vicini tramite un indirizzo fisso (vedi appunti).
L'identificativo del proprio nodo, come anche l'identificativo di ogni vertice rilevato, è un oggetto il cui contenuto non è noto al modulo neighborhood. L'interfaccia di questo oggetto nota al modulo (INeighborhoodNodeID) gli consente di:
- verificare se due identificativi sono identici (metodo 'i_neighborhood_equals').
- verificare se due identificativi appartengono alla stessa rete (metodo 'i_neighborhood_is_on_same_network').
Un arco è un oggetto (NeighborhoodRealArc) noto al modulo. Grazie alle informazioni memorizzate in esso (my_nic + mac o nic_addr) il modulo è in grado di produrre lo stub che realizza la chiamata di un metodo remoto in UDP unicast o in TCP (reliable).
L'interfaccia dell'oggetto arco nota all'esterno del modulo, invece, permette solo un sottoinsieme di operazioni:
- leggere l'identificativo del vicino.
- leggere il MAC del vicino.
- leggere il costo dell'arco.
- verificare se due archi sono identici (metodo 'equals').
- verificare se l'arco poggia su una data interfaccia di rete; abbiamo questo metodo, invece di avere direttamente l'interfaccia, per scoraggiare la creazione di un oggetto remoto unicast senza passare dal modulo.
Il costo di un arco può essere rappresentato con diverse metriche (latenza, larghezza di banda, ...). Perciò il costo di un arco esposto dall'interfaccia INeighborhoodArc è una istanza della classe astratta REM, che può venire specializzata in vari modi. Attualmente l'implementazione del modulo misura la latenza e la esprime con la classe RTT.
Il costo di un arco rilevato è la latenza, cioè il tempo che impiega un messaggio da noi a raggiungere il vertice collegato. In realtà quello che si può misurare, quindi quello che il modulo memorizza come costo, è il round-trip time (RTT).
Il costo di un arco è un valore frutto di una reale misurazione. Mentre una path può avere un costo fittizio per indicare una certa situazione – come null per indicare che la destinazione sono proprio io, o dead per indicare che la path non è più funzionante (si vedano dettagli nella trattazione del modulo Qspn – il costo di un arco come segnalato dagli eventi del modulo Neighborhood è sempre una valore reale. Infatti non ha alcun significato un arco verso me stesso, e un arco rimosso viene segnalato con un evento preciso.