ARCHITETTURA XL-plugin

Capitolo 7

ARCHITETTURA XL-plugin

Nei precedenti capitoli abbiamo analizzato le principali problematiche relative allo sviluppo di soluzioni middleware in ambiente MANET. In particolare abbiamo studiato il paradigma P2P, osservando come si adatta bene alla struttura delle reti ad hoc. Quindi abbiamo descritto una nuova soluzione middleware, chiamata CrossROAD [Del05], che eredita le principali caratteristiche dei sistemi basati su overlay strutturato (in particolare ispirandosi al protocollo Pastry [DR01b]) ed ottimizza la costruzione ed il mantenimento dell'overlay attraverso un'interazione di tipo cross-layer con il livello routing.

Per poter operare correttamente, CrossROAD deve interagire con un protocollo di routing proattivo che fornisca informazioni costantemente aggiornate sulla topologia della rete. In particolare e possibile sfruttare l'invio periodico di pacchetti di controllo (tipico dei protocolli proattivi) per trasportare informazioni relative ai servizi oerti da ciascun nodo, implementando cos un protocollo di ricerca dei servizi (Service Discovery).

CrossROAD associa a ciascun servizio un identicativo univoco e prevede che il servizio venga annunciato in rete attraverso un opportuno messaggio, incapsulato all'interno dei pacchetti di controllo emessi dal protocollo di routing.

In questo modo si ottiene, a livello routing, una visione costantemente

aggiornata della rete e una completa consapevolezza di quali nodi sono

presenti in rete e di quali servizi orono. In particolare questa informazione deve essere direttamente accessibile da parte di CrossROAD, che la utilizza per costruire e mantenere aggiornato l'overlay. Come sappiamo, ogni overlay

e costituita da un insieme di nodi che forniscono un determinato servizio.

Attraverso l'interazione cross-layer, ciascuna istanza di CrossROAD riesce ad acquisire dal routing gli indirizzi IP di tutti i nodi della rete che orono un dato servizio e puo quindi associare a ciascuno di essi un identicativo logico univoco, calcolato come funzione hash dell'indirizzo IP. Questa informazione permette a ciascuna istanza di CrossROAD di costruire autonomamente l'overlay.

Per poter realizzare questo tipo di interazione cross-layer abbiamo sviluppato una libreria dinamica (XL-plugin) che estende il protocollo di routing proattivo UniKOLSR [UNI] in modo che possa interagire direttamente con il protocollo middleware CrossROAD.

XL-plugin e stato sviluppato in linguaggio C per la versione 0.4.8 del protocollo UniKOLSR, mentre CrossROAD e interamente sviluppato in linguaggio Java. Al ne di realizzare l'interazione cross-layer e necessario denire un protocollo per lo scambio di messaggi tra XL-plugin e CrossROAD. In particolare la comunicazione avverra attraverso delle connessioni TCP locali al nodo. In gura 7.1 e illustrato un esempio di interazione cross-layer per la costruzione di un overlay network tra i nodi A e B. Per la descrizione dettagliata delle strutture dati locali e dei messaggi citati di seguito si rimanda alle successive sezioni di questo capitolo.

L'interazione tra CrossROAD e XL-plugin inizia quando l'applicazione

A

, in funzione sul nodo A, registra l'identicativo del servizio che ore,

creando una nuova istanza di CrossROAD. In questo modo il nodo locale

si unisce all'overlay (o ne crea uno nuovo) inviando a XL-plugin un

messaggio (Publish Service) contenente l'identicativo del servizio associato

alla specica applicazione e il suo indirizzo IP. Non appena XL-plugin riceve

questo messaggio, aggiorna la struttura dati che memorizza la lista dei servizi

oerti dal nodo locale (LOCAL SERVICES) e incapsula l'informazione in un

pacchetto OLSR che verra inoltrato in rete dal demone del routing. Quando

questo messaggio arriva al nodo B, XL-plugin elabora l'informazione ricevuta

Figura 7.1: Interazioni cross-layer tra middleware e routing attraverso XL- plugin

ed aggiorna la struttura dati GLOBAL SERVICES che memorizza quali sono i servizi disponibili in rete e quali nodi li orono. A questo punto, quando l'applicazione sul nodo B vuole inviare un messaggio, puo ottenere direttamente dal routing la lista degli indirizzi IP dei nodi che costituiscono l'overlay e, dopo aver vericato la consistenza delle proprie strutture dati, seleziona il "miglior destinatario", inoltrandogli direttamente (con una connessione P2P) il messaggio. Per assicurare la consistenza dell'overlay, XL-plugin invia periodicamente in rete dei messaggi di mantenimento (Maintenance Message) con i quali annuncia i servizi disponibili su ciascun nodo. Inoltre, non appena viene chiusa un'istanza di CrossROAD (anche in caso di crash dell'applicazione), XL-plugin inoltra in rete un messaggio (Disconnect Message) con il quale informa gli altri partecipanti all'overlay dell'uscita del nodo locale. In questo modo non e piu necessario gestire un elevato numero di connessioni remote per il mantenimento della consistenza dell'overlay (come succede in Pastry). Inoltre la conoscenza completa della topologia dell'overlay permette anche di evitare di avere un inoltro multihop a livello middleware, caratteristico del routing basato su soggetto utilizzato in Pastry.

Come si vede in gura 7.2, CrossROAD interagisce direttamente con

UniKOLSR esteso attraverso XL-plugin. Il plugin dispone di una serie di

7.1 XL-plugin e architettura multithread

Figura 7.2: Architettura sistema

strutture dati che utilizza per mantenere consistenti le informazioni sullo stato della rete e per rispondere alle richieste di CrossROAD.

7.1 XL-plugin e architettura multithread

Per poter ottimizzare le prestazioni del sistema, XL-plugin e caratterizzato da un'architettura interna multithread. Ricordiamo che un'applicazione multithread e costituita da piu thread, che vengono eseguiti in modo concorrente. Ogni thread denisce un percorso d'esecuzione separato. L'uso di un'architettura multithread consente di scrivere software ecienti che sfruttano al massimo il processore, riducendo al minimo il suo tempo di inattivita. Appare evidente che una soluzione concorrente fornisce prestazioni migliori rispetto alle soluzioni caratterizzate da un unico usso d'esecuzione.

Inoltre l'architettura multithread e molto piu eciente dell'architettura multitasking, normalmente adottata dai piu diusi sistemi operativi e basata sull'esecuzione concorrente dei processi. Infatti i processi sono delle entita

"pesanti", che richiedono un proprio spazio di indirizzamento e comunicano

tra di loro in modo costoso e limitato. Inoltre la commutazione di contesto

(ovvero il passaggio dall'esecuzione di un processo ad un altro) risulta

estremamente costosa. Al contrario i thread sono considerati "processi

7.1 XL-plugin e architettura multithread

leggeri", vengono eseguiti concorrentemente ma condividono lo spazio di memoria, rendendo piu eciente il cambio di contesto. Nell'ambito dello sviluppo del plugin abbiamo utilizzato le funzioni di libreria fornite da POSIX Threads API (nota come pthread) [POS] del sistema operativo UNIX.

Quando il demone del routing carica la libreria dinamica XL-plugin, esegue innanzitutto la funzione olsr plugin init(...), come descritto nel capitolo 6. Questa funzione ha diversi compiti essenziali e puo essere considerata come una inizializzazione del plugin stesso. All'interno di tale funzione vengono creati i due thread principali di XL-plugin: il thread schedulatore e il thread server padre.

Il thread schedulatore ha il compito di attivare periodicamente gli eventi interni a XL-plugin, registrati all'interno della struttura dati INTERNAL EVENTS (vedere sezione 7.6).

Il thread server padre, invece, rimane in attesa di connessioni TCP (locali al nodo) da parte di una istanza di CrossROAD. In particolare la porta utilizzata per stabilire questo tipo di connessioni e detta IPC PORT e il suo valore numerico si trova denito nel le olsrd XLplugin.h. Per ogni connessione eettuata da un'istanza di CrossROAD, il thread server padre crea un thread server glio destinato a gestire direttamente la comunicazione con l'istanza di CrossROAD stessa, attraverso lo scambio di opportuni messaggi. Lo scenario descritto e illustrato in gura 7.3.

I vari thread server gli hanno una struttura interna abbastanza semplice.

Essi infatti si limitano a ricevere dei messaggi dalla corrispondente istanza

di CrossROAD e ad elaborarli opportunamente in funzione del tipo (vedere

sezione 7.5).

7.1 XL-plugin e architettura multithread

Figura 7.3: Creazione di un thread server glio per ogni istanza di CrossROAD

Riportiamo di seguito, a titolo d'esempio, il codice del corpo di ciascun thread server glio:

void  serverSon ( void  arg )f Msg r e c e i v e d ;

int connfd = ( int ) arg ;

pthread detach ( p t h r e a d s e l f ( ) ) ; for ( ; ; ) f

i f ( ! readMsg(& received , connfd ))f

plugin output ( "A problem has occured

while reading from the middleware . . . " ) ; p t h r e a d e x i t (NULL) ;

g

processMsg(& received , connfd ) ; g

g

7.1 XL-plugin e architettura multithread

Figura 7.4: Relazione tra istanze di CrossROAD e thread server di XL-plugin

Il corpo del thread server glio e costituito da un ciclo innito che prevede la ricezione di un messaggio dalla corrispondente istanza di CrossROAD e la conseguente elaborazione.

Sempre all'interno della funzione olsr plugin init(...) vengono "resettate"

tutte le strutture dati locali a XL-plugin e si indica al Packet Parser di UniKOLSR quale funzione utilizzare per analizzare i nuovi messaggi OLSR deniti dal plugin stesso (vedere sezione 7.5). Inoltre viene aggiunto allo schedulatore interno a UniKOLSR un evento per l'emissione periodica dei messaggi di mantenimento (Maintenance Message) (vedere sezione 7.4).

Per completare il caricamento di XL-plugin viene eseguita la funzione ipc - plugin init() che aggiunge un nuovo socket al Socket Parser di UniKOLSR.

Tale socket e chiamato ipc socket ed e condiviso da ciascun thread di XL- plugin associato ad una data istanza di CrossROAD.

Come illustrato in gura 7.4, a ciascuna istanza di CrossROAD (indicata

con CR1,...CRn) e associato un thread server glio all'interno di XL-plugin

(indicato con PL1,...,PLn), che deve gestire direttamente la comunicazione

con l'istanza di CrossROAD. I vari thread server gli condividono il socket per

la comunicazione IPC con il demone del routing. Per questo motivo l'accesso

7.1 XL-plugin e architettura multithread

a tale socket e protetto da un semaforo di mutua esclusione (pthread mutex t ipc mutex). Questo nuovo socket viene utilizzato per gestire la comunicazione da XL-plugin verso UniKOLSR e quindi verso la rete. A tale socket viene associata una specica funzione (ipc action(...)), invocata automaticamente da UniKOLSR ogni volta che ci sono dei dati disponibili sul socket stesso.

Per assicurare il corretto funzionamento del sistema, e necessario gestire la condizione critica rappresentata dal fallimento dell'applicazione o di CrossROAD stesso. Infatti tale fallimento potrebbe vericarsi senza la possibilita di lanciare verso il demone del routing un esplicito messaggio di disconnessione. E' necessario, quindi, che XL-plugin sia in grado di rilevare autonomamente la caduta di una qualsiasi istanza di CrossROAD, aggiornando conseguentemente le strutture dati locali e inviando in rete un messaggio Disconnect Message per comunicarlo agli altri nodi.

Osserviamo che il monitoraggio periodico delle istanze di CrossROAD permette (senza un'overhead eccessivo) di gestire la condizione critica rappresentata dal fallimento dell'applicazione o di CrossROAD stesso.

Infatti tale fallimento potrebbe vericarsi senza la possibilita di lanciare

verso il demone del routing un esplicito messaggio di disconnessione. Per

permettere a XL-plugin di rilevare autonomamente eventuali fallimenti di

CrossROAD, e necessario che ciascuna nuova istanza di CrossROAD invii

al corrispondente thread server di XL-plugin uno speciale messaggio di tipo

ALIVE. Una volta ricevuto questo messaggio, il thread server glio viene

registrato all'interno della struttura dati ALIVE THREADS. Il messaggio

ALIVE contiene delle informazioni relative all'istanza di CrossROAD che

lo ha generato. In particolare prevede l'indicazione dell'identicativo del

servizio (serviceID), del socket su cui avviene la connessione con il thread

server glio di XL-plugin e del numero di porta (detta alivePort) su cui tale

istanza puo essere interrogata da XL-plugin per vericare il suo corretto

stato di attivita. Durante il caricamento di XL-plugin viene registrato presso

il thread schedulatore interno un evento periodico per il monitoraggio delle

istanze di CrossROAD. Attraverso l'esecuzione di questo evento, XL-plugin

eettua periodicamente un tentativo di connessione verso la porta alivePort

di ciascuna istanza di CrossROAD. Se la connessione viene riutata signica

7.1 XL-plugin e architettura multithread

che la corrispondente istanza di CrossROAD e fallita. Dunque devono essere deallocate le informazioni di stato ad essa relative e deve essere mandato in rete un esplicito messaggo di disconnessione. Questo permette a XL-plugin di rilevare in modo autonomo il fallimento delle istanze di CrossROAD e comunicarlo in rete per assicurare il mantenimento della consistenza delle informazioni presenti nei vari nodi. Al contrario, l'eventuale fallimento del routing (e conseguentemente della libreria XL-plugin) viene gestito direttamente da CrossROAD.

Vediamo, adesso, una descrizione piu dettagliata dell'evoluzione nel tempo del sistema, rappresentata in gura 7.5.

Figura 7.5: Interazione tra applicazioni, CrossROAD, XL-plugin e UniKOLSR

L'applicazione locale crea un'istanza di CrossROAD, che a sua volta

invia a XL-plugin un messaggio di Publish Service con il quale annuncia

la disponibilita di un dato servizio. Non appena viene ricevuto questo

messaggio, il thread server padre interno a XL-plugin crea un thread server

glio, che si occupera d'ora in poi in modo esclusivo della comunicazione

con l'istanza corrispondente di CrossROAD. Il thread server glio provvede

immediatamente ad aggiornare la struttura dati LOCAL SERVICES e a

7.1 XL-plugin e architettura multithread

trasmettere il messaggio Publish Service ricevuto al demone del routing attraverso ipc socket. A questo punto, il demone del routing incapsula in un pacchetto OLSR un messaggio di tipo PUBLISH MESSAGE con cui annuncia la disponibilita del servizio e lo trasmette in broadcast. Per poter costituire un overlay occorre che sia presente in rete almeno un altro nodo che ore lo stesso servizio. Per questo motivo il thread server glio verica all'interno di GLOBAL SERVICES se vi sono altri nodi che orono quel servizio. In caso aermativo, invia un messaggio alla corrispondente istanza di CrossROAD (Result Message) indicando esplicitamente l'indirizzo IP di ciascun nodo che ore il servizio e il numero di porta su cui tale servizio viene oerto. Se invece non risultano presenti altri nodi che orono il servizio, il thread server glio si blocca su una variabile condizione e viene accodato in una lista interna contenente i thread in attesa dell'arrivo di altri nodi in rete per poter formare l'overlay (struttura dati WAIT FOR THREADS). Allo stesso tempo anche la corrispondente istanza di CrossROAD e sospesa e attende la lista dei nodi per poter costruire l'overlay.

Periodicamente il thread schedulatore manda in esecuzione un evento che ha il compito di risvegliare, se possibile, uno o piu thread tra quelli sospesi. In particolare ciascun thread della lista WAIT FOR SERVICES viene sbloccato se, dopo aver esaminato GLOBAL SERVICES, si e individuato almeno un altro nodo che ore lo stesso servizio atteso. Tutti i thread cos riavviati andranno autonamente (in mutua esclusione) ad accedere a GLOBAL SERVICES e recupereranno la lista dei nodi che orono il servizio richiesto, in modo da poterla noticare a CrossROAD. Una volta che CrossROAD dispone di tale lista, puo inizializzare autonomamente l'overlay.

A questo punto, quando un'applicazione che opera su CrossROAD vuole

inviare un messaggio (costituito dalla coppia (chiave, valore)), lo passa a

CrossROAD che, dopo aver vericato la consistenza dell'overlay, provvede a

individuare la migliore destinazione possibile per il messaggio e ad inoltrarlo

verso di essa con una connessione diretta.

7.2 Strutture dati locali

Figura 7.6: Struttura dati LOCAL SERVICES

7.2 Strutture dati locali

XL-plugin dispone di una serie di strutture dati interne per gestire il protocollo di ricerca dei servizi e l'interazione con CrossROAD. Tali strutture dati sono globali e condivise dai vari thread del plugin. E' compito di XL- plugin utilizzare e mantenere consistenti nel tempo tali strutture. Avendo adottato un'architettura multithread e necessario assicurare che l'accesso a tali strutture avvenga in mutua esclusione e quindi, per ciascuna di esse,

e presente un apposito semaforo pthread mutex t. Tutte queste strutture dati vengono "resettate" all'avvio di XL-plugin all'interno della funzione olsr plugin init(...).

7.2.1 LOCAL SERVICES

La struttura dati LOCAL SERVICES memorizza informazioni relative ai servizi presenti nel nodo locale. E' implementatata attarverso una lista dinamica, illustrata in gura 7.6. L'accesso a tale sruttura e consentito solo dopo aver acquisito il semaforo di mutua esclusione pthread mutex t local mutex.

La struttura dati LOCAL SERVICES e costituita da elementi di questo tipo:

struct l o c a l e n t r y f

u i n t 1 6 t s e r v i c e I D ; u i n t 1 6 t port ;

struct l o c a l e n t r y  next ;

g ;

7.2 Strutture dati locali

dove serviceID e un intero senza segno su 16 bit che identica univocamente il servizio, port e un intero senza segno su 16 bit che indica la porta locale al nodo su cui tale servizio viene oerto e next e un puntatore all'elemento successivo di LOCAL SERVICES. Osserviamo che per ipotesi in ogni nodo ci puo essere al piu un'istanza di un dato servizio.

Di seguito elenchiamo le funzioni che permettono di operare su LOCAL SERVICES:

 void showLocal ( void ) ;

Visualizza su schermo gli elementi di LOCAL SERVICES.

 int alreadyPresent ( const u i n t 1 6 t serviceID , const u i n t 1 6 t port ) ;

Verica se il servizio identicato da serviceID e port passati come parametri alla funzione e gia presente all'interno di LOCAL SERVICES, restituendo 1 in caso aermativo, 0 altrimenti.

 int updateLocalServices ( const u i n t 1 6 t serviceID , const u i n t 1 6 t port ) ;

Se il servizio identicato da serviceID e port passati come parametri alla funzione non e gia presente nella lista LOCAL SERVICES, viene aggiunto e la funzione termina restituendo 1. Altrimenti stampa un messaggio di errore per indicare che il servizio e gia presente e restituisce 0.

 void d e l e t e L o c a l S e r v i c e ( const u i n t 1 6 t s e r v i c e I D ) ; Cancella da LOCAL SERVICES il servizio identicato da serviceID e port passati come parametri alla funzione.

7.2.2 GLOBAL SERVICES

La struttura dati GLOBAL SERVICES memorizza delle informazioni sui

servizi presenti nei nodi della rete ad hoc. In particolare associa a ciascun

7.2 Strutture dati locali

Figura 7.7: Struttura dati GLOBAL SERVICES

servizio (identicato dal suo serviceID) una lista di nodi che lo orono. Per ciascun nodo che ore il servizio memorizza l'indirizzo IP e il numero di porta su cui il servizio viene oerto. GLOBAL SERVICES e implementata attraverso una lista dinamica, illustrata in gura 7.7. L'accesso a tale sruttura e consentito solo dopo aver acquisito il semaforo di mutua esclusione pthread mutex t global mutex.

Gli elementi che descrivono ciascun servizio hanno la seguente struttura:

struct g l o b a l s e r v i c e f

u i n t 1 6 t s e r v i c e I D ; u i n t 3 2 t numElem ;

struct g l o b a l e n t r y  f i r s t ; struct g l o b a l s e r v i c e  next ; g ;

dove serviceID e un intero senza segno su 16 bit che identica

univocamente il servizio, numElem e il numero di nodi che orono il servizio,

struct global entry* rst e un puntatore alla lista dei nodi che orono

7.2 Strutture dati locali

tale servizio mentre next e un puntatore al successivo servizio disponibile.

Ciascun nodo che ore un dato servizio e descritto da un elemento di questo tipo:

struct g l o b a l e n t r y f

union o l s r i p a d d r o r i g i n a t o r ; u i n t 1 6 t port ;

struct timeval timer ;

struct g l o b a l e n t r y  next ; g ;

dove originator e l'indirizzo IP del nodo che ore il servizio, port e il numero di porta su cui tale servizio viene oerto, timer indica no a quando l'informazione specicata deve essere considerata valida e next e un puntatore al successivo elemento global entry.

Come abbiamo visto, tutte le informazioni sui servizi presenti in rete e

sui nodi che li orono hanno una validita temporale, specicata dal campo

timer della struttura global entry. Periodicamente il thread schedulatore

interno a XL-plugin manda in esecuzione un evento che cancella da GLOBAL

SERVICES le entrate relative ai servizi scaduti. Quindi un nodo, ntanto

che continua ad orire un dato servizio, deve inviare periodicamente dei

messaggi di mantenimento (Maintenance Message) con i quali conferma la

disponibilita del servizio sul nodo locale. La ricezione di tali messaggi da

parte degli altri nodi della rete permette di aggiornare coerentemente la

struttura dati GLOBAL SERVICES. Osserviamo che se un nodo fallisce (ad

esempio per un crash del routing o dell'applicazione), tutti gli altri nodi

della rete, che non ricevono piu messaggi di mantenimento dal nodo fallito,

riescono comunque ad aggiornare e rendere consistenti le proprie strutture

dati.

7.2 Strutture dati locali

Vediamo adesso le funzioni che permettono di operare su GLOBAL SERVICES:

 void globalServiceTimeout ( void h ) ;

Questa funzione viene invocata periodicamente dal thread schedulatore ed elimina gli elementi obsoleti di GLOBAL SERVICES.

 int updateGlobalServices ( const o l s r u 8 t type , union o l s r i p a d d r  o r i g i n a t o r , struct s e r v i c e  message , const double vtime , const int numElem ) ;

Questa funzione viene invocata quando arriva un messaggio di PUBLISH, DISCONNECT o MAINTENANCE e aggiorna GLOBAL SERVICES sulla base del contenuto del messaggio stesso.

 void r e f r e s h S e r v i c e s ( void ) ;

Elimina da GLOBAL SERVICES tutte le entrate corrispondenti a servizi per i quali non esiste alcun nodo che li ore, ovvero le entrate di tipo struct global service il cui puntatore rst punta a NULL.

 struct g l o b a l e n t r y  peerAlreadyAvailable ( struct g l o b a l s e r v i c e  s , union o l s r i p a d d r  o r i g i n a t o r , const u i n t 1 6 t port ) ;

Questa funzione verica se il nodo avente indirizzo IP pari a originator

e gia presente in GLOBAL SERVICES come nodo che ore il servizio indicato da struct global service* s sulla porta port. Se e presente restituisce un puntatore all'entrata corrispondente, altrimenti ritorna NULL.

 struct g l o b a l s e r v i c e  s e r v i c e A l r e a d y A v a i l a b l e ( const u i n t 1 6 t s e r v i c e I D ) ;

Questa funzione verica se e presente il servizio con serviceID

all'interno di GLOBAL SERVICES. Se e presente restituisce un

puntatore alla corrispondente struct global service, altrimenti ritorna

NULL.

7.2 Strutture dati locali

 struct g l o b a l s e r v i c e  addService ( const u i n t 1 6 t s e r v i c e I D ) ;

Questa funzione aggiunge a GLOBAL SERVICES il servizio con serviceID passato come parametro e restituisce in caso positivo un puntatore a struct global service. Se non riesce ad aggiungere il servizio, ritorna NULL.

 int addPeer ( union o l s r i p a d d r  o r i g i n a t o r , const

u i n t 1 6 t port , double vtime , struct g l o b a l s e r v i c e  entry ) ; Questa funzione aggiunge a GLOBAL SERVICES il nodo avente

indirizzo IP pari a originator come nodo che ore il servizio indicato da serviceID sulla porta port, restituendo in caso positivo un puntatore a struct global service. Se non riesce ad aggiungere il servizio, ritorna NULL.

 int d e l e t e P e e r ( union o l s r i p a d d r  o r i g i n a t o r ,

const u i n t 1 6 t port , struct g l o b a l s e r v i c e  entry ) ; Questa funzione elimina da GLOBAL SERVICES il nodo avente indirizzo IP pari a originator e che ore il servizio indicato da serviceID sulla porta port, restituendo 1 in caso di successo e 0 altrimenti.

 void updateTimer ( struct g l o b a l e n t r y  entry , double vtime ) ; Questa funzione aggiorna il campo timer dell'elemento di GLOBAL

SERVICES puntato dal parametro entry con il valore specicato dal parametro vtime.

7.2.3 WAIT FOR SERVICES

Quando un thread server glio, associato ad una data istanza di CrossROAD,

cerca di recuperare dalla struttura dati GLOBAL SERVICES la lista dei

nodi che orono il servizio corrispondente. Se la trova vuota, si blocca

su una variabile condizione. Inoltre deve inserire una serie di informazioni

7.2 Strutture dati locali

Figura 7.8: Struttura dati WAIT FOR SERVICES

necessarie per poterlo sbloccare all'interno di una opportuna struttura dati, detta WAIT FOR SERVICES. Tale struttura e implementatata attraverso una lista dinamica collegata, illustrata in gura 7.8. L'accesso a tale sruttura e consentito solo dopo aver acquisito il semaforo di mutua esclusione pthread mutex t waitfor mutex.

La lista WAIT FOR SERVICES e costituita da elementi di questo tipo:

struct wait entry f

u i n t 1 6 t s e r v i c e I D ;

pthread cond t c o n d i t i o n ; struct wait entry  next ; g ;

dove serviceID e un intero senza segno su 16 bit che identica univocamente il servizio, condition e una variabile condizione su cui si e bloccato un thread di XL-plugin in attesa che arrivi almeno un altro nodo nell'overlay che ore il servizio indicato da serviceID, next e un puntatore all'elemento successivo di WAIT FOR SERVICES.

Vediamo adesso le funzioni che permettono di operare su WAIT FOR SERVICES:

 void showWait ( void ) ;

Visualizza su schermo gli elementi di WAIT FOR SERVICES.

 struct wait entry  addWaitEntry ( const u i n t 1 6 t s e r v i c e I D ) ; Aggiunge un nuovo elemento alla lista WAIT FOR SERVICES,

restituendo un puntatore a tale elemento in caso positivo e NULL

7.2 Strutture dati locali

altrimenti. Il nuovo elemento rappresenta un thread server glio di XL-plugin associato ad un'istanza di CrossROAD che ore un servizio identicato da serviceID e che attende la presenza di almeno un altro nodo che ora tale servizio all'interno della rete per poter costituire l'overlay.

 void deleteWaitEntry ( const u i n t 1 6 t s e r v i c e I D ) ; Cancella l'elemento di WAIT FOR SERVICES avente serviceID pari a quello passato come parametro alla funzione.

7.2.4 ALIVE THREADS

XL-plugin associa un thread ad ogni istanza di CrossROAD e memorizza delle informazioni sul thread all'interno della struttura dati ALIVE THREADS.

Tale struttura e utilizzata periodicamente per monitorare lo stato delle varie istanze di CrossROAD, rendendo le strutture dati interne consistenti in caso di fallimento di una di esse. Infatti, un thread deve rimanere attivo nche lo e la corrispondente istanza di CrossROAD e quindi ALIVE THREADS viene periodicamente utilizzata dal thread schedulatore per vericare se l'istanza CrossROAD corrispondente a ciascun thread e ancora attiva. E' implementatata attraverso una lista dinamica, illustrata in gura 7.9. L'accesso a tale sruttura e consentito solo dopo aver acquisito il semaforo di mutua esclusione pthread mutex t waitfor mutex.

Figura 7.9: Struttura dati ALIVE THREADS

7.2 Strutture dati locali

La lista ALIVE THREADS e costituita da elementi di questo tipo:

struct a l i v e e n t r y f

pthread t threadID ; u i n t 1 6 t s e r v i c e I D ; u i n t 1 6 t a l i v e P o r t ; int sock ;

struct a l i v e e n t r y  next ; g ;

dove threadID e l'identicativo del thread interno al sistema operativo, serviceID e l'identicativo del servizio oerto dall'istanza CrossROAD corrispondente al thread, alivePort e la porta su cui eettuare periodicamente una procedura di polling per vericare se l'istanza CrossROAD risulta attiva e sock e l'identicativo del socket utilizzato per comunicare con l'istanza corrispondente di CrossROAD.

Vediamo adesso le funzioni che permettono di operare su ALIVE THREADS:

 int addThread ( const pthread t threadID , const u i n t 1 6 t serviceID , const u i n t 1 6 t alivePort , const int sock ) ;

Aggiunge un nuovo elemento alla lista ALIVE THREADS, inizializzandolo con i parametri attuali passati alla funzione.

 void deleteThread ( const pthread t threadID ) ;

Cancella dalla lista ALIVE THREADS l'elemento avente threadID

passato come parametro.

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

Ciascuna istanza di CrossROAD comunica con il corrispondente thread server di XL-plugin attraverso una connessione TCP locale al nodo, scambiando dei messaggi ben deniti. Una volta che ciascuno di questi messaggi e stato elaborato, il thread server che lo ha ricevuto torna in attesa di nuove comunicazioni da parte della corrispondente istanza di CrossROAD.

7.3.1 Publish Service

Il messaggio Publish Service viene usato da CrossROAD per annunciare in rete la disponibilita di un nuovo servizio nel nodo locale. Ciascun servizio viene rappresentato attraverso una coppia di interi senza segno su 16 bit che rappresentano rispettivamente l'identicativo del servizio (serviceID) e il numero di porta locale al nodo (port number) su cui tale servizio viene oerto. Quando un'istanza di CrossROAD vuole pubblicare il servizio oerto dall'applicazione a lei associata, invia al corrispondente thread server di XL- plugin un messaggio avente il formato indicato in gura 7.10.

Figura 7.10: Formato messaggio Publish Service

In particolare Publish Service e il tipo del messaggio, serviceID e

l'identicativo del servizio e port e il numero di porta su cui tale servizio

viene oerto.

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

Il thread server che riceve questo messaggio dalla corrispondente istanza di CrossROAD deve:

1. Aggiornare la struttura dati LOCAL SERVICES, inserendo la disponibilita del nuovo servizio. Se il servizio dovesse essere gia presente, invia un messaggio di errore all'istanza di CrossROAD che lo ha annunciato e torna in attesa di nuovi messaggi (per ipotesi su ogni nodo vi puo essere al piu un'istanza di ciascun servizio).

2. Acquisire in mutua esclusione il socket per la comunicazione IPC con UniKOLSR e inviare su tale socket il messaggio ricevuto. L'azione associata dal Packet Parser prevede la generazione di un messaggio Publish Message che sara inoltrato in rete in accordo al protocollo OLSR.

3. Vericare se ci sono altri nodi in rete che orono il servizio pubblicato, accedendo in mutua esclusione alla struttura dati GLOBAL SERVICES. In caso positivo, restituisce con un messaggio Result la lista di tali nodi all'istanza di CrossROAD. Altrimenti si blocca, registrandosi nella lista WAIT FOR SERVICES in attesa che qualche altro nodo ora lo stesso servizio e, di conseguenza, possa essere sbloccato dal thread schedulatore.

7.3.2 Disconnect Service

Il messaggio Disconnect Service viene usato da CrossROAD per annunciare

che un dato servizio non risulta piu disponibile sul nodo locale (ad esempio

perche l'applicazione corrispondente e stata chiusa). Tutti i nodi della

rete devono acquisire questa informazione per aggiornare coerentemente le

proprie strutture dati locali. Il servizio da cancellare viene identicato

attraverso una coppia di interi senza segno su 16 bit che rappresentano

rispettivamente l'identicativo del servizio (serviceID) e il numero di porta

locale al nodo (port number) su cui tale servizio viene oerto. Quando

un'istanza di CrossROAD vuole annullare la disponibilita di un servizio

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

oerto dall'applicazione associata, invia al corrispondente thread server di XL-plugin un messaggio avente il formato indicato in gura 7.11.

Figura 7.11: Formato messaggio Disconnect Service

In particolare Disconnect Service e il tipo del messaggio, serviceID e port rappresentano rispettivamente l'identicativo ed il numero di porta del servizio da cancellare. Il thread server che riceve questo messaggio dalla corrispondente istanza di CrossROAD deve:

1. Vericare che il servizio da rimuovere risulti eettivamente tra quelli disponibili in LOCAL SERVICES. In caso contrario stampa a video un messaggio d'errore e torna in attesa di nuovi messaggi.

2. Eliminare il servizio dalla struttura dati LOCAL SERVICES.

3. Acquisire in mutua esclusione il socket per la comunicazione IPC con UniKOLSR e inviare su tale socket il messaggio ricevuto. L'azione associata dal Packet Parser prevede la generazione di un messaggio Disconnect Message che sara inoltrato in rete in accordo al protocollo OLSR.

4. Eliminare dalla struttura dati ALIVE THREADS le informazioni ad esso relative, chiudere il socket aperto per la comunicazione con la corrispondente istanza di CrossROAD e terminare l'esecuzione attraverso la chiamata a pthread exit().

7.3.3 Lookup Service

Il messaggio Lookup Service viene usato da CrossROAD per chiedere ad XL-

plugin la lista dei nodi presenti in GLOBAL SERVICES che orono un dato

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

servizio. Questa informazione serve a CrossROAD per costruire autonamente l'overlay e viene chiesta non appena viene pubblicato per la prima volta un servizio e prima dell'invio di ogni nuovo messaggio applicativo, per vericare la consistenza dell'overlay.

Il servizio richiesto viene identicato attraverso un intero senza segno su 16 bit (serviceID). Il formato del messaggio Lookup Service e riportato in gura 7.12.

Figura 7.12: Struttura messaggio Lookup Service

In particolare Lookup Service e il tipo del messaggio mentre serviceID e l'identicativo del servizio ricercato in rete. Quando il thread server glio riceve questo tipo di messaggio verica se ci sono altri nodi in rete che orono il servizio indicato, accedendo in mutua esclusione alla struttura dati GLOBAL SERVICES. In caso positivo, restituisce con un messaggio Result la lista di tali nodi all'istanza di CrossROAD. Altrimenti blocca il thread inserendolo nella lista WAIT FOR SERVICES, in attesa che qualche altro nodo pubblichi il servizio e quindi possa essere sbloccato dal thread schedulatore.

7.3.4 Alive

Il messaggio Alive e il primo messaggio che un'istanza di CrossROAD deve mandare al corrispondente thread server glio. CrossROAD ha una struttura interna multithread che prevede la presenza di un thread server che rimane in attesa di richieste di connessione eettuate periodicamente da XL-plugin.

Attraverso questa tecnica, come vedremo in dettaglio nella sezione 7.7, XL-

plugin e in grado di rilevare autonomamente la caduta o il fallimento di una

qualsiasi istanza di CrossROAD. Attraverso il messaggio Alive ogni istanza di

7.3 Formato dei messaggi scambiati tra CrossROAD e XL-plugin

CrossROAD indica il servizio cui e associata, il socket che usa per comunicare con il corrispondente thread di XL-plugin e, sopratutto, il numero di porta su cui XL-plugin puo interrogarla per scoprire se e sempre attiva o no.

Il formato del messaggio Alive e riportato in gura 7.13.

Figura 7.13: Struttura messaggio Alive

In particolare Alive e il tipo del messaggio, serviceID e l'identicativo del servizio oerto dalla corrispondente istanza di CrossROAD e alivePort e il numero di porta su cui tale istanza puo essere contattata per vericarne lo stato. Quando il thread server glio riceve questo tipo di messaggio inserisce un nuovo elemento nella lista ALIVE THREADS contenente le informazioni acquisite dal messaggio Alive oltre all'identicativo del thread e al socket utilizzato per comunicare con l'istanza di CrossROAD.

7.3.5 Result

Il messaggio Result viene generato da XL-plugin per noticare a CrossROAD la lista dei nodi presenti in GLOBAL SERVICES che orono un dato servizio. Questa informazione serve a CrossROAD per costruire autonamente l'overlay. In particolare il messaggio prevede che, per ciascun nodo (come indicato in GLOBAL SERVICES), venga fornito l'indirizzo IP e il numero di porta locale su cui il servizio viene fornito. Il formato del messaggio Result

e riportato in gura 7.14.

In particolare Result e il tipo del messaggio mentre N indica il numero

di nodi distinti che vengono di seguito annunciati attraverso indirizzo IP e

numero di porta su cui forniscono il servizio.

7.4 Formato dei nuovi tipi di messaggio inviati verso la rete

Figura 7.14: Struttura messaggio Result

7.3.6 Error

Il messaggio Error viene inviato da XL-plugin verso CrossROAD per noticare che il servizio pubblicato risulta gia presente nel nodo locale. Il formato del messaggio Error e riportato in gura 7.15.

Figura 7.15: Struttura messaggio Error

In particolare e costituito soltanto dal tipo, espresso su 1 byte e indicato con ERR. L'elaborazione di tale messaggio e gestita da CrossROAD.

7.4 Formato dei nuovi tipi di messaggio inviati verso la rete

La libreria XL-plugin denisce 3 nuovi tipi di messaggio che estendono quelli predeniti specicati dal protocollo OLSR e sono chiamati Publish Message, Disconnect Message e Maintenance Message. Il formato e quello previsto dal protocollo OLSR ed e rappresentato in gura 7.16.

Naturalmente ciascuno dei tre messaggi avra un valore diverso per il

campo Message Type. In particolare Publish Message ha Message Type pari

7.4 Formato dei nuovi tipi di messaggio inviati verso la rete

Figura 7.16: Formato messaggio XL-plugin

a 128, Disconnect Message pari a 129 e Maintenance Message pari a 130.

Inoltre il messaggio Maintenance Message contiene tante coppie (serviceID, port) all'interno del corpo quanti i servizi locali al nodo presenti in LOCAL SERVICES.

I messaggi Publish Message e Disconnect Message vengono generati dalla funzione ipc action che viene eseguita quando un thread server scrive (in mutua esclusione) sull'ipc socket il messaggio di Publish Service o Disconnect Service ricevuto dalla corrispondente istanza di CrossROAD. In pratica la funzione ipc action si limita a trasformare le informazioni ricevute in un messaggio che possa essere incapsulato in un pacchetto OLSR. In particolare ciascun servizio viene descritto dalla seguente struttura:

struct s e r v i c e f

o l s r u 1 6 t s e r v i c e I D ; o l s r u 1 6 t port ;

g ;

Per poterlo utilizzare come corpo in un messaggio OLSR abbiamo utilizzato la seguente struttura:

struct servicemsg f

struct s e r v i c e s er vi c e ms g [ 1 ] ;

g ;

7.4 Formato dei nuovi tipi di messaggio inviati verso la rete

Figura 7.17: Scrittura XL-plugin nel buer condiviso con il demone del routing

Ecco, inne, la struttura che rappresenta il messaggio OLSR:

struct olsrmsg f

o l s r u 8 t olsr msgtype ; o l s r u 8 t o l s r v t i m e ; o l s r u 1 6 t o l s r m s g s i z e ; o l s r u 3 2 t o r i g i n a t o r ; o l s r u 8 t t t l ;

o l s r u 8 t hopcnt ; o l s r u 1 6 t seqno ;

struct servicemsg msg ; g ;

La scrittura del messaggio (opportunamente inizializzato) non viene direttamente fatta su un socket di rete ma all'interno di un buer condiviso con UniKOLSR e chiamato net outbuer, come illustrato in gura 7.17.

Tale buer viene acceduto direttamente da UniKOLSR che provvede a incapsulare i messaggi contenuti al suo interno dentro pacchetti OLSR.

Questa strategia ottimizza le prestazioni, rendendo possibile l'inoltro, con

un unico pacchetto OLSR, di svariati tipi di messaggio.

7.5 Parsing dei nuovi tipi di messaggio ricevuti dalla rete

I messaggi Maintenance Message, invece, vengono generati periodicamente dalla funzione olsrMaintenanceEvent(...) registrata presso lo schedulatore interno al demone del routing UniKOLSR. Queta funzione accede alla struttura dati LOCAL SERVICES (in mutua esclusione) e genera un apposito messaggio dove vengono annunciati tutti i servizi presenti nel nodo locale e il numero di porta su cui vengono oerti. Il periodo di emissione, detto MAINTENANCE INTERVAL, e specicato nel le olsrd XLplugin.h.

7.5 Parsing dei nuovi tipi di messaggio ricevuti dalla rete

In fase di avvio, XL-plugin utilizza la funzione olsr parser add function(...) (importata da UniKOLSR) per associare una funzione di parsing ai nuovi tipi di messaggio, descritti nella precedente sezione. La funzione che viene aggiunta al Packet Parser ha il seguente prototipo:

void o l s r P a r s e r ( union o l s r m e s s a g e m, struct i n t e r f a c e  i n i f , union o l s r i p a d d r  in addr ) ;

Questa funzione viene invocata direttamente dal demone del routing

quando riceve dalla rete un messaggio di tipo Publish Message, Disconnect

Message o Maintenance Message. Dopo aver vericato che il messaggio

sia stato generato da un vicino simmetrico e non dal nodo locale stesso

(situazione di loop), cerca di acquisire in mutua esclusione la struttura

dati locale GLOBAL SERVICES. Ottenuto l'accesso a tale struttura,

provvede attraverso la funzione update global services(...) ad aggiornarla

coerentemente con il messaggio ricevuto. Quindi inoltra il messaggio stesso

in accordo all'algoritmo previsto dal protocollo OLSR.

7.6 Eventi interni a XL-plugin

L'aggiornamento di GLOBAL SERVICES viene svolto da update global services(...) in accordo alle seguenti regole:

1. Se riceve un messaggio Publish Message e il servizio annunciato non e gia presente in GLOBAL SERVICES, lo aggiunge assieme al nodo che ha originato il messaggio (il cui indirizzo IP e dato dal campo Originator del messaggio stesso). Se, invece, il servizio risulta gia disponibile ma non il nodo che lo ore, aggiunge il nodo. Se invece sia il servizio che il nodo risultano gia disponibili, aggiorna la validita dell'entrata di GLOBAL SERVICES.

2. Se riceve un messaggio Disconnect Message, cancella (se presente) l'entrata corrispondente al servizio e al nodo che lo ore da GLOBAL SERVICES. Inoltre, cancella i servizi che non hanno piu nodi che li orono.

3. Se riceve un messaggio Maintenance Message esegue le stesse operazioni svolte per un Publish Message in corrispondenza di ciascuna coppia (serviceID, port) presente nel corpo del messaggio.

7.6 Eventi interni a XL-plugin

All'interno di XL-plugin ci sono alcune attivita che devono essere svolte periodicamente. Per raggiungere questo scopo, all'avvio viene creato un thread schedulatore con il compito di attivare periodicamente tali attivita.

In particolare all'interno della struttura dati INTERNAL EVENTS vengono memorizzati gli eventi che devono essere lanciati periodicamente dal thread schedulatore. Ciascun evento e rappresentato dall'esecuzione di una funzione.

La struttura dati INTERNAL EVENTS e implementatata attraverso una

lista dinamica collegata, illustrata in gura 7.18.

7.6 Eventi interni a XL-plugin

Figura 7.18: Struttura dati INTERNAL EVENTS

La lista INTERNAL EVENTS e costituita da elementi di questo tipo:

struct event f

void ( f u n c t i o n ) ( void  ) ; float i n t e r v a l ;

float i n i t i a l ; float s i n c e l a s t ; int t r i g g e r ;

struct event  next ; g ;

dove function e un puntatore alla funzione che deve essere eseguita

come evento, interval e il periodo con cui tale evento deve essere eseguito,

initial e un possibile ritardo iniziale (in secondi) con cui deve essere lanciato

l'evento, since last e il tempo (in secondi) eettivamente trascorso dall'ultima

esecuzione dell'evento (dato dalla dierenza tra interval e initial), trigger e

un valore booleano che, se vale 1, indica che l'evento deve essere eseguito ad

ogni ciclo del thread schedulatore (indipendentemente dal periodo) e inne

next e un puntatore all'evento successivo della lista.

7.6 Eventi interni a XL-plugin

Vediamo adesso la funzione che permette di operare su INTERNAL EVENTS:

 int addInternalEvent ( void ( e v e n t f u n c t i o n ) ( void ) , float i n t e r v a l , float i n i t i a l , int t r i g g e r )

Aggiunge un evento alla lista inizializzando gli elementi di struct internal event con i parametri attuali della funzione.

Il thread schedulatore ha una struttura ciclica e viene eseguito con periodo pari a sched poll interval (in generale dell'ordine di 0.05 sec.), specicato nel le olsrd XLplugin.h. Occorre utilizzare un periodo cos piccolo per poter garantire il rispetto della periodicita nella schedulazione degli eventi registrati in INTERNAL EVENTS.

In particolare, all'avvio di XL-plugin vengono aggiunti alcuni eventi alla lista INTERNAL EVENTS. Innanzitutto viene registrato l'evento periodico per l'eliminazione delle entrate obsolete di GLOBAL SERVICES, rappresentato dalla funzione globalServiceTimeout(...). Viene poi registrato l'evento per la verica periodica della possibilita di sbloccare dei thread (e quindi delle istanze di CrossROAD) in attesa di altri nodi nella rete che orano il corrispondente servizio. Questa funzione viene svolta andando a vericare, per ciascun thread presente nella WAIT FOR LIST, se c'e almeno un altro nodo in GLOBAL SERVICES che ore il servizio atteso. In caso positivo, il thread viene svegliato e, in modo concorrente, cerca di accedere a GLOBAL SERVICES per recuperare la lista dei nodi che orono lo stesso servizio dell'istanza CrossROAD cui e associato.

Inne viene registrato un evento per il monitoraggio periodico dello stato di funzionamento delle istanze di CrossROAD. In particolare, la funzione isAlive(...) eettua periodicamente un tentativo di connessione verso la porta alivePort di ciascuna istanza CrossROAD. Se la connessione viene riutata signica che la corrispondente istanza di CrossROAD e fallita. Dunque devono essere deallocate le informazioni di stato ad essa relative e deve essere mandato in rete un esplicito messaggio di disconnessione.

Nel prossimo capitolo illustreremo le sperimentazioni eettuate

utilizzando CrossROAD e UniKOLSR esteso attarverso la libreria XL-plugin.

7.6 Eventi interni a XL-plugin