IP Mobility e Multihoming nell'architettura Serval

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili IP Mobility e Multihoming nell'architettura Serval Anno Accademico 2014/2015 Candidato: Umberto Ferrandino matr. N46/000932

2 IP Mobility e Multihoming nell'architettura Serval Umberto Ferrandino LATEX 2

3 Dedicato a chi, nei modi più svariati, ma sempre con le migliori intenzioni, mi ha sostenuto ed accompagnato in questo cammino. 3

4 Indice Introduzione 5 1 Serval Architecture Problematiche arontate Cos'è Serval? La rete del futuro Il concetto di Servizio Service Access Layer (SAL) Installazione del SAL Funzionalità di base Ripensare lo stack TCP/IP Livello Applicazione Livello Trasporto Livello Rete Astrazione dei servizi e dei ussi Service Naming Flow Naming Inoltro dei pacchetti nello stack Serval Active Socket Forwarding e data plane Service discovery e registration Meccanismi di segnalazione eventi Prototipo dell'architettura Benchmark performance Casi di studio Web Service replicato con load balancing Storage distribuito Migrazione ussi e macchine virtuali Translator per compatibilità con host legacy 32 8 Dimostrazioni e test di funzionamento Catturare pacchetti Serval con Wireshark Invio di un le Flow migration Conclusioni 39 Bibliograa 40 4

5 Introduzione Fin dagli anni sessanta, la rete Internet, o ancora prima ARPANET, si è evoluta seguendo quelle che erano le necessità cui tale invenzione poteva far fronte. In pochi anni, il mondo intero ha assistito a quella che è probabilmente una delle più grandi rivoluzioni tecnologiche che la storia ricordi: da un progetto partito per essere un esperimento militare, poi un modo per interconnettere una quantità limitata di terminali, si è giunti ad interconnettere l'intero globo, rendendo pressoché irrisoria ogni distanza e possibile ogni comunicazione. Come è ovvio che sia, anché tale evoluzione fosse possibile, la rete ha dovuto subire una serie di cambiamenti e migliorie, con l'introduzione di nuovi protocolli e funzionalità, al ne di restare al passo con i tempi e garantire specici standard in materia di sicurezza, ecienza e quant'altro. Ad oggi, Internet va incontro ad ulteriori e più radicali cambiamenti. Infatti, nel corso degli anni, pur evolvendosi, la struttura di base della rete è rimasta fedele allo stesso modello, il famoso Stack TCP/IP. Con l'avvento del cosiddetto Web 2.0, Internet è diventato fortemente interattivo, grazie alla creazione delle piattaforme e delle applicazioni, che fanno ormai parte, della vita di tutti i giorni di ognuno di noi. Tuttavia, tale processo, ha mostrato agli sviluppatori, agli ingegneri e a chiunque lavorasse nell'ambito del networking, una serie di inadeguatezze cui la rete è soggetta, specialmente in vista di quello che potrebbe essere il passo successivo nella trasformazione di Internet e dunque, inevitabilmente, della vita di coloro che ne usufruiscono. Per far fronte alle problematiche postesi, quali ad esempio il crescente numero di dispositivi connessi alla rete (e di conseguenza al carico di lavoro dei server), o alla sempre più frequente presenza nella rete di dispositivi mobili, molti provvedimenti, sono già stati messi in atto, altrettanti invece, sono in cantiere o in attesa di essere standardizzati. Ad ogni modo, così come si è passati da un web prevalentemente statico, ad uno fortemente sociale, che basa le propria fondamenta sulla libertà di espressione e di condivisione (appunto il Web 2.0 ), allo stesso modo, si viaggia verso un nuovo web, in cui ogni oggetto possa essere connesso alla rete per sfruttarne le potenzialità, in cui l'utente possa vivere un'esperienza virtuale completa grazie alla realtà aumentata e alla semantica dei contenuti (solitamente indicato con Web 3.0 ). Tale elaborato, si propone dunque, di illustrare uno dei progetti in via di sviluppo più interessanti nell'ambito della mobilità e del multihoming, ovvero: Serval Architecture. 5

6 1 Serval Architecture 1.1 Problematiche arontate Un tempo, il web era popolato prevalentemente da dispositivi la cui mobilità era limitata ad un ambiente domestico o aziendale. La comunicazione avveniva dunque, tra singoli terminali che dicilmente avevano necessità di spostarsi. Oggigiorno, le cose sono profondamente cambiate. Infatti, sempre più spesso, un'altissima percentuale dei client che usufruiscono di un determinato servizio, sono dispositivi mobili con diverse interfacce di comunicazione (ad esempio, Wi-Fi e 3G/4G). Data la proliferazione degli abitanti del web, i provider, e in generale tutte le realtà che forniscono servizi online ad una copiosa utenza, hanno dovuto adeguare i propri organismi, passando ad architetture che prevedono numerosi server dislocati in tutto il globo. Tutto ciò ovviamente, si ripercuote sul funzionamento e sulla essibilità dei servizi. Lo stack TCP/IP, risulta essere inadeguato per quelli che sono i prossimi step nell'evoluzione della mobilità e della fruizione dei contenuti. Ad esempio, diverse sono le problematiche legate allo spostamento del usso di rete da un'interfaccia all'altra (si pensi ad esempio al fatto che, sul proprio smartphone, non si possa intercambiare Wi-Fi e 3G/4G in modo trasparente e senza interrompere le connessioni in corso), o all'utilizzo parallelo di più interfacce per lo stesso scopo (ad esempio, uno streaming in cui il download dei dati avviene in parallelo tra rete wireless e rete mobile). Per quanto riguarda invece la gestione dei server, si rende necessario un load balancer, in grado di distribuire nel miglior modo possibile il carico di lavoro tra i server, evitandone il sovraccarico. An application can run on multiple servers at dierent locations, and can launch at or migrate to a new machine at any time. In addition, user devices are often multi-homed (e.g., WiFi and 4G) and mobile. In short, modern services operate under unprecedented multiplicity (in service replicas, host interfaces, and network paths) and dynamism (due to replica failure and recovery, service migration, and client mobility). Yet, multiplicity and dynamism match poorly with today's host-centric TCP/IP-stack that binds connections to xed attachment points with topology-dependent addresses and conates service, ow, and network identiers. This forces online services to rely on clumsy and restrictive techniques that manipulate the network layer and constrain how services are composed, managed, and controlled. For example, today's load balancers repurpose IP addresses to refer to a group of (possibly changing) service instances; unfortunately, this requires all client trac to traverse the load balancer. Si veda [1, p. 1] per maggiori informazioni. 6

7 1.2 Cos'è Serval? Serval, è un progetto open source dell'università di Princeton, nato da un'idea di Michael J.Freedman, professore associato della facoltà di Informatica. Come spiegato precedentemente, le problematiche cui va incontro Internet, sono molteplici e rischiano di comprometterne un funzionamento ottimale in futuro. Per tale motivo, molti sono i progetti nati al ne di evitare che ciò accada. Serval è uno di questi: Freedman infatti, sostiene che ad oggi, gli ingegneri per poter implementare talune funzionalità, debbano ricorrere ad una serie di hack piuttosto complessi, che non sarebbero necessari risolvendo alla base le problematiche di cui sopra. Si veda [3]. Smart engineers are great at mastering complexity and hacking around it. But with the current approach, everybody needs to reinvent the wheel [...] Serval is something that will make things easier to build and easier to manage without relying on these hacks. Oltre Freedman, lavorano a Serval, anche Erik Nordstrom, David Shue, Prem Gopalan, Robert Kiefer, Matvey Arye, Steven Y.Ko e Jennifer Rexford. Il progetto, è stato nanziato da: National Science Fundation, DARPA, Oce of Naval Research e Cisco Systems. [4] La rete del futuro L'idea che sta alla base di Serval, vede l'utente, non più interessato al web come mezzo per interconnettersi ad uno specico terminale nella rete, ma piuttosto come tramite verso uno specico servizio. Si pensi ad esempio a realtà quali Google, che mettono a disposizione una moltitudine di servizi (Gmail, Maps, Drive etc.) dislocati su altrettanti server: un indirizzo IP, all'interno della rete, non può che rappresentare una specica macchina. Tale approccio, che prevede l'utilizzo dei load balancers sopracitati, risulta dunque fortemente limitativo in ambienti in cui, ogni funzionalità deve necessariamente essere dislocata su più server per far fronte al carico di lavoro. Inoltre, tutto ciò, impone dei vincoli in termini di mobilità degli host, i quali, non possono ad esempio migrare da una interfaccia all'altra, e dunque cambiare il proprio indirizzo IP, senza che la fruizione del servizio venga interrotta. Jennifer Rexfort, professoressa del dipartimento di Informatica, impegnata nello sviluppo di Serval, sostiene che (si veda [3]): A lot of applications can be rewritten to hide the fact that you break your connection and re-establish it, but it makes things unnecessarily complex and more expensive. The Internet is increasingly a platform for connecting mobile 7

8 users with the cloud and the Internet was not designed to do that [...] All the work that goes into shoehorning that into the old network architecture is very dicult Il concetto di Servizio Gli sviluppatori di Serval, hanno deciso di astrarre il concetto di servizio al punto da far sì che, l'utente, piuttosto che connettersi ad un indirizzo IP, e di conseguenza ad un terminale ben preciso, possa invece richiedere la connessione ad uno specico servizio, senza avere diretta visibilità dell'ip. Diamo allora una denizione più rigorosa di servizio [1, p. 1]: Un servizio, corrisponde ad un gruppo di sistemi, che orono le stesse funzionalità, disaccoppiando il servizio stesso, dagli identicatori di rete. Le applicazioni, possono instaurare una comunicazione senza badare ad indirizzo IP e porto. In altre parole: Service names identify who one communicates with, ow names identify what communication context to use, while addresses tell where to direct the communication. 8

9 1.3 Service Access Layer (SAL) Il cuore di Serval, è il Service Access Layer (di qui in poi SAL), che viene introdotto nello stack TCP/IP tra il livello rete e il livello trasporto. Lo scopo del SAL, è quello di realizzare l'astrazione di cui sopra e di mappare l'identicatore del servizio all'indirizzo IP corrispondente, mediante una service table, similmente a quel che avviene nel livello rete per le forwarding table. Tutto ciò senza nessuna ulteriore modica allo stack TCP/IP e senza che siano necessari ulteriori apparecchi di rete. Figura 1: Lo stack TCP/IP con e senza Serval. [1, Fig. 1] Installazione del SAL Il SAL, viene integrato all'interno del sistema operativo, mediante un modulo del Kernel Linux e/o Android, (in futuro gli sviluppatori prevedono di rendere il tutto compatibile con tutti i SO Unix-based nonché con i sistemi Windows) che può essere caricato e rimosso a tempo d'esecuzione mediante gli specici comandi da shell. Il codice sorgente necessario, può essere prelevato dall'apposita pagina del progetto su Github: Princeton-sns/Serval. Ovviamente, prima che sia possibile caricare il modulo del SAL, sarà necessario generarlo compilando il codice sorgente scaricato, mediante la tipica procedura certamente nota agli utilizzatori di un sistema operativo GNU/Linux. Per ogni dubbio, è possibile consultare la documentazione online (Serval Wiki) o i le README ed INSTALL all'interno del pacchetto contenente i sorgenti. Una volta caricato il modulo, sarà possibile far uso dei servizi messi a 9

10 disposizione da Serval ed avviare alcuni software di base (forniti all'interno dell'archivio disponibile su Github) per il testing delle funzionalità Funzionalità di base Uno degli scopi principali di Serval è quello di migliorare la mobilità delle connessioni (Mobility e Multihoming), che nell'approccio attuale risulta essere ineciente. In particolare, tramite l'astrazione realizzata dal SAL, Serval fa in modo che, non avendo le applicazioni visibilità in tutto e per tutto degli indirizzi IP, quest'ultimo possa variare senza interrompere il usso dati, nel passare da una rete all'altra o nel cambiare interfaccia di connessione. Figura 2: Mobility e multihoming. [2, Pag. 6] Oltre che per la mobilità dei client, Serval, prevede anche delle migliorie che possano invece interessare gli Internet Provider e più in generale i fornitori di servizi online. Attualmente, una architettura che prevede la distribuzione del carico di lavoro su più server, richiede l'utilizzo di terminali che si occupino di gestire le connessioni in entrata per indirizzarle in modo intelligente ad uno dei server disponibili. Tale approccio, fa sì che i load balancer, debbano gestire l'inoltro di tutti i pacchetti inviati dai client verso i server, cosa che, evidentemente, accresce la complessità ed il costo del sistema complessivo. Un simile approccio viene inoltre utilizzato per la risoluzione dei nomi tramite DNS, e di conseguenza presenta le stesse problematiche. 10

11 Figura 3: Approccio con load balancer. [2, Pag. 8] Serval gestisce tali situazioni, in modo diverso e sicuramente più eciente, e lo fa tramite i cosiddétti service routers, dei terminali che si occupano di instaurare il collegamento al servizio su richiesta del client, mediante un apposito pacchetto. Il traco successivamente generato, viaggia invece direttamente tra gli host implicati nella comunicazione (dierentemente da quando accade in presenza dei load balancer, che rischiano invece di essere sovraccaricati). Michael J.Freedman, spiega infatti che (si veda [4]): One can think of this as an overlay, but really, it means there is some software running on machines that act as service routers (much like DNS resolvers/nameservers or DHCP servers [...] These are only 'on-path' for the rst packet of each ow, unlike today's load balancers, which must be on-path for each packet. Inne, altra interessante miglioria, che potrebbe interessare in particolar modo i servizi di Cloud riguarda la migrazione delle macchine virtuali. Attualmente, qualora una organizzazione in possesso di diversi server, su ognuno dei quali sono in funzione più VM, abbia necessità di trasferirne una o più da un terminale ad un altro, dovrà necessariamente sospendere la comunicazione con i client che stavano interfacciandosi con la macchina in questione. 11

12 Figura 4: Migrazione VM tra diversi host. [2, Pag. 9] Tale inconveniente, potrebbe essere evitato se fosse possibile migrare le connessioni dei client implicati, verso altre VM. Ed è proprio in tal modo che Serval conta di risolvere tale problematica, oltre che riuscendo a diminuire il tempo di interruzione del servizio durante la migrazione della macchina. 12

13 2 Ripensare lo stack TCP/IP Le problematiche dello stack TCP/IP odierno, derivano prevalentemente dal fatto che, i concetti di indirizzo IP e porta, siano sovraccaricati dei più svariati signicati. Dierentemente, Serval, separa in modo netto il servizio dal usso dati corrispondente (relativo ad una specica socket) e dall'indirizzo di rete (che identica l'interfaccia dell'host). Di seguito sono riportati, per vari livelli dello stack, i cambiamenti che hanno luogo all'interno di quest'ultimi quando Serval è in funzione. Per maggiori informazioni, si veda [1, p. 2]. 2.1 Livello Applicazione Ad oggi, il livello applicativo, presenta le seguenti limitazioni: Indirizzo IP e port number, identicano solo in modo implicito il nome del servizio, che deve essere eventualmente risolto generando ulteriore traco (ad esempio tramite DNS), prima che la connessione possa aver luogo (early-binding). Le applicazioni utilizzano meccanismi di caching per velocizzare la risoluzione dei nomi, tuttavia, possono creare rallentamenti in caso di fallimento. Ogni socket, può essere legata al più ad un unico, immodicabile, indirizzo. In presenza del SAL, la necessità, all'interno delle applicazioni, di implementare alcuni meccanismi di risoluzione e di ottimizzazione della gestione del traco di rete, possono essere evitati o resi superui. In particolare, in termini di livello applicativo, l'introduzione del SAL comporta le seguenti migliorie: Grazie al concetto di servizio, attraverso il quale fa sì che l'ip sia trasparente alle applicazioni, è possibile risolvere l'indirizzo di rete, direttamente quando si instaura l'eettiva connessione tra gli host (late-binding). Tale questione è trattata in modo più approfondito nel paragrafo 4.1. In presenza di load balancer (ed eventualmente di NAT), la connessione può essere stabilita mediante l'invio di uno specico pacchetto (anycast-forwarded), senza che il restante traco debba attraversare il load balancer stesso. 13

14 2.2 Livello Trasporto Lo stack TCP/IP, a livello trasporto, fa uso della classica quintupla di elementi, formata da: IP mittente, porta mittente, IP destinatario, porta destinatario, protocollo. Tali informazioni, risultano necessarie per il demultiplexing dei pacchetti. In conseguenza di ciò, accade che: L'IP non può cambiare senza che le connessioni in corso siano interrotte; Le possibilità di mobilità e migrazione, sono pressoché nulle. Ad oggi, esistono diverse proposte per quanto riguarda l'integrazione della mobilità e del multihoming in TCP, ma nessuna ricopre tutti i possibili scenari in modo soddisfacente. Alcune soluzioni, prevedono che gli IP nella quintupla sopracitata possano cambiare dinamicamente, altre sostituiscono agli indirizzi altri identicatori, ma nessuna di queste soluzioni è in grado di supportare, oltre che TCP, altri protocolli di livello trasporto. Dierentemente, Serval, risolve il problema alla base, facendo sì che i protocolli di trasporto non si occupino del demultiplexing dei pacchetti, il quale ha luogo invece nel SAL grazie agli identicatori di servizio (serviceid) e di usso (owid). Così facendo, gli indirizzi di rete sono liberi di cambiare, e poiché il controllo del usso dati è relegato al SAL, tale soluzione può essere adottata con diversi protocolli di trasporto. 2.3 Livello Rete Dal momento che il SAL è posizionato al di sopra del livello rete, l'inoltro dei pacchetti, avviene così come previsto dal protocollo IP mediante una gestione gerarchica degli indirizzi. 14

15 3 Astrazione dei servizi e dei ussi 3.1 Service Naming Ogni servizio, è rappresentato da un nome di facile memorizzazione per gli utenti, e da un identicatore, che viene invece utilizzato dai dispositivi di rete e dai terminali, comunemente detto serviceid. Le istanze del servizio corrispondente, si aspettano dunque di ricevere in ingresso connessioni per quello specico identicatore, nascondendo ai client indirizzi e porti, garantendo dunque una certa essibilità. Seguendo la schematizzazione vista su [1, p. 3.1], è possibile discutere le seguenti caratteristiche: Granularità: Il concetto di servizio, realizza un'astrazione tale da nascondere l'eettiva tipologia del sistema complessivo, ad esempio: un service name può indierentemente rappresentare un singolo demone, un cluster di stampanti, un insieme di peer che distribuiscono lo stesso le o un normale servizio online distribuito su più macchine. In sostanza, la granularità del servizio è estranea ai client. Formato dell'identicatore: Di fondamentale importanza è la questione del naming. È necessario infatti, stabilire le dimensioni dei serviceid e decidere come questi debbano essere memorizzati. Gli sviluppatori di Serval, suggeriscono una soluzione che preveda un namespace di 256 bit, gestito eventualmente da autorità che si occupino della memorizzazione ed eventualmente di una suddivisione in blocchi, in base a dei pressi rappresentativi di speciche entità. È possibile in tal modo, adoperare una risoluzione gerarchica dei servizi, specialmente per quelle realtà che ne orono molteplici. Sicurezza e registrazione: Dal punto di vista della sicurezza, Serval, propone l'utilizzo di una bitstring alla ne del serviceid, ottenuta mediante crittograa hash di una chiave pubblica e del presso, rappresentativi del servizio. Tale meccanismo, non richiede la presenza di infrastrutture, ma soltanto una strategia per garantire che i serviceid vengano appresi attraverso canali sicuri e che la registrazione stessa dei servizi, avvenga mediante un sistema adabile di registrazione. Ad ogni modo, da questo punto di vista, Serval non impone alcuna politica di gestione dei serviceid, lasciando libere le imprese di scegliere come eettuare le registrazioni all'interno della propria rete. Tuttavia, va specicato che tali misure di sicurezza, non bastano ad assicurare che l'hoster del servizio sia autorizzato. Memorizzazione dei nomi: Anche per quanto riguarda questo aspetto, non vi è alcuna imposizione. Serval non si occupa di gestire 15

16 il mapping tra serviceid e service name, lasciando che sia l'utente a decidere come associare ad un identicatore un nome che possa essere facilmente memorizzato, mediante gli più svariati meccanismi (come accade ad esempio per DNS). 3.2 Flow Naming Serval fornisce un sistema di naming per il usso dati di una specica connessione, basato sul owid. Tramite tale identicatore, il SAL può eettuare il demultiplexing dei pacchetti, senza aver bisogno della classica quintupla di elementi di cui si è discusso nel paragrafo 3.2. In denitiva, il serviceid e il owid rappresentano tutto ciò che è necessario per l'inoltro dei pacchetti. Tali informazioni, vengono trasportate all'interno di uno specico header, posizionato tra quello del livello rete e quello del livello trasporto, come da immagine. Figura 5: Identicatori di Serval all'interno di un pacchetto (alcuni campi sono stati omessi per una migliore leggibilità). [1, Fig. 2] Possiamo quindi concludere che, come spiegato in [1, p. 3.2], Serval, tramite i suoi identicativi, implementa: Mobilità e multi-path: attraverso eventi che possano modicare l'interfaccia corrispondente ad un owid, o associando ad un'unica interfaccia più ussi che attraversino percorsi diversi. Inconsapevolezza del livello rete: i ussi dati sono identicati pur senza conoscere gli indirizzi IP corrispondenti, cosa che permette a Serval, di supportare indierentemente IPv4 e IPv6. Migrazione in presenza di NAT: un NAT consapevole della presenza del SAL, sostituisce l'indirizzo IP mittente, con l'ip pubblico (come di consueto) e il owid, unica informazione necessaria a destinazione per l'identicazione del usso dati corrispondente. In questo modo, può passare da una rete provvista di NAT all'altra, senza alcuna preoccupazione. 16

17 Sicurezza: dal momento che i owid possono essere generati casualmente, un identicatore sucientemente lungo, dovrebbe servire a proteggere da eventuali malintenzionati. Tuttavia, un owid troppo lungo, potrebbe generare un overhead eccessivo: per tale motivo, Serval adotta un owid di 32 bit più dei nonces che sono scambiati soltanto durante il setup della connessione e durante eventuali migrazioni. Port number non richiesto: il numero di porta, spesso identica anche il protocollo utilizzato per il usso dati verso l'applicazione (si pensi ad esempio al fatto che, il porto 80, è generalmente associato al protocollo HTTP). Il owid, invece, non tiene in alcun modo memoria del protocollo utilizzato, che può essere eventualmente specicato all'interno dell'apposito campo nel transport-header. 17

18 4 Inoltro dei pacchetti nello stack Serval Vedremo, nei paragra successivi, come Serval gestisce l'inoltro e il demultiplexing dei pacchetti all'interno delle reti, mediante i seguenti approcci e componenti: Scissione del control plane dal data plane; Service-controller, una componente che si occupa della risoluzione dei servizi, della gestione di particolari eventi, della comunicazione con gli altri controller; Service table che realizzano il mapping tra serviceid ed indirizzi di rete; Flow table che realizzano il mapping tra owid e socket; Meccanismi di comunicazione e segnalazione per la gestione di particolari eventi; Active socket per l'interazione tra le applicazioni. Figura 6: Stack Serval con le varie componenti che partecipano all'inoltro e alla gestione del traco. [1, Fig. 3] 18

19 4.1 Active Socket Le Active Socket, così come le socket BSD, su cui sono basate, vengono utilizzate per il passaggio dei dati da e verso le applicazioni, realizzando un'astrazione di un canale di comunicazione. Tali socket, si dierenziano da quelle classiche, per via del fatto che, le funzioni normalmente utilizzate per la gestione delle connessioni, hanno tra i parametri il serviceid, invece che gli indirizzi IP e il porto. Mediante un meccanismo di segnalazione eventi (si veda 4.4), Serval gestisce automaticamente la registrazione/deregistrazione dei servizi, quando vengono eseguite speciche operazioni sulle socket. Tipiche funzioni sono ad esempio: bind(): associa un indirizzo e un porto ad una socket (nel caso di Serval fa uso invece di un serviceid), su cui ci si pone in ascolto (l'evento generato da una chiamata alla funzione bind, causa una registrazione all'interno della service table che viene noticata al service-controller). close(): chiude la socket (causa una deregistrazione all'interno della service table che viene noticata al service-controller). connect(): chiamata utilizzata dai client per connettersi ad una speci- ca socket. accept(): accetta la prima connessione in coda. sendto(): invia i dati verso la specica destinazione. Figura 7: Dierenze d'utilizzo delle socket BSD classiche rispetto a quelle modicate da Serval per il funzionamento tramite serviceid. [1, Tab. 1] 19

20 Le applicazioni che fanno uso di tali funzioni, di conseguenza, non hanno visibilità dell'indirizzo di rete (dal momento che è il SAL ad occuparsi della risoluzione del serviceid nell'indirizzo corrispondente). Questo, non solo fa sì che gli IP possano cambiare liberamente, ma consente anche di eettuare il late binding, ovvero di mappare l'identicatore del servizio sul corrispondente indirizzo, solo all'atto di una connetct() o di una sendto(). 4.2 Forwarding e data plane L'instaurazione di una nuova connessione, mediante l'invio di uno specico pacchetto, comporta che venga eettuata una ricerca all'interno della service table dello specico serviceid contenuto all'interno dell'header Serval, mediante LPM (longest prex matching). Vari servizi infatti, possono avere lo stesso presso, poiché appartenenti alla stessa entità. Come è possibile notare guardando la Figura 6, la service table è composta da 3 campi, di cui il campo Action, il quale può assumere 4 diversi valori: FORWARD: viene utilizzato per l'inoltro di un pacchetto tramite il livello rete ad uno o più indirizzi. Sia il mittente, sia eventuali hop SAL intermedi o eventuali dispositivi di rete, presentano tuple all'interno della propria service table con ruolo impostato su FORWARD, contribuendo all'invio del pacchetto verso la specica destinazione. Tali hop, si comportano eettivamente come fossero dei service router. DEMUX: è il ruolo presente nella service table del destinatario, per poter smistare i pacchetti ricevuti verso la socket presso la quale la specica applicazione è in ascolto per quel serviceid. Una chiamata alla funzione bind() (si veda 4.1) fa sì che all'interno della service table, venga aggiunta una nuova voce con ruolo DEMUX per quel servizio, viceversa, una chiamata alla funzione close(), causa l'eliminazione della stessa. Figura 8: Aggiunta e rimozione di un ruolo DEMUX nella service table per il servizio X. [2, Pag ] 20

21 DELAY: un pacchetto il cui serviceid trova nella service table in sua corrispondenza una action DELAY, viene messo in coda ed una notica viene inviata al service controller. Tale ruolo, viene ad esempio utilizzato per una risoluzione ritardata (si veda 4.3). DROP: utilizzato semplicemente per scartare i pacchetti per uno speci- co servizio. Va specicato che, di default, ogni volta che un interfaccia si connette alla rete, un ruolo FORWARD viene inserito nella service table, cui corrisponde l'indirizzo di broadcast per l'interfaccia. Di seguito è illustrato un esempio di come avviene l'inoltro di un pacchetto: Figura 9: Inoltro di un pacchetto tra due terminali attraverso un service router intermedio. [1, Fig. 4] 1. Un client stabilisce una connessione per il servizio X, per il quale è presente nella service table un ruolo FORWARD verso il nodo b. 2. Il nodo intermedio, riceve il pacchetto; per lo specico serviceid ha nella sua service table un ruolo FORWARD. Il pacchetto viene dunque inoltrato verso il nodo g. 3. A destinazione, un ruolo DEMUX smista il pacchetto verso la socket sulla quale l'applicazione è in ascolto. Un esempio più complesso, è mostrato in Figura 10. Nell'esempio, un client richiede di poter usufruire di un servizio X, disponibile su due diversi server, allora il SAL assegna un owid ed un nonce generato casualmente (per proteggere da eventuali attacchi) alla socket corrispondente, ed una nuova tupla è aggiunta alla ow table. 21

22 Figura 10: Connessione ad un servizio X da parte del client a, tramite inoltro del pacchetto SYN. I ruoli indicato con ' * ' sono quelli di default. [1, Fig. 5] 1. Il SAL del client, cerca il serviceid all'interno della service table, ed inoltra la richiesta verso il nodo b (indicato come indirizzo per il ruolo FORWARD di default). 2. Il SR (service router) b, trova all'interno della propria service table, un ruolo FORWARD verso un ulteriore nodo, detto e. Reinoltra dunque il pacchetto sovrascrivendo l'indirizzo destinazione. 3. Il forwarding del pacchetto continua ricorsivamente attraverso il nodo e ed altri, nché non raggiunge il terminale g in ascolto sulla socket. 4. Il nodo g, crea quindi una nuova socket da utilizzare per l'invio della risposta al pacchetto SYN ricevuto, aggiornando la propria ow table. 5. Il pacchetto SYN-ACK generato da g, contiene il suo indirizzo di rete, il owid ed il nonce. Tale pacchetto, e tutti quelli che seguiranno, saranno scambiati in modo diretto tra i due host, senza che debbano attraversare i SR intermedi (b ed e). Va inoltre specicato, che il demultiplexing dei pacchetti successivi potrà essere eettuato pur senza l'invio del SAL header, essendo ormai noto il owid. 22

23 4.3 Service discovery e registration Al ne di poter gestire situazioni dierenti, Serval, supporta diverse modalità di registrazione e risoluzione dei servizi. Sono infatti i service controller a gestire le service table, ed eventualmente a propagarle verso altri service controller. È possibile distinguere diversi scenari: Risoluzione e routing in larga scala (wide-area): ogni qual volta una nuova istanza di un servizio è disponibile, il service controller si occupa di propagare l'informazione agli altri controller, permettendo così che il servizio possa essere raggiunto. Mediante l'utilizzo dei pressi, organizzazioni che forniscono molteplici servizi, possono organizzare i propri resolvers. Servizi nelle reti ad-hoc: essendo prive di infrastrutture di rete, le informazioni sui servizi devono essere propagate tramite ooding. Eventuali richieste vengono quindi inviate in broadcast, in attesa di risposte da istanze del servizio richiesto. Lato server, all'atto di una registrazione, il service controller può: inserire un ruolo DEMUX nella service table, propagare la registrazione agli altri controller (che potranno quindi installare nelle proprie service table un ruolo FOR- WARD). Viceversa, all'atto di una deregistrazione. Risoluzione con lookup server (on demand): come spiegato nel paragrafo 4.2, uno dei possibili ruoli per una tupla all'interno della service table, è DELAY. Tale ruolo, fa sì che i pacchetti corrispondenti al servizio, vengano messi in coda, in attesa ad esempio che il service controller si occupi della risoluzione. Una volta che tale risoluzione ha avuto luogo, i DELAY corrispondenti possono essere sostituiti con ruoli FORWARD per permettere l'inoltro dei pacchetti. Un approccio che prevede simili meccanismi, è quello con lookup server: i client interessati, inoltrano il pacchetto SYN verso il server in questione, il quale prima li mette in coda (DELAY) ed una volta eettuata la risoluzione, li inoltra (FORWARD) verso il servizio destinazione. 23

24 4.4 Meccanismi di segnalazione eventi I meccanismi di segnalazione, per la gestione di particolari eventi all'interno dello stack, sono fondamentali per garantire la essibilità e il dinamismo messi a disposizione dal SAL, in particolar modo per una corretta gestione della mobilità e della migrazione in presenza di più ussi dati. I protocolli utilizzati in Serval, si dierenziano dai classici meccanismi solitamente adottati in TCP. Prima di tutto, i messaggi di controllo viaggiano separati dai dati ed hanno un proprio sequence number, cosa che non accade ad esempio nei più comuni MPTCP e TCP Migrate, i quali possono inviare messaggi di controllo solo all'interno dei pacchetti dati, inoltre diversi protocolli di trasporto sono supportati grazie alla presenza del SAL che gestisce i ussi dati ad un livello più basso, e per lo stesso motivo migrazione e ussi multipli sono ammissibili. Per maggiori informazioni si veda [1, p. 4.4]. Per meglio illustrare le possibilità messe a disposizione da Serval, in termini di multihoming, multipath e migrazione, si faccia riferimento all'esempio riportato nella gura sottostante: Figura 11: Esempio di comunicazione multipath (con possibilità di migrazione) in presenza di terminali multihomed. [1, Fig. 6] Multipath e multihoming: in presenza di diverse interfacce di rete, possono essere instaurati più ussi dati lungo percorsi diversi. Si faccia riferimento all'esempio di Figura 11: i due host, posseggono ambedue una coppia di interfacce (a1 e a2 per il client Host C, a3 e a4 per server Host S). Il primo usso viene instaurato quando il client richiede di connettersi, usando ad esempio l'interfaccia a1 con owid fc1, che lato server corrispondono all'interfaccia a3 con owid fs1. Ogni qual volta viene inviato un pacchetto, all'interno del SAL extension header, gli host possono indicare eventuali altre interfacce disponibili per la connessione per dare la possibilità di creare più ussi dati. In questo caso ad esempio, qualora Host S lo segnali ad Host C, quest'ultimo potrebbe decidere di instaurare una nuova connessione tra le interfacce a2 e a4. 24

25 Migrazione: essendo il livello trasporto ignaro della gestione del owid da parte del SAL, è possibile migrare ussi dati da una interfaccia all'altra, su percorsi diversi o verso un altro indirizzo. Ovviamente, eventuali migrazioni possono inuire sulle prestazioni, e ridurre la banda a disposizione per il trasferimento dati. Per questo motivo, il SAL può noticare a livello trasporto l'avvio di una migrazione, così che questa possa essere gestita in modo adeguato. Facendo riferimento all'esempio di Figura 11, immaginiamo che improvvisamente l'interfaccia a3 del server smetta di funzionare. Per non interrompere la connessione, il server può migrare il usso dati su un'altra interfaccia, ad esempio a4. Tale migrazione avviene mediante l'invio da parte del server, di un pacchetto di risincronizzazione detto RSYN, contenente i owid della connessione corrente (fc1 e fs1) nonché l'indirizzo della nuova interfaccia (a4). Il client invia quindi un RSYN-ACK per noticare al server il proprio assenso alla migrazione, ed attende un ulteriore conferma da parte di quest'ultimo. La presenza di un sequence number all'interno dei pacchetti di sincronizzazione, assicura che questa vada a buon ne anche nel caso in cui arrivino fuori ordine (eventualità rara ma possibile). 25

26 5 Prototipo dell'architettura Attraverso la prototipazione dell'architettura, gli sviluppatori, si sono resi conto man mano di quelle che sono le potenzialità di Serval e i beneci che può apportare in termini di dinamicità, prestazioni e quant'altro. Attualmente, il prototipo disponibile, supporta: migrazione, SAL forwarding (comprensivo di service table con ruoli FORWARD e DEMUX, risoluzione dei servizi e meccanismi di segnalazione) ed altre funzionalità. Tuttavia, non è ancora possibile far uso del multi-path, che gli sviluppatori progettano di aggiungere in futuro. Inoltre, la presenza del service controller (che interagisce a sua volta con lo stack mediante una particolare socket), permette una gestione dinamica delle service table in presenza delle chiamate a funzioni bind(), connect() etc. Attualmente sono supportati i protocolli di livello trasporto TCP e UDP. Per maggiori informazioni su come Serval sia giunto all'architettura attuale attraverso le varie prototipazioni susseguitesi, si veda [1, p. 5.1]. 5.1 Benchmark performance Gli sviluppatori di Serval, si sono preoccupati dell'esecuzione di alcuni test che mostrassero in termini di throughput, pacchetti inviati, data loss, deviazione standard, le prestazioni di uno stack modicato dal SAL, rispetto ad un classico TCP/IP. Figura 12: Statistiche di confronto tra connessioni tramite stack TCP/IP nativo e con SAL. [1, Tab. 2] I dati mostrati, sono relativi a test di 10 secondi, eseguiti mediante tool iperf su macchine con 2 CPU Intel 2.4GHz ed interfaccia GigE con sistema operativo Ubuntu Si consideri nel valutare i risultati ottenuti da Serval, che alcune ottimizzazioni non sono ancora implementate. Sono inoltre riportati nella tabella in Figura 12, i risultati in presenza di un translator, ovvero una componente che si occupa del rendere possibile una comunicazione tra host che implementano l'architettura Serval ed host che fanno uso del classico stack TCP/IP (si veda il paragrafo 7). 26

27 La seconda parte della tabella in Figura 12, mostra i risultati ottenuti nell'inoltro di alcuni pacchetti con payload da 48 byte gestiti dal SAL, rispetto ad altri inviati con l'approccio attuale previsto da IP. Gli sviluppatori condano di poter colmare il divario presente, specialmente in termini di packet-rate, con le future ottimizzazioni. 6 Casi di studio Per dimostrare l'ecacia di Serval in una serie di casi possibili, gli sviluppatori hanno realizzato dei test su sistemi realmente funzionanti, di svariati tipi. Di seguito sono riportati i risultati ed una serie di considerazioni derivanti da tali test, per diversi utilizzi di Serval in ambito server. 6.1 Web Service replicato con load balancing In questo esperimento, si fa uso di un web-cluster con architettura Serval, per mostrare i vantaggi che quest'ultimo può apportare all'interno di una simile architettura. Supponiamo, che 4 client invino richieste verso il web service, il quale gira su diverse istanze di un web server Mongoose. Tutti gli host, sono connessi allo stesso switch di rete ToR GigE. Il load balancing, è a carico di un singolo service router, che si occupa della risoluzione delle richieste. Per illustrare i risultati ottenuti, si faccia riferimento alla seguente immagine, considerando che ogni client richiede un le di 3MB su una nestra di 20 richieste HTTP, al ne di saturare la banda a disposizione. Figura 13: Relazione tra request rate e throughput in presenza di più istanze di servizio. [1, Fig. 7] 27

28 Distinguiamo situazioni dierenti, in base alle istanze del servizio disponibili, in particolare: 0-60 secondi: due istante di servizio servono un totale di 80 richieste al secondo (20 per client), raggiungendo un throughput di circa 1.8Gbps; secondi: dopo 60 secondi, due nuove istanze di servizio si registrano presso il service router, ed iniziano a servire richieste. Si ottiene così un request rate di 160 req/s ed un throughput di circa 3.6Gbps; secondi: le prime due istanze di servizio, vengono stoppate. Dunque, eseguono la deregistrazione e servono le ultime richieste pendenti. I risultati ottenuti in termini di request rate e throughput sono comparabili a quelli ottenuti nei primi 60 secondi (avendo lo stesso numero di istanze attive); secondi: una terza istanza viene avviata su uno dei server disponibili, ottenendo così migliori prestazioni (120 req/s e 2.7Gbps). Dall'esperimento si capisce dunque, come Serval sia in grado di gestire senza l'uso di un costoso load balancer, un notevole carico di richieste riuscendo a distribuirle in modo adeguato sui server disponibili ed ottenendo ottimi risultati in termini di throughput e request rate (tali da saturare la banda disponibile). Il tutto, ricordando che il service router, non è altro che un nodo coinvolto nella sola registrazione e risoluzione dei servizi (attraversato unicamente dal primo pacchetto di una connessione e non dall'interno traco generato dal trasferimento dei dati). 6.2 Storage distribuito Si illustra di seguito, l'impiego di Serval in un sistema di storage basato su Memcached. Memcached fornisce un servizio di caching, basato sull'utilizzo di alcune chiavi, tramite le quali un algoritmo di risoluzione, fa corrispondere speciche partizioni distribuite su più server. Tramite una mappa, il client può individuare il server contenente la partizione di interesse, ed inviare ad esso le sue richieste. Tuttavia, la staticità di questo approccio, complica la gestione dei server quando se ne vogliano aggiungere o sottrarre, o nel caso in cui si voglia ripartizionare lo spazio. Con Serval, il mapping delle partizione può avvenire dinamicamente: i client possono inoltrare le proprie richieste al service router indicando un serviceid con presso comune a Memcached, seguito dalla chiave del contenuto. Il mapping tra il serviceid e la partizione corrispondente alla chiave, avviene mediante LPM nella service table. Le richieste possono quindi essere 28

29 inoltrate verso il server, il quale di qui in poi, comunicherà in modo diretto col client. Nel caso in cui un nuovo server si registri alla rete, le partizioni possono essere semplicemente riassegnate modicando la service table, tuttavia, con tale approccio, non avendo i client visibilità diretta del server (ma solo del servizio) non possono aggregare richieste (si richiede che sia il service router ad occuparsene). L'immagine sottostante, riporta i risultati ottenuti per l'esperimento, in presenza di 4 server ed un client (con un service router intermedio). Il client ed il service router sono su macchine con le stesse speciche indicate per i benchmark del paragrafo 5.1, mentre i server hanno le seguenti speciche: due CPU AMD Opteron 2.4GHz quad-core con interfaccia GigE. Il service router, assegna un totale di 16 partizioni (4 per ogni server), le cui chiavi sono codicate sugli ultimi 4 bit del presso del serviceid. Figura 14: Gestione Serval delle partizioni sotto Memcached, in presenza di 4 server. [1, Fig. 8] Anche in questo caso, come nell'esperimento precedente, distinguiamo diverse situazioni in base ai server disponibili nei vari intervalli di tempo: 0-10 secondi: inizialmente, tutti i server sono in funzione; secondi: dopo circa 10 secondi, un server viene rimosso (server 3) ed il service router ridistribuisce le 4 partizioni del server rimosso tra quelli rimanenti; secondi: dopo 20 secondi, un altro server viene rimosso (server 2) e le partizioni corrispondenti distribuite sui due server rimanenti; 29

30 30-40 secondi: il server 3, si registra nuovamente alla rete dopo circa 30 secondi, il carico dovuto alla gestione delle partizioni viene ridistribuito; secondi: il server 4 si registra nuovamente, e si torna alla situazione iniziale. 6.3 Migrazione ussi e macchine virtuali Nel seguito, sono illustrati in breve, esperimenti che mostrano come Serval possa gestire la migrazione di ussi dati su diverse interfacce, o di vere e proprie macchine virtuali, situazione particolarmente di interesse ad esempio per i servizi di cloud. Nel primo caso, abbiamo un server (sul quale è lanciato iperf) con due interfacce di rete GigE, che serve due client. Tali interfacce, possono garantire una velocità a piena banda, di 1Gbps. Figura 15: Miglioramenti in termini di throughput dovuti alla migrazione del usso dati del secondo client sulla seconda interfaccia. [1, Fig. 9] Inizialmente, i ussi di entrambi i client sono diretti verso un'unica interfaccia server, raggiungendo una velocità di circa 500Mbps (e dunque in totale di 1Gbps). Dopo 6 secondi, il service controller segnala al SAL di voler migrare uno dei ussi sulla seconda interfaccia. Trascorso un breve periodo, necessario per l'assestamento della velocità di trasmissione, entrambi i client ottengono una velocità pari a 1Gbps (2Gbps totali), raddoppiando dunque il throughput rispetto alla situazione iniziale. 30

31 Un possibile uso della migrazione oerta da Serval, utile in particolar modo a fornitori di servizi cloud, è quello in cui una macchina virtuale, debba essere trasferita da un host all'altro senza una interruzione del usso dati. Figura 16: Flusso dati, in presenza di una migrazione. [1, Fig. 10] Come l'immagine suggerisce, il usso dati subisce un lieve rallentamento ed una breve interruzione, nel periodo in cui un nuovo indirizzo di rete viene assegnato alla macchina virtuale, e mentre viene eettuata la risincronizzazione. 31

32 7 Translator per compatibilità con host legacy L'integrazione di Serval all'interno dello stack TCP/IP, risulta essere piuttosto semplice, tuttavia, per ovvi motivi, è necessario garantire compatibilità anche con host che presentano uno stack privo del SAL. Per questo motivo, sono stati sviluppati dei translators, attraverso i quali è possibile risolvere tale problematica. In particolar modo, il translator TCP-to-Serval, può tradurre una normale connessione basata su TCP (senza SAL), in una connessione adatta ad essere gestita da uno stack Serval. Un translator Serval-to-TCP, eettua invece l'operazione inversa. [1, p. 7] - [5, p. 3.1] TCP-to-Serval (lato client): per poter eettuare la traduzione, il translator (che in questo caso è un middlebox lato client) ha bisogno di conoscere quale servizio il client desidera utilizzare, e di ricevere i pacchetti relativi al usso dati associato. Il translator, agisce non molto dierentemente da un recursive DNS, utilizzando i nomi dei domini cui il client desidera connettersi, come nomi del servizio richiesto. Il translator, mappa quindi tali nomi su un indirizzo IP privato. TCP-to-Serval (lato server): alcune grandi organizzazioni, che permettono la fruizione di una molteplicità di servizi, potrebbero pensare di implementare un proprio translator, presso i propri PoP (Points of presence). Tale approccio, prevede una architettura siatta: Figura 17: Comunicazione client-server mediante translator lato server. Solo il primo pacchetto attraversa il service router, i restanti solo il translator. [5, Fig. 2] In una situazione simile, il client ovviamente non conosce il serviceid, ma piuttosto risolve tramite DNS l'indirizzo IP di una specica macchina. Ogni server che permette l'utilizzo del servizio è associato ad un IP pubblico e ad una porta. Tuttavia, l'ip che il client scopre, non 32

33 corrisponde ad una delle macchine del servizio, bensì al translator. Quest'ultimo, riceve dunque tutto il traco generato dalle richieste dei client, e tramite una tabella mappa l'ip e la porta richiesti dal client sul corretto serviceid, come mostrato nell'immagine sottostante. Figura 18: Tabella per il mapping di IP e porta sul corretto serviceid. [5, Fig. 1] Riconosciuto il serviceid corretto, il translator, invia una richiesta di connessione mediante Serval, al service router della rete. Il service router a sua volta, decide per quale server della rete stabilire la connessione. Una volta stabilita la connessione, i pacchetti successivi, potranno essere trasferiti senza attraversare il service router, mentre dovranno sempre essere gestiti dal translator, il quale mantiene una connessione classica verso il client ed una basata su Serval, verso il server che fornisce il servizio. Per le strategie di realizzazione di un translator, si veda [5, p. 4]. Serval-to-TCP/UDP: un translator di questo tipo, funziona in modo molto simile a quanto visto per il TCP-to-Serval. È piuttosto interessante valutare la possibilità di utilizzare una coppia di translator in serie, al ne di poter usufruire delle funzionalità messe a disposizione da uno stack Serval, ad esempio: si immagini un client privo di SAL, che stabilisca una connessione verso una specica destinazione. I pacchetti inviati, attraversano prima un translator TCP-to-Serval e poi un translator Serval-to-TCP, al ne di inoltrare a destinazione pacchetti mediante una connessione legacy. Così facendo, pur essendo il client un dispositivo non modicato, potrà usufruire dei vantaggi tipici dell'architettura Serval, grazie alla presenza dei translator. 33

34 8 Dimostrazioni e test di funzionamento Di seguito, sono riportati alcuni esempi e test dimostrativi eettuati, al ne di mostrare il funzionamento di Serval in alcuni scenari d'uso comune. Tutte le istruzioni riportare, fanno chiaramente riferimento a le generati tramite il processo di compilazione, primo passo da eseguire, così come accennato nel paragrafo (si consiglia ad ogni modo di far riferimento alla pagina Serval su Github e al relativo Wiki). I comandi vengono lanciati dall'interno della directory principale di Serval, comunemente chiamate servalmaster. Serval, può essere avviato in due dierenti modalità: come modulo del Kernel Linux, o in user-space. Tutti gli esempi riportati di seguito, sono stati eseguiti lanciando Serval in user-space. Avvio di Serval tramite caricamento del modulo nel Kernel: # insmod./src/stack/serval.ko Per controllare che il modulo sia stato eettivamente caricato: $ lsmod grep serval Avvio di Serval in user-space: #./src/stack/serval -i INTERFACCIA -d Una lista delle interfacce disponibili si può ottenere lanciando ifcong. L'opzione d, lancia Serval in background, come demone. Serval fornisce anche un demone (il cui uso è opzionale), detto servd, utile alla gestione degli eventi, poiché segnala registrazioni e deregistrazioni dei servizi al service router di competenza. È possibile specicare alcune opzioni per servd, creando il le /usr/local/etc/servd.conf. Per lanciare il demone: #./src/servd/servd L'opzione -rip può essere specicata per indicare esplicitamente l'ip del service router (che servd trova da solo qualora sia nella stessa sottorete, diversamente è necessario indicarlo in modo esplicito). Per maggiori informazioni, si lanci servd -h. 34

35 Una volta avviato il demone, è possibile visualizzare service e ow table, lanciando: $ telnet Figura 19: Service e ow table, visualizzate tramite telnet. Prima di iniziare, potrebbe essere utile aggiungere una entry d'esempio nella service table per il serviceid 76568: $./src/tools/serv service add IP_SERVER 8.1 Catturare pacchetti Serval con Wireshark Di base, Wireshark, noto programma per l'analisi del traco di rete, non è in grado di individuare all'interno dei pacchetti il SAL (e dunque header ed estensioni realtive). Tuttavia, è possibile istruire Wireshark anché sia in grado di individuare correttamente pacchetti Serval. Per farlo, è necessario un dissector. Un dissector non è altro che uno script, programmato in LUA, contenente le direttive necessarie per la corretta decodica di talune caratteristiche dei pacchetti nel traco di rete. Per maggiori informazioni, si veda [6]. Un dissector attraverso il quale è possibile decodicare correttamente pacchetti Serval, è stato realizzato da Isaakidis Marios (misaakidis) nell'ambito del suo progetto ServalDHT e distribuito sotto licenza GNU General Public License. Il le.lua, è disponibile tra i le del progetto sotto la directory: serval/src/serval_wireshark_dissector.lua Scaricato il le, è necessario istruire Wireshark anché ne faccia uso per la decodica dei pacchetti. Wireshark, all'avvio, carica alcuni script in base alle direttive che sono contenute nel le init.lua, dunque, per far uso del dissector, si lancino si seguenti comandi: 35

36 # cp serval_wireshark_dissector.lua /usr/share/wireshark # nano /usr/share/wireshark/init.lua Inserire alla ne del le la direttiva: dofile(data_dir.."serval_wireshark_dissector.lua") Wireshark, sarà adesso in grado di individuare il SAL. In alternativa, si faccia uso di tshark (la versione a riga di comando di Wireshark). Il comando da eseguire per catturare pacchetti Serval è il seguente: $ tshark -i INTERFACCIA -X lua_script:serval_wireshark_dissector.lua Come mostra la gura seguente, Wireshark individua correttamente il SAL. Figura 20: Pacchetto Serval individuato da Wireshark. 36

37 8.2 Invio di un le Serval, mette a disposizione una serie di semplici programmi di test, al ne di vericare il corretto funzionamento di talune funzionalità. In questo esempio, verrà mostrato come, degli host Serval, possano scambiarsi un le come se questo fosse fornito dal servizio. Si noti che, qualora i due host si trovino in sottoreti diverse, sarà necessario aggiungere nella service table, una entry che indichi presso quale indirizzo raggiungere il servizio relativo al serviceid indicato. Supponendo di voler inviare un le.jpg contenuto nella cartella Immagini di nome dark_side.jpg, lato server si lanci: $./src/test/tcp_server_user -s f /home/user/immagini/dark_side.jpg Lato client invece, si può scaricare il le mediante il seguente comando: $./src/test/tcp_client_user -s f /home/user/scrivania/serval_test.jpg Figura 21: Invio di un le tramite stack Serval. 37