Differences between revisions 4 and 10 (spanning 6 versions)
Revision 4 as of 2015-06-25 09:14:04
Size: 5006
Editor: lukisi
Comment:
Revision 10 as of 2016-02-25 17:19:27
Size: 3598
Editor: lukisi
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Modulo Neighborhood - Requisiti / Dipendenze = = Modulo Neighborhood - Requisiti =
Line 9: Line 9:
||i_neighborhood_add_address ||{{{ ip address add 169.254.1.1 dev wlan0 }}} ||
||i_neighborhood_add_neighbor ||{{{ ip route add 169.254.22.33 dev wlan0 src 169.254.1.1 }}} ||
||i_neighborhood_remove_neighbor ||{{{ ip route del 169.254.22.33 dev wlan0 src 169.254.1.1 }}} ||
||i_neighborhood_remove_address ||{{{ ip address del 169.254.1.1/32 dev wlan0 }}} ||
||add_address ||{{{ ip address add 169.254.1.1 dev wlan0 }}} ||
||add_neighbor ||{{{ ip route add 169.254.22.33 dev wlan0 src 169.254.1.1 }}} ||
||remove_neighbor ||{{{ ip route del 169.254.22.33 dev wlan0 src 169.254.1.1 }}} ||
||remove_address ||{{{ ip address del 169.254.1.1/32 dev wlan0 }}} ||
Line 19: Line 19:
Tramite l'oggetto che implementa questa interfaccia dovrà essere possibile misurare il RTT tra l'interfaccia di rete ''dev_a'' del nodo ''a'' e l'interfaccia di rete ''dev_b'' del nodo ''b''. Se il nodo ''a'' è quello che inizia la procedura:
 * Nel nodo ''a'' il modulo Neighborhood sceglie una sequenza ''string s_a'' di pochi bytes random.
 * Nel nodo ''a'' il modulo Neighborhood crea un canale ''ch_a'' di comunicazione tra due tasklet.
 * Nel nodo ''a'' il modulo Neighborhood si mette in ascolto sull'interfaccia ''dev_a'' su una porta ''uint16 p_a'' random (verifica che non sia già occupata?)
 . Questo lo fa usando il metodo ''expect_pong'' dell'interfaccia INeighborhoodNetworkInterface. Tale metodo riceve la stringa ''s_a'' e il canale ''ch_a'' e restituisce la porta ''p_a''. Prima di restituire la porta, avvia una tasklet che controllerà la porta in attesa del messaggio ''s_a''. Appena lo riceve comunica ''true'' nel canale ''ch_a''. Se dopo una attesa massima non lo riceve, allora cessa di ascoltare, libera la porta e comunica ''false'' nel canale ''ch_a''.
 * Nel nodo ''a'' il modulo Neighborhood comunica (con protocollo TCP che è reliable) ''p_a'' ed ''s_a'' al modulo nel nodo ''b''.
 * Se la comunicazione avviene correttamente:
  * Nel nodo ''b'' il modulo Neighborhood riceve la comunicazione attraverso una interfaccia di rete e la riconduce alla relativa istanza dell'interfaccia INeighborhoodNetworkInterface.
  * Nel nodo ''b'' il modulo Neighborhood si mette in ascolto sull'interfaccia ''dev_b'' su una porta ''uint16 p_b'' random (verifica che non sia già occupata?)
  . Questo lo fa usando il metodo ''expect_ping'' dell'interfaccia INeighborhoodNetworkInterface. Tale metodo riceve la stringa ''s_a'' e la porta ''p_a'' e restituisce la porta ''p_b''. Prima di restituire la porta, avvia una tasklet che controllerà la porta ''p_b'' in attesa del messaggio ''s_a''. Appena lo riceve trasmette il messaggio ''s_a'' in broadcast verso la porta ''p_a''. Se dopo una attesa massima non lo riceve, allora cessa di ascoltare e libera la porta.
  * Nel nodo ''b'' il modulo Neighborhood risponde alla comunicazione restituendo ''p_b'' al modulo nel nodo ''a''.
  * Immediatamente nel nodo ''a'' il modulo Neighborhood trasmette il messaggio ''s_a'' in broadcast verso la porta ''p_b''.
  . Questo lo fa usando il metodo ''send_ping'' dell'interfaccia INeighborhoodNetworkInterface. Tale metodo riceve la stringa ''s_a'', la porta ''p_b'' e il canale ''ch_a''. Avvia un timer. Trasmette in broadcast ''s_a'' verso la porta ''p_b'' e attende la risposta sul canale ''ch_a''. Se riceve ''true'' stoppa il timer e restituisce il RTT. Se riceve ''false'' (o se dopo una attesa massima non riceve nulla) lancia una eccezione !NeighborhoodGetRttError per indicare che la misurazione non ha avuto buon esito.
 * Altrimenti, se la comunicazione con protocollo reliable lancia un errore:
  * Nel nodo ''a'' il modulo Neighborhood rimuove l'arco.
Il modulo Neighborhood deve poter misurare il RTT tra l'interfaccia di rete ''dev_a'' del nodo ''a'' e l'interfaccia di rete ''dev_b'' del nodo ''b''. Il modulo non fa tale misurazione in autonomia. Se lo facesse risulterebbe molto inaccurato, in quanto il modulo fa uso di tasklet, cioè thread cooperativi, che non possono essere accurati nei tempi di risposta. Quindi il modulo delega questa misurazione all'oggetto che implementa questa interfaccia.
Line 35: Line 21:
'''Nota''': se la misurazione del RTT va in timeout (cioè il metodo ''send_ping'' lancia una eccezione !NeighborhoodGetRttError) il modulo Neighborhood non elabora questa misurazione fallita, senza per questo rimuovere l'arco, in quanto l'UDP è di natura un protocollo non reliable. L'utilizzatore del modulo Neighborhood misura il RTT di un certo arco nell'implementazione del metodo ''measure_rtt'' dell'interfaccia INeighborhoodNetworkInterface.
Line 37: Line 23:
<<Anchor(GetBroadcast)>> Il modulo Neighborhood lo richiama per stabilire il costo (in latenza) di un arco, e passa come parametro l'indirizzo di scheda del vicino. Il modulo Neighborhood in seguito verifica anche che presso il vicino il modulo stesso sia ancora in vita eseguendo, con protocollo reliable, un metodo remoto che non fa alcuna operazione: ''nop''. Se riceve un errore rimuove l'arco.
Line 39: Line 25:
== INeighborhoodStubFactory - metodo i_neighborhood_get_broadcast ==
Il modulo Neigborhood riceve dal suo utilizzatore una istanza dell'interfaccia INeighborhoodStubFactory, che ha il metodo i_neighborhood_get_broadcast per ottenere uno stub.
Quando il nodo ''a'' ha un vicino ''b'' questi possono avere più di un arco che li unisce. Ma ogni arco ha una interfaccia esclusiva su entrambi i nodi. Per esempio il nodo ''a'' può avere solo un arco che parte dalla sua interfaccia ''eth0'' e arriva al nodo ''b''. Un altro arco potrebbe ad esempio partire dall'interfaccia ''eth1'' di ''a'' e arrivare a ''b''. Allo stesso modo il nodo ''b'' deve avere più interfacce di rete per avere due archi verso ''a''.
Line 42: Line 27:
Il modulo lo usa sempre immediatamente prima di chiamare un metodo remoto in broadcast, e può qui indicare una istanza dell'interfaccia !ModRpc.IAckCommunicator per ricevere dopo il timeout la lista dei MAC address che hanno segnalato con un ACK la ricezione del messaggio. Ogni interfaccia di rete di ogni nodo, inoltre, ha un indirizzo di scheda univoco. Di conseguenza, quando il nodo ''a'' indica un indirizzo di scheda del suo vicino ''b'', il nodo ''a'' indica precisamente un arco che lo congiunge a ''b'' attraverso due specifiche interfacce di rete ''dev_a'' e ''dev_b''.

Sapendo questo, ad esempio in Linux, il comando {{{ ping -q -n -c 1 169.254.21.36 }}} potrà essere usato per misurare la latenza esattamente dell'arco che ci interessa, anche nel caso in cui per lo stesso vicino esistano due o più archi.

Il modulo non esclude altri meccanismi di misurazione del costo. Per dare il massimo supporto al suo utilizzatore, nel metodo ''measure_rtt'' sono passate queste informazioni relative all'arco:
 * ''string peer_addr'' - l'indirizzo di scheda della interfaccia del vicino,
 * ''string peer_mac'' - il MAC della interfaccia del vicino,
 * ''string my_dev'' - il nome della interfaccia del nodo.
 * ''string my_addr'' - l'indirizzo di scheda della interfaccia del nodo.

Modulo Neighborhood - Requisiti

INeighborhoodIPRouteManager

Tramite l'oggetto che implementa questa interfaccia dovrà essere possibile apportare delle modifiche al sistema. Per un sistema Linux ad esempio, dotato del software iproute, questo si traduce nell'esecuzione di questi comandi:

Metodi

Comandi

add_address

 ip address add 169.254.1.1 dev wlan0  

add_neighbor

 ip route add 169.254.22.33 dev wlan0 src 169.254.1.1  

remove_neighbor

 ip route del 169.254.22.33 dev wlan0 src 169.254.1.1  

remove_address

 ip address del 169.254.1.1/32 dev wlan0  

INeighborhoodNetworkInterface

Una istanza di tale interfaccia viene passata al modulo quando l'utilizzatore gli chiede di monitorare una interfaccia di rete (metodo start_monitor). L'istanza di questo oggetto passato al modulo è legata alla specifica interfaccia di rete.

Il modulo Neighborhood deve poter misurare il RTT tra l'interfaccia di rete dev_a del nodo a e l'interfaccia di rete dev_b del nodo b. Il modulo non fa tale misurazione in autonomia. Se lo facesse risulterebbe molto inaccurato, in quanto il modulo fa uso di tasklet, cioè thread cooperativi, che non possono essere accurati nei tempi di risposta. Quindi il modulo delega questa misurazione all'oggetto che implementa questa interfaccia.

L'utilizzatore del modulo Neighborhood misura il RTT di un certo arco nell'implementazione del metodo measure_rtt dell'interfaccia INeighborhoodNetworkInterface.

Il modulo Neighborhood lo richiama per stabilire il costo (in latenza) di un arco, e passa come parametro l'indirizzo di scheda del vicino. Il modulo Neighborhood in seguito verifica anche che presso il vicino il modulo stesso sia ancora in vita eseguendo, con protocollo reliable, un metodo remoto che non fa alcuna operazione: nop. Se riceve un errore rimuove l'arco.

Quando il nodo a ha un vicino b questi possono avere più di un arco che li unisce. Ma ogni arco ha una interfaccia esclusiva su entrambi i nodi. Per esempio il nodo a può avere solo un arco che parte dalla sua interfaccia eth0 e arriva al nodo b. Un altro arco potrebbe ad esempio partire dall'interfaccia eth1 di a e arrivare a b. Allo stesso modo il nodo b deve avere più interfacce di rete per avere due archi verso a.

Ogni interfaccia di rete di ogni nodo, inoltre, ha un indirizzo di scheda univoco. Di conseguenza, quando il nodo a indica un indirizzo di scheda del suo vicino b, il nodo a indica precisamente un arco che lo congiunge a b attraverso due specifiche interfacce di rete dev_a e dev_b.

Sapendo questo, ad esempio in Linux, il comando  ping -q -n -c 1 169.254.21.36   potrà essere usato per misurare la latenza esattamente dell'arco che ci interessa, anche nel caso in cui per lo stesso vicino esistano due o più archi.

Il modulo non esclude altri meccanismi di misurazione del costo. Per dare il massimo supporto al suo utilizzatore, nel metodo measure_rtt sono passate queste informazioni relative all'arco:

  • string peer_addr - l'indirizzo di scheda della interfaccia del vicino,

  • string peer_mac - il MAC della interfaccia del vicino,

  • string my_dev - il nome della interfaccia del nodo.

  • string my_addr - l'indirizzo di scheda della interfaccia del nodo.

Netsukuku/ita/docs/ModuloNeighborhood/Requisiti (last edited 2016-02-25 17:19:27 by lukisi)