Progettazione,realizzazione e test di un livello di rete ad hoc per dispositivi mobili

Università degli studi di Roma La Sapienza Facoltà di Ingegneria Relazione Finale sullo stage interno per il conseguimento della Laurea in Ingegneria Informatica Luglio 2004 Progettazione,realizzazione e test di un livello di rete ad hoc per dispositivi mobili Piergiorgio Faraglia

Università degli studi di Roma La Sapienza Facoltà di Ingegneria Relazione Finale sullo stage interno per il conseguimento della Laurea in Ingegneria Informatica Luglio 2004 Progettazione,realizzazione e test di un livello di rete ad hoc per dispositivi mobili Piergiorgio Faraglia Relatore: Ing. Massimo Mecella Correlatore: dott. Fabio De Rosa

Alla mia famiglia.

Indice 1 Introduzione 9 2 Stato dell'arte 13 2.1 Reti Wireless........................... 13 2.1.1 Tecnologie di rete wireless................ 15 2.1.2 IEEE 802.11....................... 16 2.1.3 Vantaggi di una rete wireless.............. 18 2.1.4 Problemi con le reti wireless............... 20 2.2 Reti MANET........................... 21 2.2.1 Caratteristiche delle MANET.............. 24 2.2.2 Vantaggi delle MANET................. 24 2.2.3 Problemi delle MANET................. 26 2.3 Conclusioni............................ 28 3 Analisi dei protocolli di routing 31 3.1 Protocolli di routing....................... 31 3.2 Organizzazione della rete..................... 31 3.3 Algoritmi di instradamento................... 32 3.4 Suddivisione dei protocolli di routing.............. 33 3.5 Algoritmi Proactive........................ 35 3.6 Algoritmi Reactive........................ 42 3.7 Protocolli Hybrid......................... 51 3.8 Protocollo DSR.......................... 52 3.8.1 Funzionamento generale................. 53 3.8.2 Determinazione di un percorso............. 53 3.8.3 Operazione di Route Discovery............. 53 3.8.4 Piggybacking sulla Route Discovery.......... 55 3.8.5 Route Maintenance.................... 56 3.8.6 Miglioramenti delle operazioni.............. 57 3.9 Motivazione della scelta del protocollo............. 58 7

INDICE 4 Progetto 61 4.1 Speciche del progetto...................... 61 4.2 Speciche funzionali....................... 61 4.2.1 API dell'applicazione................... 61 4.2.2 Diagram Package.................... 62 4.2.3 Sequence Diagram.................... 84 5 Test 95 5.1 Test dell'applicazione....................... 95 5.2 Descrizione dei test eettuati.................. 95 5.2.1 Dispositivi utilizzati................... 95 5.2.2 Congurazione della rete................. 96 5.2.3 Topologia della rete................... 96 5.3 Primo Test : Tuning dell'applicazione............. 98 5.3.1 Size Data 256....................... 99 5.3.2 Size Data 512....................... 100 5.3.3 Size Data 768....................... 101 5.3.4 Size Data 1024...................... 102 5.3.5 Confronto Andamenti.................. 103 5.4 Secondo Test : Robustezza dell'applicazione.......... 104 5.4.1 Prova a 2 Hop...................... 104 5.4.2 Prova a 5 Hop...................... 104 5.5 Manet Chat............................ 105 6 Conclusioni 117 A Hardware e Software 119 A.1 Congurazione dell'ambiente di sviluppo............ 119 A.2 Visual Studio.NET 2003..................... 119 A.2.1 Congurazione Microsoft LoopBack Adapter...... 121 A.3 Applicazione Smart Device................... 122 A.4 Congurazione di una MANET................. 123 B Esperimenti 133 B.0.1 Esperimenti........................ 134 C File Cong 139 C.1 Analisi dei parametri....................... 139 Bibliograa 141 8

Capitolo 1 Introduzione Negli ultimi tempi la società si sta evolvendo verso scenari dominati dalla mobilità. Tale mobilità è dettata dalla necessità di ogni persona di essere continuamente, indipendentemente dal luogo dove si trova, in comunicazione con altre persone ad essa legate da interessi di lavoro, culturali, sociali. Ognuno di noi quotidianamente si trova di fronte alla necessità di dover risolvere dei problemi pur essendo lontani sicamente dal sito dove si è vericato il problema stesso. Per rispondere a tali ed altre esigenze l'innovazione tecnologica ha prodotto i dispositivi mobili e nuove tipologie di rete. In particolare, l'attenzione è stata rivolta alle reti MANET (Mobile Ad hoc Network) reti in cui non esiste alcun tipo di infrastruttura, dove non è necessario avere sistemi centralizzati per permettere la comunicazione tra dispositivi mobili. Le MANET sono un sistema di comunicazione dati, basato su trasmissioni radio nelle quali i dispositivi comunicano esclusivamente su canali wireless. Tali reti sono reti temporanee, senza punti di accesso, che non devono essere precongurate, ma si formano per la sola presenza dei dispositivi in un dato territorio. Per la loro natura le reti ad hoc sono la soluzione ideale per tutti quei casi in cui le infrastrutture di comunicazione esistenti non sono disponibili, non sono adabili o più semplicemente troppo costose da utilizzare. Le possibili applicazioni, che destano più interesse nell'ambito della ricerca vanno dal campo militare, alle applicazioni di business, per arrivare alle applicazioni in caso di atto terroristico o di disastro naturale. Per queste tipologie di applicazioni si vengono a creare innumerevoli problemi, che vanno dall'interconnessione delle reti MANET con la rete ssa (mediante collegamenti che potranno avvenire solo attraverso satelliti o mediante collegamenti cellulari) all'aspetto più importante, che presenta una sda per la ricerca, che è la mancanza, ad oggi, di applicazioni su reti ad hoc che permettano di eseguire routing tra dispositivi mobili. La seguente tesi si colloca all'interno del progetto MAIS (Multi-channel 9

Introduzione Adaptative Information System), 1 e si propone di sviluppare un protocollo di rete, in particolare uno strato di rete, che permetta la comunicazione all'interno di una rete MANET tra vari dispositivi mobili. L'applicazione pertanto mette a disposizione una API (Application Programming Interfaces), atta a gestire l'instradamento dei messaggi, determinando se e quali dispositivi intermedi devono essere attraversati. L'idea è di avere tra le mani un software che sia in grado di fare in modo che i dispositivi che lo utilizzano possano creare una MANET, e riuscire tranquillamente a comunicare con gli elementi esistenti nella rete, senza preoccuparsi dei problemi relativi al range trasmissivo. In particolare è stata sviluppata una API, che ore le seguenti sei operazioni: Bind, Close, IsLinked, Receive, Release e Send. Il progetto nale, realizzato in collaborazione con l'ing. Fiammetta Pascucci [7], permetterà ai suoi fruitori di avere un software capace di permettere la comunicazione tra dispositivi mobili utilizzando una rete ad hoc. Lo strato di rete oerto prende corpo dall'implementazione di un protocollo di routing per reti MANET di tipo Reactive, denominato DSR Dynamic Source Routing. La scelta di esso deriva dal fatto che: prima cosa appartiene alla famiglia dei protocolli Reactive quindi in una rete MANET l'idea della creazione di percorsi solo On-Demand è sicuramente più attuabile rispetto ad un continuo scambio di informazioni ad intervalli di tempo ssati. Inoltre il protocollo DSR è sembrato quello più appropriato per una rete dove i dispositivi che la compongono sono all'incirca cinquanta e per i nostri scopi, ovvero una rete composta al massimo di pochi dispositivi (circa venti), è sembrato quello che più si adattava meglio a queste esigenze. Le dicoltà incontrate, durante la realizzazione di questo progetto sono state innumerevoli, a partire dalla poca documentazione associata all'infrastruttura delle reti ad hoc e ai rispettivi protocolli di routing. Inoltre, poichè questi argomenti sono di attuale ricerca, non esistono tutt'oggi dei riferimenti in letteratura che possano ritenersi esaustivi. Lo schema della tesi è il seguente: nel Capitolo 2 vengono esplicate le reti wireless; in particolare vengono descritti alcuni concetti base del loro funzionamento, nonché gli standards attualmente in uso mettendo in evidenza quale sono i vantaggi e gli svantaggi nel loro utilizzo. Inoltre viene descritto accuratamente cos'è una rete ad hoc, mostrando uno scenario del loro utilizzo; nel Capitolo 3 vengono descritte le tre classi di protocolli di routing Proactive, Reactive e Hybrid, spiegando la motivazione per cui tra tutti gli algoritmi visionati si è scelto di implementare il protocollo Reactive DSR (Dynamic Source Routing); 1 E' un progetto di ricerca Italiano, sviluppato congiuntamente da oltre 10 Univesità e diverse industrie. Per maggiori riferimenti:http://black.elet.polimi.it/mais/index.php. 10

nel Capitolo 4 viene fornita un'ampia e dettagliata descrizione della metodologia adottata nella realizzazione del progetto e mostrati tutti i diagrammi relativi allo sviluppo dell'applicazione; nel Capitolo 5 vengono riportati quelli che sono stati i test eettuati sull'applicazione e anche un possibile scenario di utilizzo; il capitolo 6 è relativo alle conclusioni; Appendice Hardware e Software, in cui si descrivono tutti i passi per impostare una rete ad hoc; Appendice Esperimenti, in cui sono riportate quattro delle più salienti esperienze eettuate per determinare l'assenza del routing nelle reti ad hoc realizzate con la tecnologia Wi-FI. File Cong, illustazione dei parametri presenti nel le di congurazione del protocollo di routing. Ringrazio Fiamma, perchè in questi anni mi è stata molto vicina e mi ha aiutato a superare tutti i momenti dicili, dandomi sempre tanti consigli e la forza per arontare tutti gli ostacoli. Un altro ringraziamento è per la mia famiglia, perchè non mi ha fatto mai mancare niente e perchè ha sempre creduto in me. Un grazie anche al prof.mecella, per la costanza e la pazienza con la quale in questi mesi ci ha seguito, permettendoci di ottenere grandi risultati. 11

Capitolo 2 Stato dell'arte In questo capitolo viene presentata una panoramica delle reti wireless denominate WLAN (Wireless LAN); in particolare vengono descritti alcuni vantaggi e svantaggi, nonchè gli standards attualmente in uso di tale tecnologia. Inoltre viene denito il signicato di rete MANET (Mobile Ad-hoc NETwork, oppure Multi-hop Ad-hoc Network)), come pure i vantaggi nell'utilizzo di tale rete; come ultima cosa verranno illustrate le problematiche, ad oggi, nell'impiego delle reti MANET. 2.1 Reti Wireless Una rete wireless è una rete che permette la comunicazione con altri computer, senza che il collegamento dipenda da un cavo sico. Il sistema di comunicazione dati è basato principalmente su trasmissioni radio. Vengono usati segnali radio ad alta frequenza o raggi di luce infrarossa per far comunicare le apparecchiature connesse alla rete. Una rete wireless può svilupparsi come: estensione di una rete cablata, denominata wired (Rete Centralizzata); una rete che può essere creata sul momento, denominata ad hoc (Rete non-centralizzata). Rete centralizzata Nel primo caso si parla di Infrastructure Network, tale rete si basa su infrastrutture che permettono ai nodi mobili di interfacciarsi ad esempio con un'altra LAN. Il fulcro di una rete a infrastruttura è l'access Point (AP). Un AP è un 13

Stato dell'arte dispositivo di comunicazione wireless single-purpose 1 che fornisce un collegamento (un ponte) tra apparecchi predisposti per la funzionalità wireless e una rete cablata. Il compito di un AP è quello di fornire l'accesso ad apparecchi wireless sia ad Internet sia a servizi locali di rete. Un AP gestisce la rete, possedendo una ricetrasmittente radio e un'antenna; il software di gestione della rete, residente sul punto di accesso, autentica gli utenti, mantiene la sicurezza e condivide le risorse sulla rete. Come si evince dalla Figura 2.1, tutti i dispositivi coinvolti sono collegati ad un unico Access Point, il quale ore a tutti i dispositivi collegati gli stessi servizi. Tutti i dispositivi sono connessi mediante un unico Access Point Access Point Figura 2.1: Tipica congurazione di una rete wireless con uso di un solo punto di accesso 1 Letteralmente signica a scopo/utilizzo singolo, indica la poca versatilita' della componente a cui si riferisce. Spesso si usa per specicare che una data architettura e' stata concepita per un singolo scopo specico mettendo a disposizione strumenti capaci a svolgere questo compito. 14

2.1 Reti Wireless Rete non centralizzata In opposizione alla rete centralizzata, vi è la rete ad hoc (comunemente chiamata MANET- Mobile Ad-hoc NETwork). Il signicato del termine ad hoc sta proprio nella possibilità per gli utenti di avere una rete pronta per l'uso, versatile e facilmente congurabile, in cui non sono necessari gli access point o hardware dedicati. Ogni dispositivo è in grado di comunicare con altri dispositivi che si trovano nel suo range radio trasmissivo, senza l'ausilio di stazioni e router. Nella Figura 2.2 viene mostrata una possibile topologia di una singola rete MANET. Il riquadro più esterno indica quali sono gli ipotetici conni della rete, al suo interno invece, possiamo notare che ci sono tre contenitori che segnalano qual è il range di trasmissione. Il range di trasmissione non è nient'altro che la capacità che un dispositivo ha nel riuscire ad individuare quali sono i suoi vicini. Intuitivamente si potrebbe asserire che ognuno dei contenitori possa in qualche modo individuare una sottorete MANET, ma è proprio qui l'errore. Infatti anche se un dispositivo non fa parte del range di trasmissione di un'altro (es. il contenitore A può comunicare sia con il contenitore B, in cui vi è solo un elemento, sia con il contenitore C), ciò non esclude che i due possano comunicare attraverso quello che si chiama protocollo di routing. Di ciò verrà discusso dettagliatamente nel Capitolo 3. La modalità ad hoc, che verrà descritta più in dettaglio nel paragrafo 2.2, è tipicamente stata pensata in casi di disastro o emergenza, in cui non è possibile avere un'infrastruttura di comunicazione ssa. Proprio per l'assenza di punti di accesso, le reti ad hoc permettono un'elaborazione distribuita in contesti che potrebbero essere dicili da gestire. Di seguito viene riportata la Tabella 2.1 da cui si evincono le più importanti proprietà delle due reti menzionate in precedenza. Reti Copertura Architettura Infrastructure Network 50-80 metri centralizzata Ad Hoc Network 50-100 metri decentralizzata Tabella 2.1: Reti wireless 2.1.1 Tecnologie di rete wireless Nella maggior parte dei casi le reti wireless, vengono costruite mediante la connessione di trasmettitori radio a computer e PDA, con il supporto di un punto di accesso centrale che gestisca la rete. Di seguito verranno descritti gli standard più diusi delle reti wireless in particolare la Figura 2.3 mostra lo standard 802. Tale standard include quelli 15

Stato dell'arte Impossibilità di visione di altri dispositivi B Stesso range trasmissivo Stesso range trasmissivo A C Figura 2.2: Insieme di dispositivi connessi ad una stessa MANET che sono i requisiti dettagliati per il livello sico e per la parte superiore del livello data link, ovvero il MAC (Medium Access Control) secondo la terminologia introdotta dallo standard IEEE 802. Di seguito riportiamo una descrizione dettagliata di tale tecnologia. 2.1.2 IEEE 802.11 L'IEEE (Institute of Electrical and Electronic Engineers) è l'ente degli Stati Uniti nato nel 1963, con sede a New York che denisce i modelli di rete e metodi di accesso, e sviluppa ed approva gli standard di un'ampia gamma di tecnologie. Gli standard di networking di IEEE portano il numero 802, mentre quelli wireless ne sono un sottoinsieme, con il numero 11. Il primo standard wireless di IEEE, adottato nel 1997, era semplicemente chiamato IEEE 802.11; era uno standard di trasmissione radio a 2,4 GHz con un throughput 2 massimo di 2 Mbps. Una revisione dello standard a velocità 11 Mbps, fu chiamata 802.11 High Rate. Nel 1999 lo standard 802.11 High Rate venne chiamato 802.11b. In seguito sono stati aggiunti come standard sia 802.11a, sia 802.11g. 16 2 Quantità di lavoro eettuata in un tempo prestabilito.

2.1 Reti Wireless IEEE 802.2 Logical Link Control (LLC) OSI Layer 2 Data Link IEEE 802.3 Carrier Sense IEEE 802.4 Token Bus IEEE 802.5 Token Ring IEEE 802.11 Wireless MAC OSI Layer 1 Fisico Figura 2.3: Famiglia 802 802.11b Lo standard 802.11b è una versione migliorata dello standard originale 802. Le reti 802.11b operano alla velocità massima di 11 Mbps. Tale standard è anche conosciuto come Wi-FI (Wireless Fidelity). Lo standard IEEE 802.11b supporta un meccanismo per criptare 3 il traco dati e autenticare i nodi di connessione col nome di WEP (Wired Equivalent Privacy), sistema di encryption basato su una chiave condivisa ai ni della sicurezza contro le intercettazioni. La secret key (chiave segreta) lunga 40 bit è concatenata a un vettore di inizializzazione lungo 24 bit; si ottiene così una sequenza di 64 bit totali. Attualmente si utilizza un algoritmo di crittograa WEP a 128 bit, dove si ha una chiave a 104 bit con un vettore di inizializzazione a 24 bit, garantendo una maggior sicurezza e adabilità. Come tecnologia di rete, 802.11b è molto lenta rispetto alle comuni Ethernet su cavo. Nonostante ciò, 802.11b è lo standard di fatto del mondo delle reti wireless. Ciò lo dimostra il fatto, che alcuni nuovi standard sono ad oggi studiati per la compatibilità con le reti 802.11b. Il successo di 802.11b non solo per l'uso privato, ma anche per l'installazione di reti in luoghi pubblici, è tale, che in molti paesi si sta procedendo a liberalizzare ulteriormente la banda a 2,4 GHz. 802.11a Questo standard denominato anche Wi-FI 5 è stato approvato poco dopo 802.11b. IEEE 802.11a funziona nella banda a 5 GHz e tocca i 3 Processo di rimescolamento dei dati in modo che i destinatari non autorizzati non possano leggerli. 17

Stato dell'arte 54 Mbps. Tale standard è nato come risposta alle esigenze dei sempre più numerosi utenti privati; permette infatti di supportare vari segnali contemporaneamente, fra i quali anche quelli di tipo audiovisivo. I prodotti per questo standard hanno cominciato ad apparire nel 2002. Non è ancora molto chiaro quanta diusione avrà lo standard 802.11a, poichè al momento lo standard 802.11b ha una scelta di prodotti più ampia, a prezzi molto accessibili, ed anche perchè l'802.11a è incompatibile con l'802.11b. 802.11g Nel 2002 il Task Group 802.11g ha approvato lo standard di rete IEEE. La velocità è di 54 Mbps. Anche l'802.11g opera nei 2,4 Ghz ed è compatibile all'indietro con il vecchio standard 802.11. Gli standard 802.11b e 802.11g possono lavorare insieme, infatti si pensa che in un prossimo futuro questi due standard verranno adottati sia da utenti privati che da piccole aziende. Nella tabella 2.2 vengono riportate le caratteristiche principali degli standard appena descritti. Standard Frequenza Data Rate Copertura IEEE 2,4 GHz 1-2 Mbs pochi metri 802.11 IEEE 2,4 GHz 5,5-11/22 50-100 metri 802.11b Mbs (Wi-FI) IEEE 5-40 GHz no a 54 Mbs 20-40 metri 802.11a (Wi-FI 5) IEEE 2,4 GHz no a 54 Mbs 50-80 metri 802.11g Tabella 2.2: Standard a confronto 2.1.3 Vantaggi di una rete wireless In generale si può aermare che con l'utilizzo di una rete wireless non è più necessaria la presenza di modem o di cavi Ethernet, o di altri ostacoli che impediscono la totale libertà da parte di utenti privati o enti pubblici. Scenario tipico è quello dell'università dove sono installati uno o più punti di accesso. In questo caso è suciente entrare nel campo di azione di uno di questi access point, per collegare il proprio computer alla rete dipartimentale. In questo settore, la tecnologia wireless è orientata ad orire connettività ad una LAN cablata preesistente. 18

2.1 Reti Wireless In altri ambiti, è intesa a sostituire completamente l'uso di cavi di collegamento, anche per le postazioni sse, qualora il cablaggio tradizionale risultasse troppo costoso o scomodo. E' interessante notare come questa tecnologia oggi come oggi stia prendendo piede sempre di più; infatti aeroporti, ospedali installano access point per orire accessibilità ad Internet, alla propria clientela. I vantaggi che la tecnologia wireless ore rispetto alle reti classiche sono: Mobilità. Flessibilità. Convenienza. Scalabilità. Mobilità La mobilità, è uno degli aspetti cardini delle reti wireless; infatti consente la totale libertà di movimento dovunque ci si trovi, togliendo tutte le limitazioni legate ad una rete wired. Se si è provvisti di laptop, palmari o desktop, si può accedere alla rete senza richiedere un collegamento sico. L'utente può scegliere di spostarsi liberamente rimanendo sempre connesso alla rete. Flessibilità Una rete wireless è un sistema di comunicazione essibile e implementabile nella sua estensione. Le reti wireless arrivano dove le altri reti non riescono. La rete senza li permette di posizionare un computer desktop dove un cavo non potrebbe arrivare. Scalabilità Le reti wireless sono intrinsecamente scalabili; è possibile crearne dapprima una con pochi terminali e successivamente acquistare nuovi dispositivi e connetterli. La scalabilità è un fattore molto importante anche dal punto di vista economico, poichè la rete wireless può crescere di dimensioni e potenza con il crescere delle necessità degli utenti. In alcuni edici il cablaggio tradizionale è dicile e costoso. Le aziende composte in edici di più piani possono risparmiare considerevolmente adottando il wireless. Convenienza La convenienza di utilizzare una rete wireless all'interno di una piccola azienda, un areoporto, un'università, sta nel fatto di condividere via wireless un singolo accesso ad Internet, portando a considerevoli risparmi. 19

Stato dell'arte 2.1.4 Problemi con le reti wireless L'utilizzo delle reti wireless rispetto alle reti wired, ad oggi risentono di alcuni problemi non trascurabili che sono: Mezzo inadabile. Sicurezza. Area di copertura limitata. Salute. Costo. Mezzo inadabile L'intrinseca inadabilità del mezzo trasmissivo si ri- ette su numerosi aspetti implementativi e con una serie di limitazioni legate sia al range di utilizzo, sia alla velocità di trasmissione. Se si è scelto di utilizzare una rete wireless, bisogna stare molto attenti a dove la si vuole collocare, poichè non sono certo indicate aree con alto rumore elettromagnetico. D'altronde, quale che sia l'ambiente scelto, non è pensabile che la trasmissione via etere sia immune da interferenza, che, come è noto, ha un impatto critico sulla trasmissione dati. I sistemi wireless ad oggi sorono maggiormente di disturbi. Le interferenze che si possono subire adottando una WLAN sono molteplici, come onde elettromagnetiche o microonde. Quest'ultime lavorano proprio nella banda di 2,4 GHz, che come viene mostrato dalla Tabella 2.2, è la stessa utilizzata dagli standard 802.11, 802.11b e 802.11g. Sicurezza Il problema più grave di una rete wireless è la sicurezza dei dati. I primi modelli di access point non possedevano nessun tipo di protezione, ma semplicemente richiedevano uno username ed una password; i dati viaggiavano liberi e chiunque poteva leggerli ed avere un accesso garantito alla rete. Con i modelli successivi sono state implementati diversi tipi di crittograe più o meno ecaci (attualmente la più diusa è la WEP a 128bit, mentre le versioni a 256 hanno dicoltà ad uscire sul mercato). Queste forme di sicurezza non sono ancora sucienti a garantire completamente la sicurezza della rete. Un altro aspetto negativo è quello riguardante il rallentamento delle connessioni di rete, dovuto al negoziamento delle chiavi di criptograa durante l'accesso tra un access point ed i client. Se si utilizza il metodo di crittograa a chiavi pubbliche il problema si riduce notevolmente, altresi se si utilizza quello a chiave singola la sicurezza della rete è di nuovo posta in pericolo. La sicurezza delle connessioni è minata anche dalla relativa gioventù del protocollo e dai bugs che potrebbero essere contenuti al suo interno. 20

2.2 Reti MANET Area di copertura limitata Per quanto riguarda il problema legato alla copertura, le reti wireless possono raggiungere al massimo i (150 m) centocinquanta metri. Non si può trasmettere a distanze più elevate anche perchè si vuole mantenere basse le potenze in gioco. Detto ciò si deduce che esiste un limite all'estensione di una rete wireless, che in parte condiziona la topologia della rete. Infatti dato che la velocità di trasmissione è inversamente proporzionale alla distanza, per trasmissioni ad alta velocità (lo standard 802.11a raggiunge i 54Mbs) non si possono superare alcune decine di metri. Salute Sebbene ancora non esistano prove certe e denitive sulla pericolosità o meno delle onde elettromagnetiche, va comunque menzionato che l'utilizzo di una rete wireless (più propriamente i punti di accesso) costringe i gli utenti ad essere immersi di fatto in queste onde. Costo Anche se come abbiamo menzionato nel paragrafo 2.1.3 mettere in piedi una rete wireless in certi casi può risultare conveniente, in altri costruire una rete wireless potrebbe risultare più costoso, poichè occorre acquistare accessori supplementari, come uno o più punti di accesso e schede di rete Wi- FI, dal momento che i computer attuali sono concepiti per reti tradizionali. Infatti ad oggi tutti i computers comprendono una porta Ethernet di serie, ma non tutti hanno un accesso wireless. Negli ultimi anni però sta prendendo sempre più piede la tecnologia per i notebook portatili, in grado di semplicare ulteriormente l'adozione delle tecnologie wireless; questa tecnologia denominata mobile Intel Centrino [4] integra le funzionalità LAN wireless 802.11a/b già all'interno del notebook, eliminando la necessità di acquistare una scheda di rete wireless. La tecnologia mobile Intel Centrino assicura inoltre prestazioni rivoluzionarie per i laptop, supporta portatili più sottili e leggeri per una maggiore mobilità. Per concludere le reti wireless inizieranno ben presto ad essere un bene in termini di semplicità e versatilità. 2.2 Reti MANET Le MANET [1](Mobile Ad hoc NETwork) sono un innovativo tipo di rete formata da dispositivi wireless (e quindi mobili) capaci di comunicare tra loro svolgendo operazioni di instradamento, senza alcun bisogno di una infrastruttura come avviene, invece, per la telefonia cellulare che ha bisogno di antenne e ripetitori. Le reti ad hoc sono un sistema di comunicazione dati, basato su trasmissioni radio nelle quali i nodi comunicano esclusivamente su canali wireless, senza nessun tipo di ausilio centralizzato. Le reti MANET si basano sul concetto Peer-to-Peer (P2P), dove i peer non 21

Stato dell'arte sono altro che normali personal computer, palmari, laptop etc.. L'architettura P2P è una architettura nella quale i peer possono condividere capacità di calcolo, spazio su disco e ogni tipo di risorsa in genere, senza l'utilizzo di un server centrale. Il fulcro di un'architettura P2P è l'assenza di un server centrale che amministri le connessioni e le risorse. Tale tecnologia evolve l'ambiente di elaborazione centralizzato pre-esistente ad un nuovo livello di infrastruttura software, creando una rete point-tomultipoint tra host equivalenti che si comportano, a seconda della situazione, da server o da client. Una rete MANET è una rete temporanea, senza punti di accesso, che non viene precongurata, ma si forma per la sola presenza dei vari dispositivi in un dato territorio. Nella Figura 2.4 viene presentata una possibile topologia della rete, da cui si evince che i dispositivi che prendono parte alla MANET possono comunicare, a seconda delle loro esigenze, con gli altri partecipanti. Di seguito verranno Figura 2.4: Reti ad hoc date alcune denizioni, elencati quali sono i vantaggi e le problematiche ad oggi che intercorrono nell'utilizzo di reti MANET. 22

2.2 Reti MANET Introduzione Le reti ad hoc, sono reti interoperabili, facilmente installabili che non dipendono dall'infrastruttura pre-esistente. Ogni dispositivo (un telefono cellulare, un palmare, un computer) si comporta come un nodo capace di far arrivare automaticamente pacchetti contenenti informazioni verso un altro nodo, che si trova più vicino alla destinazione prescelta (concetto di routing descritto nei Capitoli 3 e 4). Per questo motivo siamo di fronte a reti multi hop, letteralmente multi-salto: questa tecnologia è capace di far giungere le informazioni attraverso diversi dispositivi per portarle, con una serie di piccoli balzi, ad un obiettivo che può essere anche molto lontano. In altre parole, invece di instaurare la comunicazione facendo un grande balzo no ad un'antenna (come avviene nella telefonia cellulare), si utilizzano una serie di piccoli salti che necessitano di meno energia e dovrebbero garantire una maggiore adabilità. Infatti, se uno dei nodi cade, perché ad esempio gli si sono scaricate le batterie, il proprietario ha deciso di spegnerlo o si è spostato in una zona troppo lontana per essere sfruttato in maniera eciente, la rete è capace di ricongurarsi e trovare comunque una via per far comunicare tra loro i vari nodi. E' proprio l'alta ricongurabilità, che verrà discussa nel paragrafo 2.2.2, uno degli aspetti su cui si basa il maggiore interesse nell'ambito della ricerca. Questo tema però si basa sul concetto di protocollo di routing che come menzionato nel paragrafo 2.1 verrà analizzato in maniera accurata nel Capitolo3. Denizioni Una rete mobile ad hoc è una rete di comunicazione stabilita tra diversi dispositivi mobili (identicati anche con il termine Mobile Station più in breve MS). Questa tipologia di rete è generata all'occorrenza, basandosi non necessariamente su una esistente infrastruttura o su di un qualsiasi genere di stazione ssa. Asserito ciò, possiamo denire una rete ad hoc come un sistema autonomo di MSs, connessi mediante link wireless. L'unione dei link wireless crea una rete di comunicazione modellata nella forma di un arbitrario grafo di comunicazione. Questa denizione è in contrasto con il ben conosciuto modello single-hop (a singolo salto) delle reti cellulari, dove viene richiesto l'installazione di Base Station (BS) come access point per supportare le comunicazioni via wireless. Infatti in queste reti cellulari, la comunicazione tra due nodi mobili si basa su una infrastruttura wired e su base station sse. In una rete MANET non esiste nessuna delle infrastrutture in precedenza citate e la topologia della rete può cambiare dinamicamente in maniera imprevedibile, dato che i nodi sono liberi di muoversi. Le reti ad hoc sono semplicemente delle reti wireless peer-to-peer e multi-hop, in cui i pacchetti informazione sono trasmessi nella maniera store-and-forward, ovvero dalla sorgente ad una destinazione arbitraria, attraverso nodi intermedi. Può 23

Stato dell'arte accadere che data la mobilità di una rete MANET, i dispositivi al suo interno, potrebbero spostarsi a loro piacimento. Se ciò accade i cambiamenti risultanti nella topologia della rete devono essere però resi noti a tutti gli altri nodi, cosicchè le informazioni riguardanti i cambiamenti topologici della rete possono essere sempre aggiornati o addirittura rimossi. 2.2.1 Caratteristiche delle MANET Le caratteristiche più salienti di una rete ad hoc che si possono no ad ora desumere sono: Topologia Dinamica. I nodi sono liberi di muoversi arbitrariamente, perciò la topologia della rete può cambiare in maniera random (nello spazio) e in un tempo imprevedibile. Vincoli di banda e capacità variabile dei link. I collegamenti wireless tra nodi mobili continuano ad avere una signicante bassa capacità rispetto a quella delle reti basate su infrastrutture. In più il tasso di trasmissione (il throughput) delle comunicazioni wireless (tenendo conto degli eetti di accessi multipli, rumore, condizioni delle interfacce, etc.) è molto inferiore rispetto al tasso di trasmissione delle onde radio. Operazioni vincolate dall'energia. L'energia di alcuni o tutti i nodi di una rete ad hoc dipendono da batterie o strumenti energetici simili. Per questi nodi uno dei più importanti criteri di progettazione è ottimizzare il consumo energetico. Sicurezza sica limitata. Le reti mobili wireless sono generalmente più propense ad un trattamento della sicurezza sica rispetto alle reti wired. La sempre più crescente possibilità di attacchi quali ascolti, spoong 4 e denial-of-service 5 deve essere tenuta conto dai progettisti che realizzano sistemi per queste reti. 2.2.2 Vantaggi delle MANET Non c'è dubbio che le reti ad hoc rappresentano una rivoluzione nel modo in cui si sono pensate in questi anni le reti. Di seguito verranno elencati quelli che sono i più importanti vantaggi che le reti MANET possiedono, descrivendo brevemente quello che può essere uno scenario di utilizzo di esse. Esempi classici sono applicazioni che vanno dalle reti nel campo militare, alle applicazioni di business, per arrivare alle applicazioni in caso di disastro naturale o di atto terroristico. Lo scenario pensato riguarda una squadra 4 Un host genera pacchetti IP con indirizzi di sorgente falsi. Il ricevente non è in grado di stabilire se l'origine dei pacchetti sia quella autentica. 5 Flusso di pacchetti maligni che sommerge il ricevente. Un simile attacco è denominato Distributed DoS (DDoS) ed è un attacco coordinato multiplo. 24

2.2 Reti MANET di soccorritori, provvisti tutti di dispositivi mobili, che deve operare in una situazione di emergenza come un terremoto. Come successe nel 1997 in Umbria (Italy) il terremoto colpì diverse aree geograche (per l'esattezza 48 comuni)[8]. Anche se tempestivi gli aiuti da parte dei vigili del fuoco non furono sucienti a salvare le 12 vittime. Di certo non si vuole aermare che i vantaggi che vengono oerti dalle reti MANET porteranno in un futuro a salvare vite umane, si vuole solo far evincere cosa danno in più, soprattutto in queste situazioni drastiche. L'idea è che è molto utile per i soccorritori coordinare in maniera eciente e celere gli interventi, per dare un'assistenza rapida e tempestiva. Le rete MANET pertanto orono tali servizi: Assenza di centralizzazione. Capacità di ricongurare la rete automaticamente. Totale mobilità. Capacità di sfruttare al meglio le risorse di un gruppo di lavoro. Convenienza. Assenza di centralizzazione Le reti MANET sono una forte alternativa alle reti basate su infrastrutture, poichè sono reti particolarmente interessanti per permettere un'elaborazione distribuita in contesti dicili o addirittura ostili in cui non è possibile avere un'infrastruttura di comunicazione ssa. Le reti ad hoc non necessitano di sistemi centralizzati per permettere la comunicazione tra i dispositivi. La comunicazione infatti avviene come è stato citato nel paragrafo 2.2, secondo l'architettura peer-to-peer. I dispositivi hanno la possibilità di poter comunicare con altri device potendo essere nello stesso istante sia client sia server. Tutto ciò avviene senza passare per qualche punto di accesso, o hardware dedicati. Un soccorritore pertanto potrà in qualsiasi istante dare informazioni su cosa sta succedendo intorno a se, ricevendo, però anche quelle che sono le notizie che giungono da un'altra postazione. Capacità di ricongurare la rete automaticamente da parte dei nodi La capacità da parte dei dispositivi di ricongurare la rete è una proprietà molto importante, poichè nelle reti wired ciò non è attuabile. Nel nostro scenario l'idea è quella che se un soccorritore A vuole comunicare una notizia molto importante ad un soccorritore B, passando per C (concetto di routing che verrà discusso dettagliatamente nel Capitolo 4) e se C, per qualche motivo, ha il suo dispositivo spento, A non si deve assolutamente preoccupare perchè sarà messo in comunicazione con B passando per altri soccorritori. 25

Stato dell'arte Totale mobilità La mobilità è il fulcro delle reti MANET. Come si è già spiegato nel paragrafo 2.1.3 l'assenza di cavi, ore ai suoi utilizzatori la totale libertà di movimento in qualsiasi ambiente ci si trovi. Nello scenario preso come esempio la totale indipendenza di cavi, fa si che la squadra di soccorso possa in qualsiasi istante cambiare posizione, senza nulla togliere alle prestazioni del soccorso. Capacità di sfruttare al meglio le risorse di un gruppo di lavoro Questa proprietà è molto utile in quelle situazioni di disastro o emergenza. Nel nostro scenario i soccorritori sulla scena del terremoto, potrebbero avere bisogno di scambiarsi immagini, video, graci, piantine, informazioni in genere. Ciò è possibile da realizzare data la capacità a larga banda (sopra i 2 MB/s) in piena mobilità in un'area più vasta. È evidente, infatti, che la larghezza di banda richiesta per supportare i servizi di coordinamento delle forze di pronto intervento è sostanziale. L'interoperabilità con i futuri sistemi satellitari broadband e i sistemi HAPS (High Altitude Platform Systems) rappresenta di conseguenza un requisito chiave per superare le dimensioni limitate della cella di un sistema radio che opera nel range di frequenza dei GHz. L'interconnessione a un futuro servizio mobile broadband con il satellite assicurerà infatti una comunicazione stabile dalle aree in cui le infrastrutture terrestri non siano disponibili o siano state distrutte durante disastri naturali o atti terroristici. Per operazioni di questo tipo, infatti, sarà suciente che le auto della polizia e i mezzi di soccorso trasportino un transponder satellitare integrato per creare un'isola o hot spot di copertura wireless a larga banda intorno all'area dell'incidente. In questo modo le forze che intervengono potranno utilizzare anche i loro terminali, con servizi avanzati come, ad esempio, la telefonia con voce over IP, la trasmissioni video o la scansione dell'iride per una rapido identicazione di un sospetto. Convenienza Dal punto di vista economico le reti ad hoc non sono reti complicate o costose da implementare, infatti si possono creare in maniera semplice ed immediata, disponibili in ogni situazione e le si possono sviluppare in posti dicilmente raggiungibili dalle reti strutturate. 2.2.3 Problemi delle MANET Le problematiche che ad oggi sono riscontrabili nell'utilizzo delle reti MANET sono: 26 Mancanza di punti ssi. La possibilità di non avere un accesso alla rete.

Poca copertura nelle trasmissioni. 2.2 Reti MANET Attualmente non esistono applicazioni che permettono l'operazione di routing. Mancanza di punti ssi Dal punto di vista dei protocolli di rete, la mancanza di nodi ssi determina la necessità di ripensare in maniera radicale l'implementazione delle funzionalità di base (per esempio, le politiche di instradamento dei messaggi) che, a dierenza dello scenario tradizionale, coinvolgono anche i nodi terminali. Va inoltre considerato che i nodi, a dierenza dei consueti personal computer, potrebbero essere costituiti da palmari o telefoni delle nuove generazioni, e cioè da dispositivi con risorse limitate, per i quali diventa essenziale controllare e ridurre il consumo di energia. Nonostante stiano emergendo alcune proposte, non esistono ancora degli standard che rideniscano la pila di protocolli per le MANET e per la connessione con le reti sse attraverso collegamenti satellitari. La possibilità di non avere un accesso alla rete Per le applicazioni da eettuarsi in caso di emergenza, disastro, il problema saliente sta nell'interconnessione della (o delle) reti MANET con la rete ssa. Dalla Figura 2.5, si evince una possibile congurazione di rete MANET. L'idea è che i dispositivi mobili (laptop, PDA) comunicano tra loro utilizzando una rete MANET, se ad esempio il computer centrale vuole richiedere una connessione alla rete, lo può fare passando attraverso un dispositivo cellulare. Questi dispositivi sono equipaggiati di tecnologia GPRS, o GSM, o UMTS. I dispositivi cellulari a loro volta sfruttano la loro antenna radio, che contatta il satellite. Per concludere la possibilità di avere a disposizione un accesso alla rete ssa in casi di emergenza ha due nalità, che sono: per avere un collegamento verso l'esterno per mantenere i collegamenti interni al gruppo in maniera trasparente, evitando la disconnesione. Ad oggi ciò si può avere solo mediante collegamenti attraverso satelliti geostazionari a bassa quota o mediante collegamento cellulare (per esempio, GPRS, GSM e UMTS). Poca copertura nelle trasmissioni Le reti MANET rispetto alle reti wired coprono un raggio di azione sicuramente meno elevato. D'altronde se da un lato la comunicazione in una rete MANET permette la totale libertà di movimento, poichè non vi è la presenza di cavi e li, dall'altro lato l'utilizzo di una rete wireless, va a perdere quello che è la copertura radio delle trasmissioni. 27

Stato dell'arte Figura 2.5: Accesso alla rete in una rete MANET Assenza del concetto di routing Come verrà chiarito nel Capitolo 4, oggi come oggi, non esistono delle applicazioni su reti ad hoc che permettano di eseguire routing tra dispositivi mobili. Nella pila ISO/OSI mostrata in Figura 2.6, ciò che tutt'ora viene a mancare nelle applicazioni su rete MANET è il livello di rete. Essenzialmente nelle reti ad hoc ci si avvale solo dell'ausilio dei due livelli sottostanti che sono: livello di collegamento livello sico. 2.3 Conclusioni Come è stato largamente detto le reti MANET sono reti decentralizzate, che non hanno alcun bisogno di una infrastruttura ssa. In questa tesi è stata creata una rete wireless in tipologia ad-hoc-network che utilizza la tecnologia wireless Wi-FI IEEE 802.11b. Tale tecnologia è stata dettagliatamente menzionata nel paragrafo 2.1.2. Ma un'alternativa all'utilizzo delle reti MANET può essere fornita dalla tecnologia Bluethooth. Come gli standard 802.11b e 802.11g Bluethooth è una tecnologia di trasmissione radio a 2,4 Ghz, ma raggiunge solo un Mbps, con 28

2.3 Conclusioni Applicazione Presentazione Sessione Trasposto Rete Collegamento Fisico Figura 2.6: Pila ISO-OSI un campo di poco superiore ai dieci metri. Una caratteristica peculiare di Bluethooth è il fatto che non necessita di un punto di accesso per gestire la rete, ed è in grado di creare connessioni punto-multipunto. Ciò signica che i dispositivi Bluethooth sono in grado di comunicare direttamente senza bisogno di alcuna intermediazione. Per concludere si è scelto di utilizzare la tecnologia Wi-FI, piuttosto che quella Bluethooth poichè oltre ad avere un Data Range superiore (da 5,5 Mbs a 11/22Mbs) ha una copertuta 5 (50 metri come minimo rispetto a 10 metri) o anche 10 (100 metri come massimo rispetto a 10 metri) volte maggiore. 29

Capitolo 3 Analisi dei protocolli di routing 3.1 Protocolli di routing In questo capitolo verrà data una classicazione degli algoritmi di instradamento descrivendo dettagliatamente alcuni possibili protocolli che permettono di fare routing all'interno di una rete MANET. Verrà inoltre spiegato il motivo per cui dopo aver visionato molti protocolli di routing si è scelto di implementare l'algoritmo Reactive DSR (Dynamic Source Routing). 3.2 Organizzazione della rete La topologia di una rete MANET può essere o di tipo gerarchica o di tipo piatta. In una rete gerarchica i nodi sono suddivisi in gruppi, denominati cluster. Per ogni cluster viene selezionato un cluster head 1, attraverso il quale passa tutto il traco della rete. Nell'utilizzo di una rete gerarchica vi è un vantaggio, cioè quello di minimizzare il numero di pacchetti di routing scambiati tra i nodi di uno stesso cluster, e anche tra i vari cluster head. In una rete piatta invece non esiste nessun tipo di centralizzazione, così da permettere di stabilire più di un percorso tra il nodo sorgente e il nodo destinazione. Questo è un vantaggio perchè in tal modo si possono valutare diverse metriche per stabilire il peso di un collegamento, a seconda delle richieste di utilizzo della rete stessa. Di seguito verranno presentati gli algoritmi di instradamento, spiegando quali sono i vantaggi e gli svantaggi nel loro utilizzo. 1 Identica il nodo a capo di un cluster che organizza i compiti degli altri componenti del gruppo. 31

Analisi dei protocolli di routing 3.3 Algoritmi di instradamento Gli algoritmi di instradamento possono essere classicati in base alle politiche che adottano per adempiere ai loro compiti; tale politiche possono essere: Organizzazione della rete. Modalità di reperimento delle informazioni di instradamento. Modalità con cui viene deciso il percorso verso il nodo destinazione. Classicazione in base all'organizzazione della rete La rete può essere organizzata in maniera: uniforme, in cui lo scambio di informazioni di routing avviene tra tutti i nodi 2 allo stesso modo; non uniforme, dove cioè ogni nodo risponde e genera informazioni di routing in modo diverso a seconda del suo ruolo. I nodi che compongono la rete non uniforme possono essere a loro volta suddivisi, a seconda dei compiti che svolgono all'interno della rete, in Neighbor Selection o Hierarchical. La Figura 3.1, mostra la suddivisione della rete nelle due diverse tipologie appena citate. Nel primo caso il nodo X comunica con il nodo Y passando per nodi intermedi, che svolgono le stesse operazioni di instradamento (infatti per marcare proprio il fatto che i nodi sono tutti uguali e svolgono le medesimi operazioni si è utilizzata la stessa segnatura per rappresentarli). Nel secondo caso la non uniformità della rete viene rappresentata attraverso la dierenziazione dei nodi all'interno dei tre involucri (nodo pieno, nodo vuoto, rappresentano i diversi compiti che un nodo può assumere). Classicazione in base alla modalità di reperimento delle informazioni di instradamento Il reperimento delle informazioni può avvenire in modalità Proactive (detta anche Table-Driven) o in modalità Reactive (detta anche On-Demand). In modalità Proactive i nodi si scambiano informazioni di routing a intervalli ssi di tempo; questa caratteristica permette che ci sia un instradamento immediatamente disponibile ad ogni richiesta di routing; purtroppo però ciò comporta un elevato traco di segnalazione. In modalità Reactive, viene invocata una procedura per determinare il corretto instradamento solo se si vuole trasmettere un pacchetto. Ciò porta ad avere un ritardo nella trasmissione dei pacchetti dati, riuscendo però ad 2 D'ora in avanti si assumerà che il termine nodo, device, host, terminale rappresentano la stessa cosa. 32

3.4 Suddivisione dei protocolli di routing Rete uniforme Rete non uniforme Destinazione Destinazione Sorgente Sorgente Figura 3.1: Organizzazione della rete abbassare notevolmente il traco di segnalazione. Nel paragrafo 3.4 verrà ulteriormente approfondito questo aspetto. Classicazione in base alla modalità con cui viene deciso il percorso verso il nodo destinazione Il percorso verso il nodo destinazione può essere ottenuto attraverso un approccio source routing, in cui il nodo sorgente determina l'esatto percorso che il pacchetto dati deve eseguire, per raggiungere la destinazione, oppure non source routing, dove l'unica informazione di routing è il next-hop 3 : ciascun nodo decide in modo indipendente a chi ritrasmettere il pacchetto anchè questo raggiunga la destinazione. 3.4 Suddivisione dei protocolli di routing I protocolli di routing [9] forniscono il corretto percorso che un pacchetto deve compiere, dal nodo sorgente al nodo destinazione, cercando di adattarsi il più possibile ai mutamenti topologici della rete. Essi possono essere suddivisi in tre distinte categorie: Proactive. Reactive. Hybrid. I protocolli Proactive mantengono aggiornate le informazioni riguardanti l'instradamento tramite continui scambi di pacchetti ad intervalli ssi. 3 Identica il salto ad un dispositivo, dentro il range trasmissivo. 33

Analisi dei protocolli di routing Questa tecnica permette di avere sempre disponibile, l'instradamento ad o- gni richiesta. L'immediata risposta può risultare un vantaggio, ma ciò determina un notevole traco di segnalazione; può capitare infatti che la rete venga impegnata anche quando non vi è alcuna richiesta di trasmissione dati. Nei protocolli Reactive, viene invocata una procedura per determinare il corretto instradamento solo ed esclusivamente nel momento in cui il pacchetto deve essere trasmesso. Anche se la trasmissione dei pacchetti dati avviene in modo più lento rispetto ai protocolli Proactive, ciò permette di avere un minor impegno della rete, dovuto al basso traco di segnalazione. I protocolli Hybrid, invece, cercano di unire i vantaggi di entrambi i protocolli precedentemente descritti, ma presentano problemi a livello implementativo. La Figura 3.2 mostra una sorta di albero gerarchico, in cui i primi gli della radice (Routing Protocols) rappresentano le famiglie degli algoritmi Proactive, Reactive e Hybrid, scendendo nei due livelli sottostanti vi è la classicazione dell'organizzazione di rete, come descritto nel paragrafo 3.3, ed in ultimo menzionati gli attuali protocolli di routing di cui se ne parlerà più avanti. Figura 3.2: Algoritmi di instradamento 34

3.5 Algoritmi Proactive 3.5 Algoritmi Proactive Negli algoritmi Procative (anche denominati Table-Driven) i dispositivi mobili, facenti parte di una rete MANET, si scambiano informazioni ad intervalli di tempo ssati; per tale motivo l'instradamento è immediatamente disponibile ad ogni richiesta di routing. L'idea è di mantenere costantemente aggiornate tutte le informazioni di instradamento, tra tutti i dispositivi che compongono la rete. I protocolli che fanno parte di questa famiglia sono i seguenti: DSDV Destination Sequenced Distance Vector. WRP Wireless Routing Protocol. CSGR Cluster Switch Gatewey Routing. STAR Source Tree Adaptive Routing. Caratteristiche comuni dei protocolli Proactive I protocolli che fanno parte della famiglia Proactive sono accomunati dalle seguenti caratteristiche: Scambio di pacchetti ad intervalli ssi. Uso di tabelle. Aggiornamento delle tabelle. Scambio di pacchetti ad intervalli ssi Come si è accennato nel paragrafo 3.5 i protocolli Proactive hanno la proprietà di poter permettere ai componenti della rete di avere a disposizione le informazioni di routing (es. come raggiungere la destinazione, quale sono i dispositivi che in un determinato istante sono non raggiungibili etc.) sempre più aggiornate. Tale meccanismo è possibile poichè i dispositivi, senza alcuna necessaria richiesta, si scambiano tra loro pacchetti informativi. I pacchetti rivelano, sia le informazioni di instradamento sia i relativi cambiamenti topologici della rete. Uso di tabelle L'uso di una o più tabelle che memorizzano tutte le informazioni riguardanti la topologia della rete è una caratteristica peculiare della classe Proactive: tutti i protocolli in precedenza menzionati ne fanno uso. In dettaglio andremo ad esaminare sia qual'è in breve il funzionamento e sia quali tabelle utilizzano i quattro protocolli inizialmente citati. 35

Analisi dei protocolli di routing DSDV. Il protocollo DSDV, assegna ad ogni nodo una routing-table, nella quale sono memorizzate tutte le possibili destinazioni raggiungibili da un dispositivo e tutti i numeri di salto 4. Il protocollo si avvale anche dell'aiuto di una sequenza di numeri, che permette ad un utente mobile di eettuare una distinzione tra un route 5 vecchio rispetto ad uno nuovo. WRP. Il protocollo WRP si libera del problema count-to-innity 6 forzando ogni nodo a compiere dei severi controlli sulle informazioni riportate dai nodi vicini 7. Tutti i dispositivi cercano di evitare cicli all'interno della rete e forniscono percorsi alternativi quando si è di fronte ad un link failure 8. Ogni nodo mantiene quattro tabelle: distance-table, segnala il numero di salti tra un nodo e la destinazione richiesta. routing-table:, indica il nodo next hop. link cost-table, indica il ritardo associato ad un particolare link. message retrasmission list table, tabella che nel suo interno mantiene un numero di sequenza del messaggio d'aggiornamento, un contatore di ritrasmissione, un ag richiesto per il riconoscimento e un elenco degli aggiornamenti mandati nel messaggio di update. CSGR. Il protocollo CSGR si avvale del concetto di gerarchia (citato nel paragrafo 3.2), i nodi vengono suddivisi in gruppi, denominati cluster, ed ogni gruppo ha il suo cluster head. I cluster head hanno il controllo di più dispositivi all'interno del gruppo. Per eleggere un cluster head all'interno di un cluster si usa un algoritmo. Sebbene il cluster head ore servizi e varie forme di controllo e di coordinamento, ciò può essere usufruito solo da quei dispositivi che si trovano all'interno dello stesso cluster. Durante tutta la durata della sessione, non è detto che si debba sottostare allo stesso cluster head; quanto il cluster head risulta spento o irraggiungibile, un algoritmo si preoccuperà di scegliere un altro cluster head. Il fatto che un cluster head possa cambiare frequentemente per dierenti 4 Determina quanti nodi, bisogna contattare per raggiungere la destinazione. 5 D'ora in avanti si assumerà che il termine route, percorso, cammino rappresentino la stessa cosa. 6 E' un eetto del Distance Vector, nel quale i router non si accorgono che una destinazione è diventata irraggiungibile, ma credono che sia ancora attiva anche se riconoscono che la sua distanza sta aumentando sempre di più. 7 Dispositivi che si trovano nel range trasmissivo del dispositivo mittente. 8 Si verica quando un link fallisce. 36

3.5 Algoritmi Proactive motivazioni, può causare problemi per quei dispositivi che invece di inviare i dati alla destinazione, cercano di convergere verso quel cluster head, causando dei rallentamenti di trasmissione all'interno della rete. Il degrado delle prestazioni, dovuto ai continui cambiamenti di cluster head, viene tenuto a freno dall'algoritmo LCC; tale algoritmo aerma che si può cambiare cluster head soltanto se: sono presenti due cluster head nello stesso cluster; un nodo si sposta ed esce dal raggio d'azione di qualsiasi cluster head. Pur essendoci una divisione dei nodi in cluster, questo protocollo non esclude la comunicazione con altri cluster. Infatti il nodo sorgente che fa parte di un determinato cluster, invia un pacchetto al suo cluster head, questo a sua volta invia il pacchetto al gateway 9 che si occuperà di inviare il pacchetto ad un altro cluster head. Questa iterazione continua nchè non si arriva a contattare il cluster head del nodo di destinazione. Nella Figura 3.3. viene mostrata la comunicazione tra tre cluster head. C2 C3 C1 Figura 3.3: Comunicazione di tre cluster head nel protocollo CSGR Il protocollo CSGR usa il protocollo DSDV, come schema sottostante di routing ed inoltre viene utilizzato un approccio gerarchico per gestire il traco 9 Nodo che è nel range di due o più cluster head. 37

Analisi dei protocolli di routing dalla sorgente alla destinazione. Ogni dispositivo deve mantenere: cluster member table; memorizza i cluster head di destinazione di ogni dispositivo, inoltre la tabella viene trasmessa periodicamente dal protocollo DSDV. routing table; determina il next hop per raggiungere la destinazione. STAR. Il protocollo STAR appartiene alla famiglia dei protocolli Proactive. Ma, a dierenza degli altri che mantengono le informazioni in apposite tabelle, si avvale dell'aiuto del source-tree 10, ovvero di una struttura che mantiene informazioni sui nodi indicante il percorso per giungere a destinazione. In dettaglio il source-tree altro non è che un grafo (albero), in cui il primo nodo (la sorgente) è il richiedente di un percorso, e gli altri nodi sono i suoi vicini. Scorrendo lungo il grafo si può giungere, se è presente, al nodo di destinazione. Nella Figura 3.4 viene mostrato il source-tree tra un nodo A e un nodo B. Si pensi a questo generico scenario: il nodo A vuole poter comunicare con il nodo B; per prima cosa A verica la presenza del nodo B nel suo source-tree e in caso aermativo A instrada il pacchetto da trasmettere nel suo albero dei percorsi, raggiungendo il nodo B. Aggiornamento delle tabelle L'aggiornamento delle tabelle di routing è una qualità fondamentale di questa classe di protocolli, ciò fa si che gli utenti che optano nella scelta di questi protocolli, possano avere a disposizione una rete consistente. Di seguito verrà descritto come avviene l'aggiornamento delle tabelle nei singoli protocolli di routing. DSDV. Il protocollo DSDV tiene periodicamente aggiornare le tabelle in modo da mantenere la consistenza all'interno della rete. L'aggiornamento delle informazioni può avvenire in due modi dierenti: 38 aggiornamento timer driver, in cui i dispositivi periodicamente trasmettono le loro routing table ai nodi vicini per mantenere le tabelle consistenti; aggiornamento event driver, dove un nodo invia la sua tabella a causa di un improvviso cambiamento della stessa. 10 Albero di percorsi.

3.5 Algoritmi Proactive Percorso ad albero di B A B Percorso ad albero di A Figura 3.4: Protocollo STAR Gli aggiornamenti delle table-driven possono essere fatti o tramite full dump o incremental update; il primo è utilizzato per inviare tutte le informazioni di routing disponibili, il secondo invece viene usato quando ci sono pochi cambiamenti rispetto all'ultimo full dump. WRP. In generale un dispositivo, per mantenere informazioni di routing accurate, periodicamente scambia con i suoi vicini le routing-table, usando messaggi di aggiornamento. Un messaggio di aggiornamento possiede al suo interno: il nodo di destinazione, la distanza dalla destinazione, il predecessore. Quando i vicini ricevono messaggi di aggiornamento, sono tenuti ad inviare una risposta di avvenuta ricezione del messaggio. In caso non vengano rilevati cambiamenti all'interno della rete, ogni nodo è tenuto comunque ad inviare un messaggio di Hello 11. 11 Il messaggio di Hello notica la presenza del nodo all'interno della rete. 39

Analisi dei protocolli di routing Un aspetto interessante che coinvolge tutti i dispositivi della rete, si verica nella ricezione delle routing-table; infatti i dispositivi vericano se le routingtable ricevute contengono percorsi migliori rispetto a quelli memorizzati nelle loro routing-table. In caso aermativo automaticamente i dispositivi memorizzano il percorso nella loro routing-table. In caso negativo non viene eettuato nessun aggiornamento. CSGR. Il protocollo CSGR pur appartenendo alla famiglia dei Proactive non usa messaggi di aggiornamento, poichè i cambiamenti topologici della rete possono essere derivati solo dai movimenti improvvisi del cluster head, di cui se ne occupa l'algoritmo LCC STAR. Il protocollo STAR, non tenta di orire percorsi ottimi per raggiungere la destinazione. E' per questo motivo che il protocollo non esegue periodici aggiornamenti, per la memorizzazione dei percorsi. Solo in un caso i nodi sono tenuti a svolgere aggiornamenti, ovvero quando la topologia della rete cambia frequentemente. A questo punto tutti i nodi coinvolti nel cambiamento sono tenuti ad inviare messaggi di aggiornamento, proprio per evitare la presenza di guasti. E' evidente che lo scambio di messaggi di aggiornamento comporta un notevole traco di rete, ma ciò è essenziale per mantenere la validità di un source tree. Vantaggi dei protocolli Proactive I vantaggi che ore la famiglia dei protocolli Proactive sono i seguenti: permettere di avere immediatamente disponibile l'instradamento di pacchetti informativi anche se non si eettua una specica richiesta, avere un'immediata risposta ai cambiamenti topologici della rete, risulta essere un'agevolazione soprattutto in situazioni di poca copertura radio. Detto ciò andiamo a vedere quali facilitazioni potrebbero portare i quattro protocolli, se un utente dovesse sceglierli. DSDV. I vantaggi che ore il protocollo Proactive DSDV sono inerenti sia alla consistenza della rete, nel tenere frequentemente aggiornate le tabledriven, sia nel tentare di evitare i cicli all'interno di una rete. Inoltre anche il continuo aggiornamento delle tabelle sicuramente fornisce un notevole miglioramento riguardo le informazioni topologiche. 40

3.5 Algoritmi Proactive WRP. Il protocollo WRP ha come pregio quello di comportarsi molto bene quando si verica un link failure; infatti, se i dispositivi riescono in un arco di tempo, a scoprire la rottura del link, questi inoltrano ai nodi vicini un messaggio di aggiornamento, permettendogli di modicare le loro distance-table. CSGR. Unico merito che si può asserire al protocollo CSGR è che è stato pensato per agevolare quelle reti dove il numero dei dispositivi è elevato. STAR. Il protocollo STAR usa un source-tree per mantenere le informazioni relative ai suoi vicini; ciò consente di non eettuare aggiornamenti periodici. Svantaggi protocolli Proactive Nei protocolli Proactive le problematiche che si evincono sono le seguenti: eccessivo scambio di messaggi informativi; elevato traco di segnalazione. Di seguito vengono riportati gli ulteriori svantaggi che i singoli protocolli portano alla rete. Non verrà menzionato il protocollo DSDV, che in sostanza accusa gli stessi problemi appena descritti. WRP. Come è stato precedentemente esposto il protocollo WRP possiede quattro tabelle per immagazzinare tutti le informazioni inerenti alla rete. Purtroppo questa proprietà risulta essere uno svantaggio, se si è pensato di utilizzare dispositivi mobili come PDA, Smartphone, ect. poichè hanno una memoria abbastanza limitata (circa 128MB). Inoltre a suo sfavore c'è anche l'eccessivo scambio di messaggi di aggiornamento. CSGR. Notevoli svantaggi nell'utilizzo di questo protocollo sono dovuti ai continui cambiamenti dei cluster head. Per tale motivo capita che i nodi passino più tempo a determinare se un cluster head risulta irraggiungibile o addirittura spento, piuttosto che preoccuparsi ad instradare il pacchetto informazione. 41

Analisi dei protocolli di routing STAR. Il protocollo STAR ha come pecca quella di non preoccuparsi minimamente di orire ad un nodo, il percorso il più breve. Purtroppo è altrettanto dicile determinare la procedura di reperimento di un percorso, quando questo non è presente nel source-tree. 3.6 Algoritmi Reactive A dierenza dei protocolli Proactive, i protocolli Reactive creano i percorsi On-Demand, ossia solo quando un nodo ne fa esplicitamente richiesta. Tale proprietà risulta essere un grande vantaggio, poichè nelle reti MANET è insito il concetto di mobilità. Data l'alta possibilità di spostamento dei singoli dispositivi, i percorsi che si vengono a formare cambiano in continuazione ed è per questo motivo che risulta inutile e controproducente mantenere in anticipo tutti i route esistenti tra di essi. I protocolli che ne fanno parte di questa famiglia sono i seguenti: AODVAd Hoc On-Demand Distance Vector Routing. DSR Dynamic Source Routing. TORA Temporally Ordered Routing Algorithm. SSR Signal Stability Routing. LAR Location-Aided Routing. PAR Power-Aware Routing. RDMAR Relative Distance Microdiverity Routing. Del protocollo DSR verrà riportata una descrizione più dettagliata nel paragrafo 3.8. Grazie alle sue caratteristiche (l'utilizzo di una route cache, la determinazione di un link failure attraverso l'operazione di Route Manintenance, l'eliminazioni dei cicli all'interno della rete per mezzo dei pacchetti RREQ, RREP,RRER) esso è stato scelto come lavoro della seguente tesi. Caratteristiche comuni dei protocolli Reactive I protocolli Reactive, per inviare un pacchetto da un nodo sorgente ad un nodo destinazione eseguono i seguenti passi: scoperta del percorso tramite Route discovery; mantenimento del percorso tramite Route Manteinence; cancellazione del percorso con Route Deletion. Di seguito verrà spiegato il funzionamento e la fase di ricerca del percorso (Route Discovery) dei singoli protocolli Reactive. 42

3.6 Algoritmi Reactive Fase di Route Discovery nei protocolli Reactive La fase di Route Discovery è il fulcro dei protocolli Reactive. Tale procedura riesce a determinare, quando un nodo lo richiede, i molteplici percorsi per arrivare a destinazione. Di ogni protocollo si andrà a descrivere la seguente fase. AODV. La ricerca di un percorso nell'algoritmo AODV avviene in tal modo: quando il nodo sorgente richiede un percorso per giungere al nodo di destinazione, il nodo sorgente inizia una fase di ooding 12. Questa richiesta può arrivare sia direttamente a destinazione, sia ad un nodo intermedio, il quale deve essere in possesso di un'informazione sucientemente aggiornata. Una volta che un nodo (sia un nodo intermedio sia il nodo destinazione) riceve una richiesta, deve immediatamente rimandare al nodo sorgente una risposta, la quale indica l'avvenuta ricezione dell'informazione. Ciò può essere fatto utilizzando il percorso inverso. Per essere certi di costruire percorsi sia senza loop 13, sia contenenti informazioni aggiornate, ogni nodo mantiene un numero di sequenza. Tale numero è univoco per ogni percorso ed è per questa ragione che viene ogni volta incrementato, così che un nodo riesca a capire se ne è già in possesso. Entrando più nel dettaglio, quando il nodo sorgente richiede un route, oltre ad eettuare una richiesta di scoperta dei vicini 14, invia un pacchetto RREQ (Route Request) che rappresenta l'instanza di un percorso per giungere a destinazione. Se alla prima iterazione si riesce a contattare la destinazione, la fase di Route Discovery termina qui. Altrimenti viene eettuato l'invio dei pacchetti RREQ anche dai nodi intermedi, che contattano altri nodi a loro adiacenti, nchè si raggiunge il nodo richiesto. Il pacchetto RREQ viene identicato dal: broadcast ID, che viene incrementato ad ogni richiesta di percorso, l'indirizzo IP del nodo sorgente. Per concludere nella Figura 3.5 viene mostrata l'operazione di Route Discovery, in cui il nodo uno (N1) inoltra una richiesta a tutti i suoi vicini (ciò viene determinato dall'orientamento delle frecce), che a loro volta spediscono pacchetti RREQ giungendo a destinazione. 12 Il mittente propaga in tutta la rete una richiesta per arrivare ad nodo destinazione. 13 Cicli all'interno della rete. 14 Fase necessaria ad un dispositivo per capire quali nodi appartengono al suo range trasmissivo. In questa fase vengono spediti dei pacchetti informazione, che contengono: l'indirizzo IP del mittente, indirizzo IP della destinazione, il numero di sequenza. 43

Analisi dei protocolli di routing Data la bidirezionalità dei link, una volta raggiunta la destinazione, quest'ultima rimanderà tramite un percorso inverso (nel caso proposto il più corto, ma non è sempre detto) un pacchetto RREP (Route Reply) contenente il percorso (insieme di indirizzi IP dei nodi) che è stato fatto per giungere ad essa. Destinazione N1 N2 N5 N4 N7 N8 Destinazione N1 N2 N5 Percorso inverso N4 N8 N7 Sorgente N3 N6 Sorgente N3 N6 Route Discovery Figura 3.5: Protocollo AODV TORA. Di seguito verranno descritte le tre funzionalità base che si differenziano (solo per il nome) dalle tre fasi standard inizialmente menzionate. Esse sono: Route Creation, stabilisce una sequenza di link diretti dalla sorgente alla destinazione. Route Maintenance reazione ai cambiamenti topologici della rete per ristabilire percorsi dentro un certo tempo. Route Erasure, si verica quando vengono scoperte partizioni della rete per questo motivo i percorsi coinvolti devono essere cancellati. In tali casi vengono trasmessi dei clear-packet per noticare che i percorsi devono essere cancellati. Durante le prime due fasi viene costruito il grafo (denominato DAG Direct Aciclic Graph), ed assegnate le direzioni (upstream-downstream) ai link. La terza fase è utile nel momento in cui i nodi all'interno di una rete si spostano frequentemente. La Route Maintenance infatti cerca proprio di garantire l'aggiornamento del DAG. 44

3.6 Algoritmi Reactive La scoperta di un percorso nell'algoritmo TORA avviene tramite la costruzione di un grafo aciclico (il DAG si estende dal nodo sorgente al nodo destinazione). La sorgente identica la radice del grafo: è per questo motivo che la sua altezza è pari a zero; mentre gli altri nodi del DAG hanno altezza pari al numero di nodi da attraversare per giungere a destinazione. Tora ore percorsi multipli per ogni coppia sorgente/destinazione. In questo modo l'algoritmo trova potenzialmente più di un percorso per arrivare alla destinazione, cosicchè la manutenzione dei percorsi in caso di un guasto o di uno spostamento è notevolmente semplicata. Infatti nella maggior parte dei casi non bisogna ripartire con la richiesta di un nuovo percorso, ma si utilizza uno di quelli rimasti. Questa fase viene svolta dalla Route Maintenance. SSR. L'operazione di Route Discovery avviene col la selezione di percorsi, in base alla forza del segnale. Il protocollo SSR è formato da due protocolli cooperativi che sono: DRP Dynamic Routing Protocol SRP Static Routing Protocol DRP è responsabile di monitorare e mantenere sia la stabilità del segnale SST (Signal Stability Table) sia la tabella di routing RT (Routing Table). Tutte le trasmissioni sono ricevute e processate dal protocollo DRP, il quale si preoccupa di aggiornare le due tabelle. Conclusa questa fase, DRP rimane in attesa nchè non riceve i pacchetti dati dal protocollo SRP, che ha come compito quello di processare tali pacchetti. Un'altra fase importante del protocollo SSR è la gestione dei link failure. Quando un link fallisce dentro la rete, i nodi intermedi sono tenuti ad inviare messaggi di errore, per segnalare al nodo che ha iniziato la fase di Route Discovery qual è il canale di comunicazione che ha fallito. Una volta ricevuti questi cambiamenti, il mittente inizierà la ricerca di un nuovo percorso per giungere a destinazione. Data la logica del protocollo, se si riesce ad arrivare al nodo destinazione dopo l'avvento di un link failure, la sorgente è tenuta a trasmettere in broadcast a tutti i nodi tale notica. LAR. Il protocollo LAR si avvale del GPS 15 [6], per determinare qual è la posizione di un determinato dispositivo. Vengono deniti inoltre due concetti, ovvero: request zone: zona richiesta, 15 GPS è l'abbreviazione di Global Positioning System (Sistema Globale di Rilevamento della Posizione) è una rete di satelliti lanciata, per uso Militare, dagli USA che viene ora utilizzata in tutto il Mondo. 45

Analisi dei protocolli di routing expected zone: zona supportata. Expected Zone (Xd+ R,Yd+R) R Destinazione (Xd,Yd) Request Zone Sorgente (Xs,Ys) Figura 3.6: Protocollo LAR Questo protocollo fa delle severe assunzioni. Come prima cosa si assume che il mittente sappia la posizione della destinazione e la velocità di trasmissione per giungervi. Inoltre nella zone expected viene denito sia la posizione del nodo di destinazione sia la velocità di trasmissione per giungere a destinazione. Nella Figura 3.6 tale zona è individuata dal rettangolo più piccolo, mentre la request zone dal rettangolo più grande, in esso sono inclusi sia la posizione del mittente (Xs,Ys) sia la zone expected contenente il nodo di destinazione(xd, Yd). LAR limita la ricerca di un nuovo percorso in un'area ristretta, così da ridurre il traco di segnalazione. PAR La scoperta di un percorso nell'algoritmo PAR è vincolata dal livello di batteria dei singoli dispositivi. Ciò viene preso come metrica di routing. In tale algoritmo si cerca di: 46 minimizzare l'energia che si consuma per inviare un pacchetto, massimizza il tempo prima che venga partizionata la rete,

minimizza la varianza in un nodo, minimizza il costo per pacchetto, minimizza il massimo costo di un nodo. 3.6 Algoritmi Reactive Come viene evidenziato dalla Figura 3.7, il processo di Route Discovery si basa sulla scoperta di un percorso in cui il livello della batteria è più elevato. Verrà scartato infatti il cammino dove è presente un dispositivo, in cui il livello di batteria è molto basso. L'utilizzo di questo algoritmo quindi non è da consigliare in una rete composta dai soli dispositivi quali PDA e Smartphone. + + - - + + - + + + - - Figura 3.7: Protocollo PAR - RDMAR. Il protocollo di routing RDMAR è basato sul calcolo della distanza stimata tra i nodi, limitando così il ooding di pacchetti nella fase di Route Discovery. In RDMAR si assume che tutti i nodi sono migranti e aventi la stessa velocità di movimento. Questa assunzione può permettere in pratica di stimare la relativa distanza di percorrenza per giungere a destinazione, che altrimenti porterebbe un notevole dispendioso di tempo. In RDMAR l'operazione di Route Discovery, compatta la trasmissione dei 47

Analisi dei protocolli di routing pacchetti informazione nella ricerca di un percorso per giungere a destinazione. Inoltre quando un link si rompe, il processo di Route Maintenance è usato per riparare l'eventuale percorso formato. I vantaggi dei protocolli Reactive I protocolli Reactive a dierenza dei protocolli Proactive hanno i seguenti vantaggi: creano i percorsi solo ed esclusivamente su richiesta (On- Demand), eliminano l'elevato traco della rete, cosi ch'è la rete non venga inondata dall'invio dei pacchetti informazione, l'assenza di innumerevoli tabelle per memorizzare i dati relativi all'instradamento, permette un minor dispendio di memoria, soprattutto nei riguardi di quei dispositivi che non ne hanno una quantità limitata. AODV. Il protocollo di routing AODV migliora quelle che sono le caratteristiche del protocollo Proactive DSDV, minimizzando il numero di richieste per creare percorsi dal nodo sorgente al nodo destinazione. L'algoritmo, come si è gia detto, inizia la sua logica facendo l'operazione di ooding ad ogni richiesta di route, ciò permette un funzionamento adeguato per reti di piccole dimensioni (cinquanta o cento nodi al massimo), dove ore un basso overhead. TORA. Questo protocollo è stato pensato per minimizzare le azioni, quando ci si trova di fronte a dei cambiamenti topologici della rete. Infatti tale protocollo è molto adatto ad ambienti mobili altamente dinamici. Come si evince dalla Figura 3.8 tra il nodo D e il nodo F è avvenuto un link failure, ma ciò non desta problemi poichè automaticamente il nodo D riesce ad ottenere un collegamento sia con il nodo B che C. L'immediato collegamento del nodo D con gli altri nodi è dovuto grazie all'operazione tempestiva di Route Maintenance. Il protocollo Tora si avvale anche dell'aiuto della metrica, denominata height, che si basa su cinque elementi: 48 un time logico per la gestione dei link failure, un identicatore univoco ID di un nodo, che denisce il nuovo livello a cui ci si referenzia, un indicatore di bit, una propagazione di parametri, un identicatore per il nodo.

3.6 Algoritmi Reactive I primi tre elementi rappresentato collettivamente i reference level 16. Per concludere in TORA non si è totalmente sicuri di garantire che i percorsi siano esenti da cicli, ma si può accertare che saranno almeno di breve durata. B A E (1) D C F G A E B D C F G (2) B C B C A D G A D G (3) E F E F (4) Link Failure Link Reversal Figura 3.8: Protocollo TORA SSR. SSR si comporta come DSR e AODV quando si verica un link failure. La sorgente si mobilita ad inviare dei messaggi di aggiornamento, per informare che i nodi coinvolti nel percorso possano aggiornare le tabelle SST e RT. LAR Il protocollo LAR deriva dal protocollo DSR. In questo protocollo si è cercato di migliorare il ood iniziale per la ricerca di un percorso. Se si è inoltre a conoscenza della posizione (anche approssimata) della destinazione, si cerca di mandare i pacchetti di richiesta verso quella direzione, provando a coprire un'area tanto più ampia quanto più è imprecisa la conoscenza della posizione. 16 Si creano ogni volta che un nodo perde il suo ultimo downnstream a causa di un link failure. 49

Analisi dei protocolli di routing PAR. L'unica proprietà che ha il protocollo PAR è l'essere conveniente se si sceglie di adottare dispositivi con un'alta durata di batteria, poichè riesce ad minimizzare l'energia che si consuma nell'invio di pacchetti. RDMAR. L'utilizzo del GPS è considerato un vantaggio perchè riesce a determinare con esattezza la posizione del nodo di destinazione. Gli svantaggi dei protocolli Reactive Di seguito verranno menzionati gli svantaggi dei singoli protocolli. AODV. Non viene garantito che i percorsi siano i più corti e a causa del funzionamento On-Demand, alcuni pacchetti dati potrebbero essere persi nchè non si riesce a trovare un percorso per la destinazione. Inoltre per reti composte da più di 100 dispositivi si ha un alto overhead dovuto dalla propagazione di pacchetti di richiesta da parte del nodo sorgente. TORA. Il tempo di creazione da parte del protocollo nella creazione del grafo è eccessiva. Inoltre i percorsi oerti non sono sicuramente ottimali, e anche in questo protocollo di routing c'è la possibilità della formazione di loop. SSR. Nel protocollo SSR c'è un dispendio di tempo notevole quando si è in presenza di canali comunicativi deboli, poichè come precedente citato tale protocollo seleziona i percorsi solo ed esclusivamente se la potenza del segnale è alta. LAR LAR purtroppo non permette il suo utilizzo se non si è provvisti del Global Positioning System. PAR Non è indicato per chi volesse usare dispositivi mobili come PDA e Smartphone, poichè la loro batteria dura all'incirca 60min. Inoltre questo protocollo massimizza il tempo per partizionare la rete. RDMAR. I limiti che vengono attribuiti a tale algoritmo sono tre: 50 la distanza stimata è in funzione della previsione della distanza stessa; l'assunzione di una velocità ssata dei dispositivi mobili; si deve ssare un range di trasmissione.

3.7 Protocolli Hybrid 3.7 Protocolli Hybrid I protocolli Hybrid cercano di unire quelli che sono i vantaggi dei protocolli Proactive e Reactive. Di seguito verrà descritto solo il protocollo ZPR - Zone Routing Protocol poichè ad oggi, questa famiglia di protocolli è molto dicile da implementare e basa il suo funzionamento sulla cooperazione dei protocolli Reactive e Proactive. Protocollo ZPR. Il protocollo ZPR usa una routing zone, (letteralmente zona di routing), che può essere pensata simile al menzionato utilizzo dei clusters, con l'eccezione che ogni nodo si comporta come un cluster head, potendo essere quindi membro di un qualsiasi cluster. Le zone di routing possono essere sovrapposte. Ogni nodo specica una zona radio in termini di radio hops 17. Le dimensioni di una zona di routing possono andare ad incidere sulle prestazioni della comunicazione della rete ad hoc. ZPR utilizza nella zona di routing uno dei protocolli di instradamento Proactive. Ciò fa evincere che ogni dispositivo deve avere a disposizione delle tabelle all'interno delle quali vengono memorizzati i percorsi per raggiungere i nodi all'interno della zona. Gli aggiornamenti dei percorsi (in caso di cambiamenti topologici della rete o in caso di link failure), vengono eettuati dai singoli nodi all'interno della zona di routing. Per realizzare invece la ricerca dei nodi (operazione di Route Discovery), che si trovano in zone diverse, viene utilizzato uno dei protocolli Reactive. Il protocollo ZPR si avvale dell'aiuto di tre sotto-protocolli, che sono: un protocollo Proactive denominato IARP (IntrAzone Routing Protocol). Il compito principale è assicurare che ogni nodo, dentro una zona di routing, abbia a disposizione una tabella di routing consistente e che venga aggiornata periodicamente per esprimere informazioni attendibili, atte a determinare la ricerca di tutti i nodi all'interno della zona. Un protocollo Reactive denominato IERP (IntEr Routing Protocol). Il suo compito è eettuare la ricerca sia di nodi in altre zone, sia la ricerca di un percorso per giungere a destinazione. La Figura 3.9 presenta un possibile scenario. I cerchi identicano univocamente le tre zone X, Y, Z, che come si nota sono sovrapposte e al loro interno si trovano alcuni dispositivi. La ricerca di un percorso On-Demand viene eettuata dai nodi posizionati sui bordi di una zona (border node), che si preoccupano di reperire le informazione riguardanti i nodi risiedenti in altre zone. Ciò 17 I radio hops, identicano sempre, come è stato precedentemente illustrato, quanti salti un nodo è obbligato a fare per arrivare al nodo destinazione. 51

Analisi dei protocolli di routing Border Node Border Node Zona dei nodi Y Zona dei nodi X Zona dei nodi Z Figura 3.9: Protocollo ZPR non avviene tramite query broadcast 18, ma tramite l'invio di messaggi dai nodi marginali ai nodi posizionati all'interno di altre zone. BRP Bordercast Resolution Protocol. Per concludere il protocollo di routing ZPR, teoricamente, ha la possibilita' di ottimizzare la gestione sia di molti dispositivi che di un numero di dispositivi piu' stretto, ma allo stato attuale è molto dicile da implementare, poichè non si è ancora stabilito uno standard di utilizzo, cioè permettere la cooperazione delle due famiglie di protocolli Reactive e Proactive. 3.8 Protocollo DSR Nel seguente paragrafo verranno prima di tutto descritte le funzionalità del protocollo di routing DSR, analizzate le due principali operazioni di Route Discovery e Route Maintenance e poi in ultimo spiegato il motivo per il quale si è scelto di implemantarlo. 52 18 Continue domande trasmesse a tutti i nodi.

3.8 Protocollo DSR 3.8.1 Funzionamento generale Il protocollo DSR fa parte della famiglia dei protocolli Proactive, per cui i nodi che intendono conoscere un determinato percorso devono farne esplicitamente richiesta. Ogni dispositivo possiede una route cache nella quale vengono memorizzati una serie di percorsi atti ad arrivare al nodo di destinazione. In questa tabella i percorsi sono mantenuti per un determinato periodo di tempo (scelta che viene gestita dal programmatore): quando questo tempo scade, il percorso, è cancellato se non viene referenziato. La prima fase che un nodo sorgente utilizza nella determinazione di un percorso (se questo non è già memorizzato in route cache) è la scoperta dei vicini. In questa fase si riesce a determinare quali sono i dispositivi che si trovano nel range trasmissivo del nodo che ha richiesto un route. Una volta scoperti i vicini, si inizia la fase di Route Discovery. Di seguito verranno descritti dettagliatamente i passi che bisogna compiere per arrivare a determinare un percorso. 3.8.2 Determinazione di un percorso Per costruire un source route nel quale si invierà un pacchetto dati, le tappe da eseguire sono le seguenti: si verica se nella route cache è presente o meno un percorso, se lo si trova, si utilizza questo percorso per inviare il dato al nodo destinazione; se non si ha memorizzato un percorso in route cache, si esegue la scoperta dei vicini. Se un vicino è proprio il nodo di destinazione, si invia il dato; se la fase di scoperta dei vicini non è andata a buon ne si procede con l'operazione di Route Discovery. In generale un nodo inoltra una richiesta, denominata RREQ (route request), quando o nella sua route cache non ha un percorso per giungere a destinazione o la scoperta dei vicini non ha dato come esito il nodo destinazione. 3.8.3 Operazione di Route Discovery Questa fase permette di scoprire dinamicamente un percorso verso un altro host, sia se l'host di destinazione è ricercabile direttamente dentro il suo stesso wireless trasmission range, sia se è necessario utilizzare nodi intermedi per ottenere il percorso. Un host inizia l'operazione di Route Discovery trasmettendo un RREQ ai nodi che si trovano nel suo stesso wireless trasmission range. 53

Analisi dei protocolli di routing Il pacchetto RREQ identica sia il mittente e sia quale è il destinatario della richiesta. Se la RREQ riesce ad ottenere un percorso, allora viene mandata indietro al mittente una RREP (route reply), nella quale è memorizzato il percorso completo sorgente-destinazione. Il pacchetto RREQ è composto da: indirizzo del mittente, indirizzo della destinazione request ID che indica il numero generato dal mittente, che identica univocamente una RREQ, route record che memorizza in un record la sequenza dei salti necessari per raggiungere l'host di destinazione. Tali dati sono ricavati attraverso la Route Discovery. Per scoprire ed evitare che ci siano RREQ duplicate nella ricerca di un percorso, ogni host mantiene una lista delle coppie (indirizzo sender, request id) ricevute dalle varie RREQ. Quando un device riceve una richiesta si può comportare nei seguenti modi: se la coppia indirizzo sender,request ID è nota nella lista, allora l'host scarta la richiesta senza processarla; se l'indirizzo dell'host è già presente nel route record di una richiesta, allora scarta la richiesta senza processarla; se la richiesta giunge alla destinazione, allora il route record contiene il percorso dal quale la richiesta è giunta. Inne, la destinazione copia il percorso memorizzato nel route record e lo pone in una RREP che invierà al mittente; se la richiesta giunge ad un host intermedio, esso aggiunge al route record il suo indirizzo e inoltra la richiesta. Anché sia fornita una RREP al mittente, la destinazione deve possedere un percorso per la sorgente. Se la destinazione ha nella propria route cache un percorso per il mittente, invia la RREP su questo percorso. Diversamente, se non si possiede un percorso, può essere utilizzato quello memorizzato nel route record della RREQ ricevuta. Questo approccio richiede che la comunicazione tra coppie di host sia bidirezionale. Nella Figura 3.10 viene mostrata l'operazione di Route Discovery all'interno di una rete composta da otto dispositivi. Nel primo passo, si evince la trasmissione da parte del nodo sorgente (nodo 1) del pacchetto route record. I nodi successivi controllano se nella loro route cache è presente un percorso 54

3.8 Protocollo DSR per giungere al nodo 8 (si è supposto che tutti i nodi hanno la route cache vuota), in seguito eseguono la fase di scoperta dei vicini (anche qui si voluto far notare che non si arriva subito al nodo di destinazione), e come ultimo anche loro inviano i pacchetti route record n tanto che non si giunge al nodo destinazione. Una volta giunti al nodo 8 la seconda fase è la trasmissione del pacchetto RREP, destinato al nodo sorgente, il quale una volta ricevuto potrà utilizzare tale percorso per inviare il dato al nodo 8. Un ulteriore approccio oerto dal protocollo DSR per mandare un pacchetto di risposta al nodo sorgente (RREP), può essere quello di utlizzare la modalità piggyback. Questa tecnica permette di inviare all'interno del pacchetto RREP anche quello RREQ, ma di ciò verra trattato nel paragrafo 3.8.4. Sorgente N3 N1 N1 N3 N2 N1,N3 N1,N3 N1,N2 N1,N3,N4 N4 N6 N5 N7 N1,N3,N6 N1,N2,N5 N1,N3,N4 N8 Destinazione N1,N3,N6,N7 1) Pacchetto RouteRecord Durante la Route Discovery N1,N2,N5,N8 Sorgente N1 N1,N2,N5,N8 N2 N5 N4 N1,N2,N5,N8 N8 Destinazione 2) Propagazione del pacchetto RouteReply con il pacchetto RouteRecord N3 N6 N7 Figura 3.10: Protocollo DSR 3.8.4 Piggybacking sulla Route Discovery Abbiamo visto, che quando un host vuole inviare un pacchetto dati ad un altro host, prima controlla se nella sua cache è presente un percorso, poi se non lo è, comincia l'operazione di Route Discovery. L'attesa del pacchetto RREP da parte del nodo richiedente può essere ridotto, usando la tecnica di piggyback. Nel pacchetto RREP infatti ci sono anche i pacchetti RREQ, ciò per evitare che una volta arrivati a destinazione, questa rifaccia nuovamente la scoperta di un percorso per giungere al nodo sorgente. 55

Analisi dei protocolli di routing Questa tecnica se pur molto utile bisogna usarla con cautela. Attualmente si usa la tecnica di piggybacking quando si inviano o pacchetti RREP o pacchetti RRER (pacchetti di errore), dato che sono per natura piccoli di dimensione. 3.8.5 Route Maintenance Gli algoritmi di routing Reactive precendentemente descritti usano uno scambio continuo di messaggi per noticare lo stato della rete. In questo algoritmo ciò non è eettuato. Il protocollo DSR quando riesce a trovare un percorso, utilizzata una procedura di Route Maintenance per monitorare le operazioni da eettuare sul percorso, ed informare sia il mittente, sia i nodi intermedi di qualsiasi errore di routing. Dato che le reti wireless sono per natura meno adabili delle rete con li, molte di esse utilizzano un riconoscimento hop-by-hop a livello data link, per scoprire e ritrasmettere i pacchetti persi o danneggiati. In queste reti, la Route Maintenance può essere facilmente fornita ad ogni hop. Se il livello data link riscontra un problema di trasmissione, l'host manda un pacchetto RRER (route error) al mittente che ha provocato l'errore. Il pacchetto RRER contiene gli indirizzi dei due host posti alle estremità del link, che hanno generato l'errore. Quando un host riceve un RRER, l'hop che ha generato l'errore è rimosso dalla route cache dell'host, e tutti i percorsi che contengono l'hop che ha generato l'errore sono troncati in quel punto. Esistono diverse modalità per dichiarare l'avvento di un errore: 56 passive acknowledgement, se la rete wireless non supporta un riconoscimento a basso livello, dopo che è stato inviato un pacchetto, l'host è in grado di capire se l'host seguente sta trasmettendo di nuovo il pacchetto lungo il percorso assegnato; viene usato un bit, incluso nell'header del pacchetto, per permettere ad un host di richiedere al nodo seguente una risposta di avvenuta ricezione; quando un host intermedio riceve un pacchetto RREP, l'host deve avere un percorso verso il mittente del pacchetto originale, per poter inviare un pacchetto RRER. Se questo host ha memorizzato nella sua route cache un percorso, utilizza questo per inviare il pacchetto, altrimenti se l'host non ha il percorso nella route cache, per inviare il pacchetto d'errore potrebbe invertire il percorso che è stato usato per giungere a lui dalla sorgente. Si potrebbe usare piggibacking come nel caso di un pacchetto RREP.

3.8 Protocollo DSR Un'altra opzione per restituire un pacchetto d'errore è quello di salvare localmente il route error in un buer, eseguire l'operazione di Route Discovery per trovare il mittente originale, e in seguito mandare il pacchetto route error attraverso il percorso trovato. 3.8.6 Miglioramenti delle operazioni Di seguito verranno illustrate le ottimizzazioni possibili per le operazioni di Route Discovery e di Route Maintenance. I miglioramenti che si possono eseguire sulla route cache di un host sono: riguardanti i dati, che possono essere immagazzinati in ogni formato; un host può sempre aggiungere un nuovo percorso in route cache. Di quest'ultima miglioria si andrà ad analizzare quali sono le situazioni tipiche che portano un nodo ad aggiungere nella sua route cache nuovi percorsi. In particolare un nodo aggiunge i percorsi in route cache se: un host ottiene il percorso mediante una RREP; un nodo deputato ad avanzare un pacchetto dati controlla l'intero percorso (che dovrà arontare il pacchetto per giungere a destinazione). In questo caso il nodo può memorizzare quel dato percorso, un nodo che inoltra una RREP, può rilevare il percorso memorizzato nel route record e memorizzarlo nella sua route cache. Un host inoltre usa la sua route cache per evitare la propagazione nella rete di copie uguali di pacchetti RREQ, ricevuti dai suoi vicini. Un'ultima ottimizzazione sarebbe quella di aggiungere in un record il numero massimo di hop, sui quali un pacchetto può essere propagato. Questa miglioria potrebbe essere molto importante per ridurre il numero di richieste propagate nella fase di Route Discovery. Per eettuare questa ottimizzazione si seguono i seguenti passi: per compiere l'operazione di Route Discovery, inizialmente si manda la RREQ con un limite di hop posto a uno; se dopo un certo intervallo di tempo, non si riesce ad avere una risposta (RREP) alla RREQ formulata nel passo precedente, allora viene mandata una nuova richiesta con un numero massimo di salti ssato (di solito si sceglie come numero massimo di salti 10). 57

Analisi dei protocolli di routing 3.9 Motivazione della scelta del protocollo Nell'appendice B vengono riportate quattro delle più salienti esperienze eettuate, sia in ambienti chiusi che in spazi aperti (senza intralci di trasmissioni radio) che hanno permesso di avere l'assoluta certezza, che nelle reti ad hoc, non esistendo infrastrutture, non è possibile avere una comunicazione pointmultipoint. Ossia ciò non è possibile se nonchè si usufruisca di un protocollo di routing. E' per tale motivazione che si è scelto di sviluppare il protocollo Reactive DSR. La scelta è ricaduta sul protocollo DSR, poichè per prima cosa, appartiene alla famiglia dei protocolli Reactive, di cui si sono elencati i vantaggi nel paragrafo 3.6. In una rete MANET, l'idea della creazione di percorsi solo On-Demand, è sicuramente più attuabile, rispetto ad un continuo scambio di informazioni ad intervalli di tempo ssati. In secondo luogo, il protocollo DSR, rispetto a tutti i protocollo visionati, offre non una ma tre diverse alternative per garantire la ricerca di un percorso. Queste fasi sono: ricerca in route cache; permettere un notevole ridimenzionamento del traco di pacchetti nella rete, poichè se in route cache è presente un percorso per giungere a destinazione automaticamente si instradano pacchetti di informazione. Scoperta dei vicini; consente ad un nodo la ricerca dei vicini nel suo range trasmissivo. Se infatti il nodo di destinazione è un vicino, il nodo mittente invia immediatamente pacchetti contenenti i dati. Route Discovery; questa fase consente di cercare un percorso tra nodi che non si trovano nello stesso range trasmissivo. Inoltre il protocollo DSR, è appropriato per una rete dove i dispositivi che la compongono sono all'incirca cinquanta e per i nostri scopi, ovvero una rete composta al massimo pochi dispositivi (circa venti), è sembrato quello che più si adattava bene a queste esigenze. Ma il motivo più importante è il mantenimento da parte di tutti i dispositivi di una sola tabella, denominata route cache. Tale route cache mantiene tutte le informazioni necessarie a far si che si abbiano a disposizione i percorsi necessari per giungere ad un nodo destinazione. Il mantenimento di un'unica tabella è un grande vantaggio, dovuto anche al fatto che l'applicazione pensata fa uso soprattutto di dispositivi mobili, come palmari; con bassa capacità di memoria (circa 128 MB), quindi tenere in memoria solo una tabella, risulta molto utile in termini di risparmio di risorse. 58

3.9 Motivazione della scelta del protocollo DSR permette inoltre, che la comunicazione tra due host possa essere fatta, utilizzando percorsi più brevi, come pure permette di eliminare, tutti i problemi relativi alla creazione di cicli nel percorso, proprio perchè vi è il continuo controllo da parte dei nodi, nei confronti dei pacchetti RREQ, RREP, RRER. Infatti se un device si accorge di aver già ricevuto uno di questi pacchetti non fa nient'altro che riutare. L'operazione di Route Maintenance invece, determina i link failure nella rete, così da permettere ai dispositivi di cercare un'alternativa, una volta noticato il fallimento. Concludendo il protocollo DSR è sembrato quello che più si adatta sia allo scenario proposto nel Capitolo 2, riguardante la squadra di soccorso, che deve necessariamente avere a disposizione PDA, laptop, etc. sia alle scelte di progetto discusse nel Capitolo 4. 59

Capitolo 4 Progetto 4.1 Speciche del progetto Come abbiamo menzionato nel Capitolo 2, le reti ad hoc sono reti senza nessun tipo di centralizzazione, altamente dinamiche, che però sorono, ad oggi, dell'assenza del concetto di instradamento(almeno con il software a disposizione per esse). Attualmente le reti MANET utilizzano solo due livelli della pila ISO/OSI: il livello sico, che denisce gli aspetti che riguardano la trasmissione dei bit; il livello di collegamento, che si occupa della trasmissione dei pacchetti del livello sovrastante, del riconoscimento di errori di trasmissione e dei meccanismi di correzione tramite ritrasmissione. L'applicazione che viene presentata mette a disposizione una API (Application Programming Interfaces), che implementa un vero e proprio strato di rete 1, atto a gestire l'instradamento dei messaggi. L'idea è di avere tra le mani un software che permetta ai dispositivi, che compongono la rete MANET, di comunicare senza preoccuparsi dei problemi relativi al range trasmissivo. 4.2 Speciche funzionali La specica delle funzionalità dell'applicazione vengono espresse utilizzando la semantica UML [5]. 4.2.1 API dell'applicazione Nella Figura 4.1 viene riportato lo Use Case generale, in cui vengono evidenziate le sei sezioni principali dell'applicazione, che sono: 1 Si pensi al linguaggio di programmazione C, che ore come system call la socket(), la send(), la bind(), la connect() e l'accept(). 61

Progetto Sezione relativa all'operazione Bind. Tale operazione permette di identicare le applicazioni che lavorano su uno stesso dispositivo. Sezione relativa all'operazione Close. Tale operazione permette di chiudere una determinata applicazione che lavora sul dispositivo. Sezione relativa all'operazione IsLinked. Tale operazione verica la presenza o meno di un determinato dispositivo nella rete. Sezione relativa all'operazione Receive. Tale operazione permette di ricevere dati quando il dispositivo ne viene in possesso. Sezione relativa all'operazione Release. Tale operazione permette di chiudere denitivamenete l'applicazione, rilasciando tutte le risorse utilizzate dalla stessa. Sezione relativa all'operazione Send. Tale operazione permette di inviare dati sfruttando la logica del protocollo di routing. Figura 4.1: Use case generale dell'applicazione Nel seguito tale diagramma verrà esploso per rappresentare al meglio le funzionalità di ogni singola sezione, mediante l'utilizzo dei Sequenze Diagram. 4.2.2 Diagram Package Nella Figura 4.2 vengono mostrati gli otto package, che sono: 62

4.2 Speciche funzionali Figura 4.2: Diagramma dei package Client Device Discovery Manet Reception Server Table Utility Manet Package Il package Manet è utilizzato come strato intermedio tra il livello superiore destinato alle applicazioni (chat, agende, etc.) ed il livello sottostante che si occupa di tutta la logica di rete. In questo package, vi sono due classi. 63

Progetto Classe ManetManager. In questa classe sono contenuti cinque metodi principali che sono: bind(int port): ManetSocket; consente di noticare la presenza di una nuova applicazione, che intende utilizzare il protocollo di routing. close(int port): void; chiude l'applicazione identicata dal numero di porta. release(): void; permette la totale chiusura delle porte in ascolto sul lato server e la chiusura di tutti i Thread che lavorano nell'aggiornamento delle tabelle. searchmanetsocket(int port):manetsocket; metodo privato non visibile dal livello applicativo, che permette di ricercare una particolare applicazione precedentemente registrata mediante l'operazione di Bind. deletemanetsocket(int port): void; metodo privato non visibile dal livello applicativo, ed utilizzato per cancellare un' applicazione precedentemente memorizzata. Nella Figura 4.3 è riportato il package Manet, con la relativa classe appena citata e la classe ManetSocket. Figura 4.3: Manet Package Classe ManetSocket. In questa classe sono presenti tre metodi molto importanti per la logica dell'applicazione, che sono: 64

4.2 Speciche funzionali islinked(string namedestination): Boolean; avvia la logica per l'individuazione della presenza di un dispositivo sulla rete. receive(structreceive sr): StructReceive; fornisce la logica per permettere la ricezione del dato. send(string namedestination, int portdestination, byte[] data): Boolean; esegue tutta la logica dell'invio del dato verso un altro dispositivo. Device Package Il package Device modella le caratteristiche del dispositivo sico. Come si evince dalla Figura 4.4 tale package ha al suo interno la sola classe Host. Classe Host. In questa classe sono presenti i metodi: deleterowstoreddatatable(): void; cancella una riga contenente tutti i parametri relativi alla spedizione del dato; solitamente questo tipo di aggiornamento viene eettuato quando si è inviato il dato alla destinazione e non si vogliono mantenere dati inutili in tabella. destinationdiscovery(string namedestination, int portdestination, byte[] datainput): Boolean; memorizza i parametri in variabili globali della classe e avvia la logica dell'operazione di Send. Questo è il metodo che fornisce il risultato della Send al livello superiore. linkedroutediscovery():void; viene inoltrata una Route Discovery. A dierenza della logica riguardante l'operazione di send, in questo caso non si ricerca un percorso in Route Cache, poichè molte volte i percorsi memorizzati in RouteCache possono generare fallimenti di link. routediscovered(): void; metodo invocato quando nella Route Cache è presente un percorso per la destinazione specicata. In questo metodo è implementata la logica di costruzione del pacchetto comando e del pacchetto dato. routediscovery(): void; metodo invocato quando nella Route Cache non è presente un percorso, ed è necessario inoltrare una operazione di Route Discovery. Viene eettuata la scoperta dei vicini, e controllato se tra i vicini è presente l'indirizzo destinazione cercato; se l'indirizzo è presente viene inviato direttamente il dato senza eettuare una Route Discovery, viceversa tale operazione viene avviata. waitresultislinked(string namedestination): Boolean; coordina l'operazione di islinked per vericare la presenza di un particolare dispositivo. 65

Progetto waitresultsend(): Boolean; gestisce l'operazione di Send. Sono effettuati vari cicli per permettere che il dato sia inviato alla destinazione; verica se un percorso è presente nella Route Cache oppure se è necessario eettuare una Route Discovery. Figura 4.4: Device Package Discovery Package Nel package Discovery sono implementate tutte le risorse necessarie per effettuare operazioni di ricerca di percorsi sulla rete. Le classi riportate in Figura 4.5 compongono il package appena citato, e sono: 66 DiscoveryDeviceNeighbours; implementa la logica delle operazioni riguardanti la scoperta dei dispositivi vicini, ossia quei dispositivi che si trovano nello stesso range trasmissivo del dispositivo che eettua la ricerca. PacketRREP; memorizza e implementa tutto ciò che occorre per manipolare pacchetti di risposta RREP.

4.2 Speciche funzionali PacketRREQ; memorizza e implementa tutto ciò che occorre per manipolare pacchetti di richiesta RREQ. PacketRRER; memorizza e implementa tutto ciò che occorre per manipolare pacchetti di notica di link fallito RRER. PiggyBackingResultSend; implementa la costruzione di nuovi pacchetti di richiesta, o l'instradamento degli stessi; questi pacchetti sono necessari, per cercare di far arrivare la notica dell'avvenuta ricezione del dato, al nodo mittente dell'operazione Send. PiggyBackingRREP; implementa la costruzione di nuovi pacchetti di richiesta, o l'instradamento degli stessi; questi pacchetti sono necessari, per cercare di far arrivare il pacchetto di risposta RREP al nodo mittente della Send. RouteDiscovery; avvia una nuova operazione di Route Discovery, inviando a tutti i vicini il comando 3. RouteDiscoveryLinked; avvia una nuova operazione di Route Discovery, inviando a tutti i vicini il comando 9 Figura 4.5: Discovery Package 67

Progetto Classe DiscoveryDeviceNeighbours. In questa classe sono presenti i metodi: assegnazionevicini(string addresshost): ArrayList; invocato ogni volta che si desidera eettuare la scoperta dei dispositivi vicini; questo metodo richiama uno dei due metodi descritti in seguito, a seconda della scelta implementativa eettuata dal programmatore. discoveryvicini(string addresshost): ArrayList; eettua la scoperta dei vicini, stabilendo connessioni verso gli altri dispositivi senza inviare nessun comando, ma vericando solamente l'eventuale presenza del dispositivo. La risposta riguardante la presenza o meno di un dispositivo, la si ottiene dopo 100 millisecondi. scopertavicini(string addresshost): ArrayList; eettua la scoperta dei vicini, inviando il comando 1 e attendendo in risposta il comando 2. Classe PacketRREP. In questa classe vengono implementati tre metodi: createrouterecord(string[] rreq, string route): void; metodo privato che costruisce il Route Record del pacchetto RREP da inviare. getrrep(): string; restituisce il pacchetto RREP pronto per essere inviato. Il pacchetto viene memorizzato in una stringa, nella quale ogni parametro viene separato dal successivo tramite una virgola. substitutionrouterecord(string route): void; metodo privato utilizzato per sostituire il Route Record di un pacchetto RREP. Questo metodo è utilizzato nelle operazioni riguardanti il fallimento di un link sul Route Record sostituito. Classe PacketRREQ. In questa classe vengono implementati tre metodi: 68 createrouterecord(string route): void; metodo privato che costruisce il Route Record del pacchetto RREQ da inviare. Questo metodo viene utilizzato dal nodo mittente, cioè da colui che avvia l'operazione di Route Discovery. createrouterecord(string[] rreq, string route): void; aggiunge al Route Record del pacchetto RREQ ricevuto il proprio indirizzo IP. Si evince che questo metodo è utilizzato dai nodi intermedi di un operazione di Route Discovery. getrreq(): string; restituisce il pacchetto RREQ pronto per essere inviato. Il pacchetto viene memorizzato in una stringa, nella quale ogni parametro viene separato dal successivo tramite una virgola.

4.2 Speciche funzionali Classe PacketRRER. In questa classe sono presenti quattro metodi: getheaderror(): string; restituisce l'indirizzo del dispositivo che si trova in testa al link fallito. getfooterror(): string; restituisce l'indirizzo del dispositivo che si trova in coda al link fallito. getlinkfailure(): string; restituisce l'intero link che ha generato il fallimento. getremoveroutes(): void; aggiorna la Route Cache, noticando il link fallito. Classe PiggyBackingResultSend. In questa classe è presente il solo metodo: startpiggybacking(): void; inoltra l'operazione di mantenimento per inviare il risultato dell'operazione di Send, inviando il comando 8. Classe PiggyBackingRREP. Nella seguente classe è implementato il metodo: startpiggybacking(): void; inoltra l'operazione di mantenimento per inviare il pacchetto RREP, inviando il comando 7. Classe RouteDiscovery. In questa classe è presente il metodo: startroutediscovery(): void; avvia l'operazione di Route Discovery, inviando il comando 3. Classe RouteDiscoveryLinked. In questa ultima classe è implementato il solo metodo: startdiscoverylinked(): void; avvia l'operazione di Route Discovery, inviando il comando 9. Client Package In questo package viene implementata la logica Client del dispositivo. Le classi che si occupano di eseguire questa logica sono: ClientCommand; in cui si esegue tutta la logica dell'invio di un comando. ClientData; in cui si esegue tutta la logica dell'invio di un dato. Nella Figura 4.6 viene riportato il seguente package. 69

Progetto Figura 4.6: Client Package Classe ClientCommand. In questa classe sono presenti tre metodi: discovery(): void; eettua una connect all'indirizzo specicato. neighbourpresence(): Boolean; metodo utilizzato per eettuare la scoperta dei vicini. Solitamente viene usato quando si sceglie di utilizzare il metodo discoveryvicini descritto precedentemente. sendingcommand(): void; implementa la vera e propria logica dell'invio del comando. Classe ClientData. In questa classe è presente il metodo: sendingdata(): void; implementa la vera e propria logica dell'invio del dato. Server Package Il package Server implementa tutta la logica server del dispositivo; le classi che si occupano di tale compito sono: CommandProcessor; in cui vengono analizzati tutti i comandi. ServerCommand; si occupa della ricezione dei comandi. ServerData; si occupa della ricezione dei dati. Nella Figura 4.7 vengono riportate le classi del package Server. Classe CommandProcessor. In tale classe è presente il solo metodo: interpretationcommand(): void; il quale è deputato ad analizzare i comandi che uno dopo l'altro arrivano sulla porta comandi (10000). 70

4.2 Speciche funzionali Figura 4.7: Server Package Classe ServerCommand. In questa classe sono presenti tre metodi: close(): void; chiude la porta comandi (10000). receptioncommand(): string; ottiene il comando inviato dal client attualmente connesso. serverlistenercommand(): void; implementa la logica per attendere connessioni da parte dei vari Client. Classe ServerData. In essa sono presenti i seguenti quattro metodi: close(): void; si occupa della chiusura della porta dati. drawdata(byte[] data): void; suddivide il pacchetto dati arrivato, in maniera da poterlo memorizzare nella Memory Data. receptiondata(): byte[]; implementa la logica di ricezione del dato. serverlistenerdata(): void; implementa la logica di attesa di connessioni da parte dei vari Client. 71

Progetto Reception Package In questo package si implementano tutte le logiche che si sviluppano quando un dispositivo riceve un comando. Le classi che compongono questo package sono otto, in particolare: ReceptionData ReceptionPiggyBackingResultSend ReceptionPiggyBackingRRER ReceptionResultSend ReceptionRREP ReceptionRREPLinked ReceptionRREQ ReceptionRREQLinked Nella Figura 4.8viene riportato in maniera dettagliata il seguente package. Classe ReceptionData. destinationdata(): void; in questo metodo in primo luogo viene prelevato il dato dalla Memory Data; poi lo stesso viene posto nel buer dal quale l'operazione receive preleva i dati arrivati. In secondo luogo viene inviata verso il nodo mittente del dato, la risposta di avvenuta ricezione dello stesso. intermediatedata(): void; si occupa di instradare il dato, prelevato dalla Memory Data, al nodo indicato sul percorso ottenuto. Nel caso si verichi un fallimento di link viene eettuato un aggiornamento della Route Cache. startanalysisdata(): void; verica se il dispositivo è un nodo intermedio o il nodo destinazione, nel percorso utilizzato per inviare il dato. Classe ReceptionPiggyBackingResultSend. 72 destinationrreqpiggybacking(): void; il dispositivo ottiene il risultato della send e lo memorizza in un buer. intermediaterreqpiggybacking(): void; il dispositivo è un nodo intermedio, per questo motivo il metodo si occupa solamente di passare il medesimo pacchetto ai suoi vicini.

4.2 Speciche funzionali Figura 4.8: Reception Package 73

Progetto startanalysisresultsend(): void; in primo luogo viene vericato che il pacchetto RREQ di mantenimento sia arrivato per intero, poi che il dispositivo non sia il mittente del pacchetto ed inne che il dispositivo non abbia già ricevuto il pacchetto precedentemente. Se tutte le veriche danno un esito positivo, viene controllato se il dispositivo è o meno la destinazione del pacchetto RREQ. Classe ReceptionPiggyBackingRREP. destinationrreqpiggybacking(): void; il nodo ottiene il pacchetto RREP e preleva da esso il percorso per inoltrare il dato. intermediaterreqpiggybacking(): void; il dispositivo è un nodo intermedio, per questo motivo il metodo si occupa solamente di passare il medesimo pacchetto, ai suoi vicini. startanalysisrreq(): void; in primo luogo viene vericato che il pacchetto RREQ di mantenimento sia arrivato per intero, poi che il dispositivo non sia il mittente del pacchetto ed inne che il dispositivo non abbia già ricevuto il pacchetto precedentemente. Se tutte le veriche danno un esito positivo, viene vericato se il dispositivo è o meno la destinazione del pacchetto RREQ. Classe ReceptionResultSend. destinationresultsend(): void; il dispositivo ottiene il risultato della send e lo memorizza in un buer. intermediateresultsend(): void; viene passato il pacchetto ottenuto, all'hop successivo. Nel caso in cui questo link fallisca, viene avviata la procedura di mantenimento per assicurarsi che il risultato giunga al nodo di destinazione. startanalysisresultsend(): void; verica se il nodo è la destinazione del risultato oppure se è un nodo intermedio; la verica viene eettuata sul percorso inviato nel comando. Classe ReceptionRREP. 74 destinationrrep(): void; viene prelevato il percorso memorizzato nel Route Record del pacchetto arrivato; su questo percorso viene inviato il dato. Se avviene un fallimento sull'hop, viene eettuato un aggiornamento della Route Cache del dispositivo. intermediaterrep(): void; il pacchetto RREP arrivato, viene passato all'hop calcolato sul percorso presente nel comando.

4.2 Speciche funzionali startanalysisrrep(): void; in primo luogo viene vericato che il pacchetto RREP sia arrivato per intero, che il dispositivo non sia il mittente del pacchetto ed inne che il dispositivo non abbia già ricevuto il pacchetto precedentemente. Se tutte le veriche danno un esito positivo, viene vericato se il dispositivo è o meno la destinazione del pacchetto RREP. Classe ReceptionRREPLinked. destinationrreplinked(): void; il risultato dell'operazione islinked viene memorizzato in un buer. intermediaterreplinked(): void; viene passato il pacchetto ottenuto al succesivo hop. startanalysisrreplinked(): void; viene vericato che il pacchetto sia arrivato per intero e che il nodo non sia il nodo mittente del pacchetto stesso. In seguito viene vericato il ruolo del nodo sul percorso ottenuto. Classe ReceptionRREQ. destinationrreq(): void; viene memorizzato in Route Cache il percorso presente nel Route Record del pacchetto, in seguito viene creato il pacchetto di risposta RREP ed inviato. Se l'invio fallisce viene avviata una procedura di mantenimento del pacchetto RREP. intermediaterreqwithoutroute(): void; dopo aver memorizzato il percorso presente nel pacchetto, questo viene passato ai dispositivi vicini del dispositivo. intermediaterreqwithroute(): void; il nodo è intermedio ma ha nella sua Route Cache un percorso per la destinazione, quindi il percorso presente nella Route Cache viene posto come Route Record del pacchetto RREP, che viene inviato al dispositivo mittente del pacchetto RREQ. startanalysisrreq(): void; in primo luogo, viene vericato che il pacchetto RREQ sia arrivato per intero, che il dispositivo non sia il mittente del pacchetto ed inne che il dispositivo non abbia già ricevuto il pacchetto precedentemente. Se tutte le veriche danno un esito positivo, viene controllato se il dispositivo è o meno la destinazione del pacchetto RREQ. 75

Progetto Classe ReceptionRREQLinked. destinationrreqlinked(): void; viene aggiornata la Route Cache, e viene mandata la notica di avvenuta ricezione al nodo mittente dell'operazione islinked. intermediaterreqlinked(): void; viene passato il pacchetto ai nodi vicini del dispositivo, in seguito viene aggiornata la Route Cache. startanalysisrreqlinked(): void; in primo luogo, viene vericato che il pacchetto sia arrivato per intero, poi che il dispositivo non sia il mittente del pacchetto ricevuto e inne che il dispositivo non abbia già ricevuto quel pacchetto. Se tutte le veriche vanno a buon ne, viene controllato se il dispositivo è un nodo intermedio oppure destinazione. Utility Package In questo package vengono implementate delle operazioni utilizzate dalle varie classi presenti nel codice. Tutti i metodi del package sono statici. In tutto sono presenti sette classi che sono: DataOperation FileOperation PacketOperation ParametresOperation RouteOperation StoredResult StructReceive Classe DataOperation. 76 createdatapackets(arraylist arraypacketdata, string timestamp): ArrayList; crea i pacchetti dato da inviare verso la porta dati dei server. Ogni pacchetto è formato da tre campi; il numero d'ordine, il timestamp, e il dato. I numero d'ordine è utilizzato lato server per ricomporre il dato nel giusto ordine; il timestamp, è utilizzato per prelevare i dati dalla Memory Data; il dato inne può essere o l'intero dato da spedire oppure una parte della suddivisione. Tutti questi parametri sono memorizzati in un ArrayList. llpacket(byte[] data, int size): byte[]; utilizzato per riempire i pacchetti dato che non raggiungono le dimensioni specicate. I caratteri di riempimento sono spazi.

4.2 Speciche funzionali getsendingdata(string number, string time, byte[] data): byte[]; restituisce il pacchetto dati formato da numero d'ordine, timestamp e dato. sizedata(byte[] data): ArrayList; eettua la suddivisione del dato in più pacchetti. La dimensione del dato in un pacchetto è di 1024 bytes. Classe FileOperation. readcongint(string parameter): int; eettua la lettura dal le con- g.txt, e restituisce il valore trovato come intero. readcongstring(string parameter): string; eettua la lettura dal le cong.txt, e restituisce il valore trovato come stringa. Classe PacketOperation. modifyrouterecord(string addresshost, string[] packet, string route): string; modica il Route Record del pacchetto che gli viene passato. Classe ParametresOperation. gettimestamp(): string; restituisce il timestamp, il quale è formato dalla data del giorno espressa in gg/mm/aaaa e dall'ora in cui è generato; l'ora è così suddivisa hh.mm.ss.ms getrequestid():int; restituisce il request ID, richiesto per le operazioni di Route Discovery. getnumber(int number): string; restituisce il numero d'ordine dei pacchetti dato. Questo numero può essere al massimo 9999. getrequestidmaintenance(): int; restituisce il request ID, richiesto per le operazioni di mantenimento sia del pacchetto RREP sia del risultato della Send. Nella Figura 4.9 sono evidenziate tutte le classi e i metodi del seguente package. Classe RouteOperation. calcolahop(string addressdevice, string route): string; dato un percorso ed un indirizzo IP, il metodo restituisce l'indirizzo IP successivo rispetto all'indirizzo passato come parametro. computeposition(string route, string addressdevice): int; restituisce la posizione occupata in un determinato percorso, dall'indirizzo specicato. Il numero viene restituito come intero. 77

Progetto computerouterecord(string packet): string; restituisce il Route Record del pacchetto passato come parametro. computeroute(string addresssender, string addressdestination, string route): string; dato un percorso e due indirizzi IP, mittente e destinazione, viene restituito il percorso mittente-destinazione. reverseroute(string route): string; restituisce il percorso inverso rispetto a quello passato come parametro. changerouterecord(string packet, string route): string[]; eettua una modica al Route Record di un pacchetto. getpacket(string[] packet): string; converte il pacchetto preso come parametro, in una stringa in cui ogni campo è separato dal seguente da una virgola. Classe StoredResult. getresultislinked(string port): boolean; restituisce se presente, il risultato di un operazione di islinked, avviata da una particolare applicazione. Se non è presente alcun risultato per quell'applicazione allora viene restituito il valore null. getresultsend(string port): boolean; restituisce se presente, il risultato di un operazione di Send, avviata da una particolare applicazione. Se non è presente alcun risultato per quell'applicazione allora viene restituito il valore null. setislinked(string port): void; memorizza il risultato di un'operazione di islinked. setresultsend(string port): void; memorizza il risultato di una operazione di send. Classe StructReceive. 78 getaddress(): string; restituisce l'indirizzo del dispositivo che ha inviato il dato. getport(): int; restituisce il numero di porta dell'applicazione che deve ricevere il dato. setaddress(string address): void; utilizzato per memorizzare l'indirizzo del dispositivo che ha inviato il dato. setdata(byte[] data): void; utilizzato per memorizzare il dato ricevuto.

4.2 Speciche funzionali Figura 4.9: Utility Package Table Package In questo package sono mantenute tutte le tabelle presenti sui dispositivi. Le classi presenti in questo package sono: DeviceTable; memorizza gli indirizzi IP dei dispositivi partecipanti alla rete MANET. DuplicatesTable; memorizza i pacchetti RREQ e RREP che vengono inviati al dispositivo; tutto questo serve ad evitare la loro duplicazione. MemoryData; utilizzata per la sincronizzazione della porta dati e di quella comandi. In essa, infatti, vengono memorizzati i pacchetti dato dal Server Data ed una volta completata la ricezione di tutti i pacchetti, questi ultimi vengono prelevati dal Server Command per avviare le varie logiche di gestione. RouteCache; vengono memorizzati i percorsi per giungere al nodo di destinazione. StoredDataReceived; memorizza i dati arrivati i quali non sono stati ancora prelevati dal metodo receive. 79

Progetto StoredDataTable; memorizza il dato preso in input da un'operazione di Send. Insieme al dato vengono memorizzati tutti i parametri utilizzati nell'operazione. Nella Figura 4.10 vengono riportate tali classi. Figura 4.10: Table Package Classe DeviceTable. In questa classe sono implementati i metodi che riguardano la creazione e la popolazione della Device Table; in particolare si utilizza: 80 costructiondevicetable(): void; costruisce la tabella, la quale ha due colonne; il nome e l'indirizzo IP relativo al nome. populationdevicetable(): void; eettua la popolazione della tabella prelevando i dati dal le dispositivi.txt.

4.2 Speciche funzionali traslationname(string name): string; eettua una traduzione del nome passato come parametro, con l'indirizzo IP presente in tabella. discoveryneighbours(): void; implementa la logica per la scoperta dei vicini. setneighbours(string address): void; memorizza i dispositivi vicini trovati in un ArrayList. getneighbours(): ArrayList; fornisce la lista dei vicini trovati. Classe DuplicatesTable. In questa classe sono presenti quattro metodi: constructionduplicatesrreq(): void; crea la tabella Duplicates Table RREQ, la quale è formata da 2 colonne : bit, id-sender. updateduplicatesrreq() : void; viene eettuato un aggiornamento sulle righe della tabella, Duplicates Table RREQ, ogni 30 secondi, invocando il metodo updatebitrreq. updatebitrreq() : void; aggiorna i bit delle righe della tabella, Duplicates Table RREQ. Se una riga ha il bit di presenza posto a 0, allora essa è cancellata; altrimenti per qualsiasi altro valore il bit viene decrementato di 1. storedrreq(string s) : void; memorizza un nuovo id-sender nella tabella. searchrreq(string id-sender) : Boolean; cerca nella tabella se è presente l'id-sender specicato. constructionduplicatesrrep(): void; crea la tabella Duplicates Table RREP, la quale è formata da 2 colonne : bit, id-sender. updateduplicatesrrep() : void; viene eettuato un aggiornamento sulle righe della tabella, Duplicates Table RREP, ogni 30 secondi, invocando il metodo updatebitrrep. updatebitrrep() : void; aggiorna i bit delle righe della tabella, Duplicates Table RREP. Se una riga ha il bit di presenza posto a 0, allora essa è cancellata; altrimenti per qualsiasi altro valore il bit viene decrementato di 1. storedrrep(string s) : void; memorizza un nuovo id-sender nella tabella. searchrrep(string id-sender) : Boolean; cerca nella tabella se è presente l'id-sender specicato. 81

Progetto close() : void; chiude i Thread che lavorano sull'aggiornamento delle due tabelle. Classe MemoryData. In questa classe sono presenti i metodi: constructionmemorydata(): void; crea la tabella Memory Data, la quale è formata da 3 colonne : number, timestamp, datasend. setmemorydata(byte[] number, byte[] timestamp, byte[] data): void; inserisce una nuova riga nella tabella. getanddeletedatarow(string timestamp, int numberpacket): ArrayList; se il numero di pacchetti, che possiedono il timestamp passato come parametro, è uguale al parametro numberpacket, allora vengono restituite quelle righe che hanno il valore del timestamp uguale a quello che è stato passato come parametro. I valori presenti nelle varie righe sono memorizzati in un ArrayList. Altrimenti, se il numero di pacchetti memorizzati è inferiore, allora viene restituito il valore null. numbertimestamp(string timestamp) : int; utilità che conta quante righe possiedono il timestamp passato come parametro. getdata(string timestamp, int numberpacket): byte[]; se il numero di pacchetti, che possiedono il timestamp passato come parametro, è uguale al parametro numberpacket, allora vengono riordinati tutti i pacchetti ottenuti, creando il dato come era originariamente, prima cioè che fosse suddiviso in vari pacchetti. Altrimenti, se il numero di pacchetti memorizzati è inferiore, allora viene restituito il valore null. Classe RouteCache. In questa classe sono presenti quattro metodi importanti: 82 constructionroutecache(): void; crea la tabella Route Cache, la quale è formata da 2 colonne : bit e route. close(): void; termina il Thread che lavora sul metodo updateroute- Cache. getroute(string indirizzomittente, string indirizzodestination): string; questo metodo prende come parametri due indirizzi e restituisce un percorso indirizzomittente-indirizzodestinazione. searchrowforroute(string indirizzodestinazione): string; restituisce un percorso, se presente in Route Cache, contenente l'indirizzo passato come parametro.

4.2 Speciche funzionali updatepresencebit(): void; aggiorna i presence bit dei vari percorsi memorizzati in Route Cache. updateroutecache(): void; eettua un aggiornamento periodico sui percorsi presenti in Route Cache. La Route Cache viene aggiornata ogni 30 secondi. addroute(string route): void; aggiunge un nuovo percorso in Route Cache. I vari percorsi sono tutti memorizzati con l'indirizzo del dispositivo in prima posizione. removeroutes(string head, string foot): void; elimina dai percorsi presenti in tabella, il link head-foot. Classe StoredDataReceived. In questa classe sono presenti i seguenti metodi : constructionbuer(): void; crea la tabella Buer, la quale è formata da 3 colonne : port, address, data. setbuer(int port, string indirizzo, byte[] dato): void; memorizza una nuova riga nella tabella. getrow(structreceive sr): StructReceive; memorizza i dati, prelevati nella tabella Buer, nell'istanza StructReceive ricevuta come parametro. deleterow(int port): void; cancella la riga della porta specicata. Classe StoredDataTable. In questa classe si hanno a disposizione i seguenti metodi: contructionstoreddatatable(): void; crea la tabella Stored Data Table, la quale è formata da 4 colonne : requestid, portsender, portdestination, data. setstoreddatatable(int requestid, int portsender, int portdestination, byte[] data): void; aggiunge una riga alla tabella. deleterow(string requestid, string portsender) : void; cancella la riga che possiede i parametri specicati. getanddeleterows(string requestid) : ArrayList; restituisce e cancella la riga specicata. 83

Progetto 4.2.3 Sequence Diagram In questa sezione verranno riportate, nel dettaglio, tramite l'ausilio di Sequence Diagram [5], sia la costruzione iniziale dell'applicazione, sia il usso delle sei operazioni principali implementate in questo lavoro di tesi, che sono: bind close islinked send Receive Release. Creazione oggetto ManetManager Nella Figura 4.11 vengono mostrati i passi che si eettuano nella costruzione di un'istanza della classe ManetManager. Tale creazione permette ad un Figura 4.11: Creazione oggetto ManetManager qualunque dispositivo di avvalersi delle funzionalità del protocollo di routing 84

4.2 Speciche funzionali DSR. Nel costruttore della classe Manet Manager viene ricavato, per prima cosa, l'indirizzo IP del dispositivo sul quale l'istanza viene eseguita. Successivamente, vengono create le tabelle principali del'applicazione: la Device Table, la Route Cache, la Duplicates Table e la Stored Data Table. La Device Table memorizza l'associazione tra il nome dei dispositivi, presenti nella rete MANET, e i relativi indirizzi IP. La Route Cache memorizza i percorsi che, durante l'esecuzione dell'applicazione, si andranno a scoprire. Essa implementa tutta la logica di mantenimento, gestione, aggiornamento e cancellazione dei percorsi all'interno di un dispositivo.la DuplicatesTableRREQ e la DuplicatesTableRREP, manterranno quelli che sono, rispettivamente, i pacchetti RREQ e i pacchetti RREP, ottenuti dal dispositivo. Questa tabella permette di evitare che ci siano RREQ e RREP duplicati; ciò migliora le prestazioni dell'intera rete. La StoredDataTable memorizza il dato e i parametri ad esso associati quando si eettua un operazione di send. Alcune di queste tabelle devono essere aggiornate periodicamente, per questo motivo vengono creati diversi Thread, deputati all'aggiornamento di esse. Precisamente, un Thread aggiorna la Route Cache, essendo caricato sul metodo updateroutecache; altri due Thread aggiornano la Duplicates Table RREQ e la Duplicates Table RREP, rispettivamente tramite i metodi updateduplicatesrreq e updateduplicatesrrep. Inne, vengono create le due porte di ascolto; viene infatti creata un'istanza della classe ServerCommand ed una della classe ServerData. Queste classi creano tutte le strutture dati necessarie al funzionamento delle porte di ascolto. Su queste due istanze vengono lanciati due Thread per fare in modo che le due porte stiano in attesa di connessioni, senza bloccare l'applicazione. Il metodo a cui è associato il Thread sulla porta comandi è serverlistener- Command, mentre il metodo sulla porta dati è serverlistenerdata. Chiamata Bind La chiamata bind(int port) permette ad una applicazione di usufruire della logica sottostante, del protocollo di routing. Per poter eettuare operazioni come la send, la receive e la islinked, infatti, è necessario passare come parametro il numero di porta che viene assegnato nel momento in cui si effettua la chiamata bind. Nella Figura 4.12 è mostrato il usso di esecuzione dell'operazione di bind. Una qualsiasi applicazione eettua la chiamata bind, passando come parametro il numero di porta che vorrebbe che le fosse assegnato. Il ManetManager, per prima cosa, crea l'oggetto ManetSocket, contrassegnato dal numero di porta che gli è stato passato. A questo punto, il ManetManager memorizza un riferimento dell'istanza ManetSocket, nella istancemanetsocket. Una volta che 85

Progetto Figura 4.12: Operazione Bind è stata memorizzata l'istanza, quest'ultima viene restituita all'applicazione sovrastante. Chiamata Close La chiamata close(int port) consente di chiudere un'applicazione di cui non si ha più bisogno. Nella Figura 4.13 è mostrato il usso di esecuzione dell'- operazione. Quando il ManetManager riceve una chiamata close, richiama il metodo privato deletemanetsocket che si occupa di ricercare nella istancemanetsocket, l'istanza da eliminare. Eliminata l'istanza, l'operazione termina. Chiamata IsLinked Per vericare la presenza di un preciso dispositivo sulla rete, il protocollo di routing implementato, mette a disposizione la chiamata islinked. Nella Figura 4.14 viene mostrato il usso di esecuzione dell'operazione. Una Mobile Application richiama il metodo islinked della classe ManetSocket, passando come parametro il nome del dispositivo, del quale vuole vericare la presenza. Il metodo islinked ada la logica di gestione dell'intera operazione al metodo waitresultislinked, implementato nella classe Host, il 86

4.2 Speciche funzionali Figura 4.13: Operazione Close Figura 4.14: Operazione Is Linked 87

Progetto quale restituirà, dopo un certo periodo di tempo, un risultato. Il metodo avvia un'operazione di Route Discovery verso la destinazione desiderata; quindi preleva il requestid, scoprirà quali sono i vicini a cui inviare i pacchetti di richiesta. La Route Discovery viene avviata mandando pacchetti comando, contassegnati dal comando 9. Dopo aver lanciato la RouteDiscoveryLinked, si aspetta un risultato; periodicamente, infatti, si controlla l'arraylist resultislinked presente nella classe StoredResult, che contiene i vari risultati delle operazioni islinked effettuate. L'operazione islinked è bloccante per l'applicazione che la chiama, ma può essere chiamata contemporaneamente da più applicazioni. Chiamata Send Di seguito vengono riportati tre sequence diagram relativi all'operazione send; in essi è stata suddivisa logicamente l'operazione stessa, per evidenziare accuratamente quali sono i vari casi di utilizzo. Nella Figura 4.15 viene Figura 4.15: Chiamata Send generale mostrato il usso di esecuzione dell'operazione send, senza specicare in dettaglio la logica relativa ai due casi che si possono avere. Va inizialmente precisato che la send è un'operazione bloccante (si pensi alla system Call del linguaggio di programmazione C [2]), poichè essa ha bisog- 88

4.2 Speciche funzionali no di un intervallo di tempo per poter inviare il dato. Il tempo necessario varia a seconda che sia presente o meno nella route cache un percorso per il dispositivo di destinazione. Come per l'operazione di islinked, la send blocca l'applicazione che la chiama, ma può essere invocata da più applicazioni contemporaneamente. Una generica applicazione su PDA invoca il metodo send() sulla classe ManetSocket, per inviare un pacchetto dati. Nel metodo send, viene per prima cosa vericato che il dato ricevuto come parametro sia diverso dal valore null. In seguito, viene invocato il metodo destinationdiscovery(string namedestination, int portdestination, byte[] data) della classe Host; questo metodo dopo aver memorizzato i parametri ricevuti in alcune variabili globali della classe, invoca, a sua volta, il metodo waitresultsend. Quest'ultimo metodo contiene tutta la logica dell'operazione; ad esso è infatti assegnato il compito di coordinare le varie azioni che devono susseguirsi nell'operazione di send. Due sono le azioni principali che si possono avere: la Route Discovered e la Route Discovery. Queste si diversicano poichè la RouteDiscovered viene invocata quando nella RouteCache si è trovato un percorso per la destinazione; viceversa la RouteDiscovery cerca un percorso per la destinazione. Di seguito, si analizzeranno dettagliatamente i due casi. Route Discovered La Route Discovered, riportata in Figura 4.16. si ha quando la ricerca in Route Cache ha un esito positivo. In primo luogo viene prelevato il requestid che identicherà l'operazione; successivamente viene memorizzato il dato nella StoredDataTable, questa operazione è necessaria poichè nel caso in cui la RouteDiscovered non riesca a inviare il dato alla destinazione, si avrà disponibile il dato iniziale. Dopo aver eettuato queste due azioni, si è pronti per inviare il dato. Il dato prima di essere inviato deve essere posto in pacchetti comprendenti il numero d'ordine e il timestamp. Per questo motivo, per prima cosa il dato viene suddiviso, con il metodo sizedata(byte[] data) : ArrayList, in seguito dopo aver calcolato il timestamp verranno creati, con il metodo createdatapackets(arraylist data, string timestamp) : ArrayList, i pacchetti che saranno inviati. Ora che si è in possesso dei vari pacchetti si crea il comando 5 associato all'invio del dato. Prima di inviare il comando e il dato, viene calcolato qual'è l'hop, e si eettua un controllo per vericare che l'hop sia raggiungibile. Se la verica restituisce un esito positivo, allora vengono inviati sia il dato sia il comando. Viene inviato prima il dato per agevolare la sincronizzazione lato Server. Una volta che il dato è stato inviato, si rimane in attesa per un certo numero di secondi, controllando periodicamente l'arraylist resultresultsend presente nella classe StoredResult, che contiene i vari risultati delle 89

Progetto operazioni send eettuate. Viceversa, se la verica restituisce un esito negativo, si aggiorna la Route Cache noticando l'errore del link. Figura 4.16: Route Discovered RouteDiscovery La RouteDiscovery riportata in Figura 4.17 si ha quando la ricerca in Route Cache ha un esito negativo. In primo luogo, quindi, si eettua la scoperta dei vicini, tramite il metodo discoveryvicini. Una volta ottenuti quelli che sono i dispositivi che si trovato nel range trasmissivo, si verica se tra essi è presente il dispositivo di destinazione. Se la destinazione è presente tra i vicini, allora, si avvia 90

4.2 Speciche funzionali una RouteDiscovered, per mandarle il dato. Se invece la destinazione non è presente tra i vicini, si avvia una RouteDiscovery; in primo luogo, si preleva il requestid che identica univocamente l'operazione e si memorizza il dato nella StoredDataTable. Successivamente, viene creata un'istanza della classe OperationRouteDiscovery. In seguito viene avviato un Thread sul metodo startroutediscovery(), che si occupa di inviare i pacchetti RREQ ai vicini. Quando tutti i pacchetti RREQ sono stati inviati, il dispositivo mittente Figura 4.17: Chiamata Send relativa alla scoperta di un percorso tramite l'operazione di route Discovery. attende che l'operazione restituisca un risultato, il quale si materializza con l'ottenimento di un pacchetto RREP. Se non si viene in possesso di un pacchetto RREP, l'operazione di send restituirà il valore false. Se viceversa, un pacchetto RREP giunge al nodo mittente, esso utilizza il percorso memorizzato nel Route Record per inviare il dato alla destinazione. A questo punto viene mandato il comando 5 unito al percorso ottenuto per la destinazione e al timestamp relativo all'istante in cui si invia il dato. (5 + percorso + timestamps) L'operazione di send() termina con successo se il risultato ottenuto è true; ciò accade quando il dispositivo di destinazione otterrà il dato e invierà al dispositivo mittente una notica dell'avvenuta ricezione (comando 6). 91

Progetto Chiamata Receive La chiamata receive, viene utilizzata dalle varie applicazioni, per ricevere i dati, che giungono al dispositivo. Nella Figura 4.18 viene mostrato quello che è il usso dell'operazione. Un'applicazione richiama il metodo receive, passando come parametro un'istanza della classe StructReceive, in questa istanza saranno memorizzati i parametri associati alla ricezione del dato, che sono: porta dell'applicazione presente sul dispositivo, indirizzo del dispositivo che ha inviato il dato e il dato stesso. Il parametro relativo alla porta dell'applicazione è utilizzato per decidere a quale applicazione caricata sul dispositivo è associato il dato. L'indirizzo del dispositivo e il dato, invece, sono restituiti all'applicazione. Ogni volta che viene eettuata una chiamata receive, e quindi viene prelevato un dato, lo stesso viene cancellato dalla memoria tramite il metodo deleterow. Figura 4.18: Chiamata Receive Chiamata Release La chiamata release, è utilizzata per chiudere tutte le risorse utilizzate dal protocollo di Routing. Nella Figura 4.19 viene mostrato il usso dell'operazione. Il metodo release, per prima cosa chiude tutti i ManetSocket attivi nell'applicazione. Successivamente, richiama il metodo close, su quattro classi: Route Cache, DuplicatesTable, ServerCommand e ServerData. Le chiamate close associate alle due classi che plasmano tabelle, si limitano a settare il ag interrompi, il quale consente di arrestare i Thread che lavorano sui metodi updateroutecache, updateduplicatesrreq e updateduplicates- 92

4.2 Speciche funzionali RREP. Le chiamate close eettuate sui due metodi che implementano la logica server, permettono di chiudere le due porte : comando(10000) e dato(11000). La chiusura delle porta si realizza tramite la chiamata Stop. Figura 4.19: Chiamata Release. 93

Capitolo 5 Test 5.1 Test dell'applicazione Nel capitolo 4 sono state descritte approfonditamente le scelte eettuate all'interno del codice, usate per implementare la logica dell'algoritmo di Routing. In questo capitolo, invece, verranno analizzati i test eettuati sull'applicazione, ed alla ne sarà presentato un possibile scenario di utilizzo. Tutti i parametri che saranno trattati nel seguito sono stati prelevati dal le cong.txt, presente su ogni dispositivo della rete. 5.2 Descrizione dei test eettuati Sono stati eettuati due tipi di test: un test di Tuning ed un test di robustezza. Con il test di Tuning si sono riusciti ad ottenere vari parametri, che migliorano notevolmente le prestazioni dell'applicazione. In particolare, si è posta molta attenzione al calcolo del tempo impiegato per inviare pacchetti dato. Con il test di robustezza si è vericata la stabilità dell'applicazione in condizioni critiche. Nel seguito, verrà fatta un'attenta analisi dei test; ma prima saranno chiariti alcuni dettagli. 5.2.1 Dispositivi utilizzati I test sono stati eettuati avvalendosi di sei dispositivi, che presentano molte disuguaglianze, soprattutto da un punto di vista HardWare. Tre, dei sei dispositivi utilizzati, sono PDA: due IPAQ 5550 un IPAQ 5540 95

Test. La congurazione HardWare dei PDA prevede un processore a 450Mhz e 128Mb di RAM. Anche se i modelli, sono molto simili dal punto di vista HardWare, essi presentano grandi diversità per quel che riguarda il SoftWare; essi infatti utilizzano due sistemi operativi totalmente dierenti. Gli altri tre dispositivi utilizzati sono: due desktop un laptop.i due desktop possiedono una congurazione HardWare molto prestante, con processori a 3GHz e 1GByte di memoria RAM. Anche il laptop, un ASUS L5530, possiede ottimi requisiti con un processore ad una frequenza di 2.8GHz e 512 Mbyte di RAM. Occorre precisare una cosa molto importante; i nodi della rete, come si evince, sono molto disomogenei in quanto a caratteristiche HardWare e Soft- Ware. Questo ha permesso di testare al meglio l'applicazione, poichè tutti i difetti di essa sono amplicati dalla grande diversità dei dispositivi che la sfruttano. Ad esempio, si può intuire facilmente che quando o un laptop o un desktop invia pacchetti dato verso un PDA, quest'ultimo è messo a dura prova poichè la sua velocità di clock risulta notevolmente inferiore a quella di un computer desktop. 5.2.2 Congurazione della rete E' utile sottolineare alcuni aspetti di congurazione. La rete sulla quale i dispositivi sono in comunicazione è stata denominata Manet. I vari indirizzi IP della rete appartengono al gruppo C e precisamente appartengono tutti alla stessa sottorete : 192.168.0.0 Entrando in dettaglio gli indirizzi utilizzati sono: IPAQ 5550, indirizzo: 192.168.0.1 IPAQ 5550, indirizzo: 192.168.0.2 IPAQ 5540, indirizzo: 192.168.0.3 ASUS L5530, indirizzo: 192.168.0.4 desktop1, indirizzo: 192.168.0.5 desktop2, indirizzo: 192.168.0.6 5.2.3 Topologia della rete I test sono stati eettuati collocando i dispositivi in due stanze contigue, separate da un divisorio in acciaio. In tutte le prove tre dispositivi sono stati posti in una stanza e tre nell'altra. Nella Figura 5.1 viene mostrato lo scenario appena descritto. 96

5.2 Descrizione dei test eettuati Laboratorio A ((( ))) Laboratorio B ((( ))) 192.168.0.4 192.168.0.6 ((( ))) ((( ))) 192.168.0.5 192.168.0.2 ((( ))) ((( ))) 192.168.0.3 192.168.0.1 Figura 5.1: Scenario di utilizzo 97

Test 5.3 Primo Test : Tuning dell'applicazione In questo test, la concentrazione è rivolta all'osservazione dei tempi impiegati per inviare un dato su 5 hop; l'invio del dato è infatti un'operazione che appesantisce molto le prestazioni dell'applicazione. Per questo motivo è bene cercare dei parametri che permettano di migliorare le prestazioni. I parametri analizzati sono: sizedata, parametro relativo alla taglia del pacchetto che trasporterà il dato sulla rete attesaroutediscovered, tempo massimo di attesa del risultato dall'operazione RouteDiscovered attesaroutediscovery, tempo massimo di attesa del risultato dall'operazione RouteDiscovery I parametri attesaroutediscovered e attesaroutediscovery caratterizzano rispettivamente i due metodi RouteDiscovered e RouteDiscovery, presenti nella classe Host. Essi, come già ampiamente spiegato nel capitolo precedente, costituiscono la logica dell'operazione send. La send, prima di restituire un risultato dall'esito negativo, eettua vari tentativi per riuscire a mandare il dato; per questo motivo, più il tempo di attesa delle due operazioni è limitato, più tentativi possono essere eettuati nello stesso lasso di tempo. Potendo usufruire di più tentativi sarà sicuramente maggiore la probabilità di riuscire a inviare il dato. Per queste ragioni risulta molto importante calcolare con precisione i tempi di attesa, cercando di ridurli al massimo. Il parametro sizedata incide notevolmente sui due tempi; infatti, nelle due operazioni citate precedentemente, l'invio del dato occupa la maggior parte del tempo. Il dato, come già visto nel capitolo precedente, viene inviato in vari pacchetti, se la sua dimensione è maggiore del sizedata. Altrimenti se la dimensione risulta essere inferiore o uguale alla dimensione del parametro, allora il pacchetto dato viene riempito di tanti spazi quanti sono i bytes di dierenza. Occorre scegliere la giusta taglia del pacchetto dati, perchè essa permette di migliorare notevolmente le prestazioni dell'intera applicazione. Di seguito saranno mostrate le prove eettuate su varie taglie di pacchetto, che sono : Size Data 256 Size Data 512 Size Data 768 Size Data 1024 98

5.3.1 Size Data 256 5.3 Primo Test : Tuning dell'applicazione La taglia più piccola provata è di 256 bytes. Questa taglia ha un comportamento accettabile nell'invio di dati che non superano i 1024 bytes; da questa dimensione in poi le prestazioni iniziano a degradare. Si pensi infatti che per inviare 1024 bytes si impiegano 3563 millisecondi, mentre per inviarne 16384 si impiegano 19313 millisecondi 1. Questo tipo di prestazioni non sono accettabili, per il nostro protocollo di routing. Tutte le prove eettuate sono riassunte nel graco di Figura 5.2. Nel graco, i tempi, posti sull'asse delle ordinate, sono l'unione del tempo impiegato ad eettuare le operazioni di RouteDiscovery con il tempo impiegato ad inviare il dato. I risultati del test, sono stati calcolati su una base media di 10 campioni. Size Data 256 25000 20000 21137 Tempo (msec) 15000 10000 8383 13043 5000 4653 4302 4653 5040 5214 6717 0 64 128 256 512 1024 2048 4096 8192 16384 Dim.Dato (byte) Figura 5.2: Graco Size Data 256 1 Il tempo calcolato è solo quello necessario ad inviare il dato 99

Test 5.3.2 Size Data 512 Raddoppiando la taglia si possono riscontrare notevoli miglioramenti. Quando si iniziano a spedire dati di dimensioni maggiori di 1024 bytes, ci si accorge che le prestazioni sono leggermente migliorate. Per inviare 1024 bytes, infatti, ci si impiegano 3232 millisecondi, mentre per inviarne 16384 ce ne vogliono 10601 2. Come si osserva facilmente, c'è un notevole miglioramento rispetto alla taglia precedente, non tanto per il miglioramento del tempo impiegato per inviare 1024 bytes quanto sull'invio di 16384. Queste prestazioni, non possono però essere ritenute soddisfacenti, poichè impiegano ancora troppo tempo per inviare i pacchetti dato. I risultati del test, calcolati su una base media di dieci campioni, sono riportati nel graco di Figura 5.3. Size Data 512 25000 20000 Tempo (msec) 15000 10000 8407 12539 5000 4930 4695 4876 4813 5086 4912 6353 0 64 128 256 512 1024 2048 4096 8192 16384 Dim.Dato (byte) Figura 5.3: Graco Size Data 512 100 2 Il tempo calcolato è solo quello necessario ad inviare il dato

5.3.3 Size Data 768 5.3 Primo Test : Tuning dell'applicazione Le prestazioni raggiunte con questa taglia, iniziano ad essere molto soddisfacenti. Questi miglioramenti si notano constatando un notevole abbassamento dei tempi necessari ad inviare pacchetti dato, soprattutto per grandi quantità e una maggiore robustezza nel trasporto degli stessi. Per menzionare qualche dato ottenuto nella sperimentazione, si pensi che per inviare 1024 bytes il tempo necessario è stato di 3208 millisecondi, mentre per spedire 16384 si è impiegato 7948 millisecondi. La robustezza, è stata riscontrata nello studio dei campioni prelevati; infatti, per ogni taglia di dato il massimo numero di campioni possibili da prelevare è quattordici; con il SizeData posto a 768 si hanno avuto perdite di campioni nell'ordine dei due o tre, che rispetto alle taglie precedenti è un numero molto soddisfacente. Nel graco di Figura 5.4, sono riportati tutti i risultati del test; da ricordare che nei tempi posti sulle ordinate, è incluso il tempo totale della RouteDiscovery. Size Data 768 25000 20000 Tempo (msec) 15000 10000 10209 7303 5000 4341 4308 4451 4455 4938 4731 5214 0 64 128 256 512 1024 2048 4096 8192 16384 Dim.Dato (byte) Figura 5.4: Graco Size Data 768 101

Test 5.3.4 Size Data 1024 Con questo SizeData si sono raggiunte delle prestazioni realmente soddisfacenti; sia in termini di tempo che di robustezza. Per evidenziare le prestazioni di questa taglia si pensi che per inviare 1024 bytes ci si impiegano 2912 millisecondi, mentre per inviarne 16384 bytes ci vogliono 6552 millisecondi. Si nota, confrontando questi valori con quelli ottenuti dalle altre taglie, che le prestazioni sono notevolmente migliorate. Inoltre, sulle prove eettuate per prelevare i campioni, i fallimenti di invio del dato sono stati nell'ordine di 1 ogni 15 prove eettuate; questo dato è il migliore rispetto a tutte le altre taglie. La scelta per la dimensione del SizeData è quindi ricaduta su 1024 bytes. Tutti i risultati del test, sono riportati nel graco di Figura 5.5 Size Data 1024 25000 20000 Tempo (msec) 15000 10000 8296 5000 5352 4750 4754 4602 4758 4770 5211 6596 0 64 128 256 512 1024 2048 4096 8192 16384 Dim.Dato (bytes) Figura 5.5: Graco Size Data 1024 102

5.3.5 Confronto Andamenti 5.3 Primo Test : Tuning dell'applicazione Nel graco di Figura 5.6, sono confrontati tutti i vari graci analizzati precedentemente. Con questa visione globale delle prove eettuate, si riesce a vericare quanto il SizeData 1024 sia di gran lunga il migliore. Eettuando un'attenta analisi, si nota che tutti gli andamenti sono equivalenti no alla dimensione di 1024 bytes. Da qui in poi, si nota una crescita inaccettabile dei tempi da parte del SizeData 256. Scorrendo ancora le ascisse, si nota che prima il SizeData 512 e in seguito il SizeData 768, degradano le loro prestazioni. Si evince che la curva più importante del graco è quella ottenuta con il SizeData 1024, che infatti è stato scelto. Confronto Andamenti 25000 20000 Tempo (msec) 15000 10000 SizeData256 SizeData512 SizeData768 SizeData1024 5000 0 64 128 256 512 1024 2048 4096 8192 16384 Dim.Dato (byte) Figura 5.6: Graco di confronto Size Data 103

Test 5.4 Secondo Test : Robustezza dell'applicazione Punto di partenza del secondo test eettuato è stato quello riguardante la taglia del dato; si è ssata la taglia sui 1024 bytes. Il test di robustezza, è servito per testare l'applicazione, sottoponendola a grandi carichi di lavoro; in più si è potuto vericare il tempo impiegato dalla stessa per inviare taglie di dato come 1Mbyte, 2Mbyte, 4Mbyte e 8Mbyte. La maggiore dicoltà incontrata è stata quella di risolvere i problemi relativi ai server sovraccarichi. Per la grande dimensione dei dati, la suddivisione in pacchetti porta a creare un grande numero degli stessi. Per questo motivo, i server riutano connessioni quando ne hanno già troppe in coda; questo fenomeno si enfatizza ancor di più quando il server che riceve il dato, è caricato su PDA. Questo problema comunque è stato risolto gestendo l'eccezzione generata dal server, cioè facendo ritrasmettere il pacchetto. Sono state eettuate due prove: a due Hop, a cinque Hop. 5.4.1 Prova a 2 Hop Il test è stato eettuato in una stanza ed i dispositivi coinvolti erano i due desktop ed il laptop. La prova risulta molto interessante, per i problemi esposti precedentemente sui sovraccarichi dei server; con i computer ssi il problema lo si riscontra in maniera molto minore. I risultati del test sono stati i seguenti: Invio : 1 Mbyte, Tempo : 13,5 secondi Invio : 2 Mbyte, Tempo : 2 minuti 30 secondi Invio : 4 Mbyte, Tempo : 7 minuti 18 secondi Invio : 8 Mbyte, Tempo : 14 minuti Da questi risultati si evince che le prestazioni al crescere della dimensione del dato degradano notevolmente. Questo risultato è dovuto in buona parte ai limiti sici che tutt'oggi ancora è presente nelle reti Manet. Questa ipotesi è confermata anche dal fatto che, dando al sizedata dimensioni di 512Kbyte, le prestazioni non migliorano ma restituiscono gli stessi risultati. 5.4.2 Prova a 5 Hop Questo test è stato eettuato sempre nella stessa stanza, utilizzata per il test precedente. Il percorso imposto, che si può vedere nella Figura 5.1, è stato scelto per avere una alternanza tra PDA e computer ssi; questo permette di sottoporre i dispositivi a tutti i tipi di stress. I risultati ottenuti sono i seguenti : Invio : 1 Mbyte, Tempo : 5 minuti 23 secondi 104

5.5 Manet Chat Invio : 2 Mbyte, Tempo : 10 minuti 24 secondi Invio : 4 Mbyte, Tempo : 30 minuti Invio : 8 Mbyte, Tempo : 40 minuti Si può notare che per la dimensione del dato a 4 Mbyte a 8 Mbyte, i tempi diventano insostenibili. Rispetto all'esempio dei due Hop le prestazioni sono peggiorate di molto; questo è anche dovuto alla presenza nella rete di tre dispositivi PDA. 5.5 Manet Chat Di seguito sarà descritta una possibile applicazione. L'applicazione pensata è una chat, che utilizzerà il protocollo di rete implementato. Essa consente di far comunicare tutti i dispositivi presenti nella rete MANET. Nella Figura 5.7 è mostrata l'interfaccia graca progettata. Figura 5.7: Applicazione CHAT Nella Form sono presenti : 105

Test La TextBox che compare in alto nello schermo, è quella che si utilizza per inserire il testo che deve essere inviato. La ComboBox, posta sotto la TextBox, indica quali sono i dispositivi a cui è possibile inviare il dato. Questi rappresentano i dispositivi presenti nella rete MANET. Il Botton SEND, plasma l'omonima operazione; con esso si avvia tutta quella che è la logica dell'invio del dato. Nella TextBox posta a destra del bottone SEND, apparirà il risultato della SEND; il risultato sarà true se il dato arriva al dispositivo indicato. Se il risultato che compare nella TextBox sarà false vorrà dire che i tentativi eettuati non hanno avuto buon esito. Il tempo massimo di attesa per ottenere una risposta è di 1 minuto circa. La grande TextBox che è presente nel centro della Form, noticherà i messaggi arrivati al dispositivo, dagli altri nodi presenti nella rete. All'arrivo di un messaggio, sarà visualizzato l'indirizzo IP del dispositivo mittente, e il messaggio da lui inviato. Nella parte bassa della Form compare il Botton CLOSE, il quale eettua la chiusura dell'intera applicazione. Di seguito verrà mostrato il codice della chat sviluppata. using System; using System.IO; using System.Drawing; using System.Collections; using System.Windows.Forms; using System.Threading; using System.Data; using System.Text; using System.Net; using Tesi.Manet; 106

5.5 Manet Chat using Tesi.Utility; namespace ProvaFTP { /// <summary> /// Descrizione di riepilogo per Form1. /// </summary> public class Form1 : System.Windows.Forms.Form { private System.Windows.Forms.ComboBox combobox1; private System.Windows.Forms.MainMenu mainmenu1; private System.Windows.Forms.Button button1; private System.Windows.Forms.TextBox textbox1; private System.Windows.Forms.Label label1; private System.Windows.Forms.Label label2; private System.Windows.Forms.TextBox textbox2; private System.Windows.Forms.TextBox textbox3; private System.Windows.Forms.Button button2; private System.Windows.Forms.Button button4; private System.Windows.Forms.TextBox textbox6; private System.Windows.Forms.TextBox textbox4; private ManetManager manetmanager = null; private ManetSocket ms1 = null; private Boolean interrompi = true; private System.Windows.Forms.Button button3; private Thread ricezione = null; public Form1() { // // Necessario per il supporto di Progettazione Windows Form // InitializeComponent(); //Creazione istanza Manet Manager manetmanager = ManetManager.getManetManager(); //Registrazione di un'applicazione sulla porta logica 50 ms1 = manetmanager.bind(50); ricezione = new Thread (new ThreadStart(this.receive1)); ricezione.start(); //Calcolo indirizzo IP del dispositivo 107

Test } IPHostEntry iphostinfo = Dns.Resolve(Dns.GetHostName()); IPAddress addresshost = iphostinfo.addresslist[0]; //Prelevo i nomi dei dispositivi che compongono la rete StreamReader sr = new StreamReader("\\dispositivi.txt"); while(sr.readline()!= null) { string a = sr.readline(); } if(!(addresshost.tostring().equals(a))) this.combobox1.items.add(a); sr.readline(); /// <summary> /// Pulire le risorse in uso. /// </summary> protected override void Dispose( bool disposing ) { base.dispose( disposing ); } #region Codice generato da Progettazione Windows Form /// <summary> /// Creazione interfaccia grafica /// </summary> private void InitializeComponent() { System.Resources.ResourceManager resources = new System.Resources.ResourceManager(typeof(Form1)); this.mainmenu1 = new System.Windows.Forms.MainMenu(); this.combobox1 = new System.Windows.Forms.ComboBox(); 108 this.button1 =

5.5 Manet Chat new System.Windows.Forms.Button(); this.textbox1 = new System.Windows.Forms.TextBox(); this.label1 = new System.Windows.Forms.Label(); this.label2 = new System.Windows.Forms.Label(); this.textbox2 = new System.Windows.Forms.TextBox(); this.textbox3 = new System.Windows.Forms.TextBox(); this.button2 = new System.Windows.Forms.Button(); this.button3 = new System.Windows.Forms.Button(); this.textbox4 = new System.Windows.Forms.TextBox(); this.button4 = new System.Windows.Forms.Button(); this.textbox6 = new System.Windows.Forms.TextBox(); // // combobox1 // this.combobox1.location = new System.Drawing.Point(8, 56); this.combobox1.size = new System.Drawing.Size(80, 21); // // button1 // this.button1.location = 109

Test 110 new System.Drawing.Point(104, 56); this.button1.size = new System.Drawing.Size(56, 20); this.button1.text = "SEND"; this.button1.click += new System.EventHandler(this.button1_Click); // // textbox1 // this.textbox1.location = new System.Drawing.Point(8, 16); this.textbox1.multiline = true; this.textbox1.scrollbars = System.Windows.Forms.ScrollBars.Vertical; this.textbox1.size = new System.Drawing.Size(224, 32); this.textbox1.text = ""; // // label1 // this.label1.location = new System.Drawing.Point(64, 80); this.label1.size = new System.Drawing.Size(120, 16); this.label1.text = "RECEIVE MESSAGE"; // // label2 // this.label2.location = new System.Drawing.Point(64, 0); this.label2.size = new System.Drawing.Size(104, 16); this.label2.text = "SEND MESSAGE"; // // textbox2 // this.textbox2.acceptsreturn = true; this.textbox2.location = new System.Drawing.Point(8, 96); this.textbox2.multiline = true;

this.textbox2.scrollbars = System.Windows.Forms.ScrollBars.Vertical; this.textbox2.size = new System.Drawing.Size(224, 136); this.textbox2.text = ""; // // textbox3 // this.textbox3.location = new System.Drawing.Point(176, 56); this.textbox3.size = new System.Drawing.Size(56, 20); this.textbox3.text = ""; 5.5 Manet Chat // // button3 // this.button3.location = new System.Drawing.Point(8, 240); this.button3.text = "IS LINKED"; this.button3.click += new System.EventHandler(this.button3_Click); // // button2 // this.button2.location = new System.Drawing.Point(8, 240); this.button2.size = new System.Drawing.Size(56, 20); this.button2.text = "CLOSE"; this.button2.click += new System.EventHandler(this.button2_Click); // // button4 // this.button4.location = new System.Drawing.Point(8, 240); this.button4.size = new System.Drawing.Size(56, 20); this.button4.text = "START"; this.button4.click += new System.EventHandler(this.button4_Click); // // textbox4 // 111

Test this.textbox4.location = new System.Drawing.Point(72, 240); this.textbox4.size = new System.Drawing.Size(32, 20); this.textbox4.text = ""; // // textbox6 // this.textbox6.location = new System.Drawing.Point(72, 240); this.textbox6.size = new System.Drawing.Size(32, 20); this.textbox6.text = ""; // // Form1 // this.backcolor = System.Drawing.Color.Blue; this.controls.add(this.textbox4); this.controls.add(this.button3); this.controls.add(this.button2); this.controls.add(this.textbox3); this.controls.add(this.textbox2); this.controls.add(this.label2); this.controls.add(this.label1); this.controls.add(this.textbox1); this.controls.add(this.button1); this.controls.add(this.combobox1); this.icon = ((System.Drawing.Icon) (resources.getobject("$this.icon"))); this.menu = this.mainmenu1; this.minimizebox = false; this.text = "ManetChat"; } #endregion /// <summary> /// Il punto di ingresso principale dell'applicazione. /// </summary> static void Main() { Application.Run(new Form1()); } 112

5.5 Manet Chat private void Manet1() { this.textbox3.text = ""; } string nomedest = this.combobox1.text; string temp = this.textbox1.text; byte[] b = Encoding.UTF8.GetBytes(temp); //Inizia l'operazione di send Boolean boo = ms1.send(nomedest,50,b); this.textbox3.text = boo.tostring(); private void receive1() { try { StructReceive sr = new StructReceive(50); StructReceive result = null; while(interrompi) { result = ms1.receive(sr); if(result!= null) { string address = result.getaddress(); string dato = Encoding.UTF8.GetString (result.getdata(),0,result.getdata().length); string[] cmd = dato.split(' '); string stringadato = null; for(int i=0; i<cmd.length; i++) { try { if(cmd[i]!= "") { 113

Test 114 if(cmd[i+1]!= "") { stringadato = stringadato + cmd[i] + " "; } else { stringadato = stringadato + cmd[i]; break; } } } catch(system.argumentoutofrangeexception) { stringadato = stringadato + cmd[i]; } }//End for if(this.textbox2.text == "") { int posizione = this.textbox2.text.length; this.textbox2.selectionstart = this.textbox2.text.length; this.textbox2.scrolltocaret(); this.textbox2.text = "<" + address + "> " + stringadato; this.textbox2.selectionstart = posizione; this.textbox2.scrolltocaret(); } else { int posizione = this.textbox2.text.length; this.textbox2.selectionstart = this.textbox2.text.length; this.textbox2.scrolltocaret(); this.textbox2.text = this.textbox2.text.insert (this.textbox2.text.length,"\r\n" + "<" + address + ">"

+ stringadato); this.textbox2.selectionstart = posizione + 2; this.textbox2.scrolltocaret(); } }//End while result = null; } } catch(system.objectdisposedexception) { } }//End receive1 private void button1_click (object sender, System.EventArgs e) { Thread t1 = new Thread (new ThreadStart(this.Manet1)); t1.start(); } private void button2_click (object sender, System.EventArgs e) { manetmanager.close(50); this.interrompi = false; manetmanager.release(); this.textbox4.text = "OK"; } private void islinked() { string nomedest = this.combobox1.text; } Boolean bo = this.ms1.islinked(nomedest); this.textbox5.text = bo.tostring(); 5.5 Manet Chat private void button3_click(object sender, System.EventArgs e) { this.textbox5.text = ""; Thread t2 = new Thread (new ThreadStart(this.isLinked)); 115

Test t2.start(); } private void button4_click(object sender, System.EventArgs e) { manetmanager = ManetManager.getManetManager(); } this.ms1 = manetmanager.bind(50); ricezione = new Thread (new ThreadStart(this.receive1)); ricezione.start(); //Ip Address of local device IPHostEntry iphostinfo = Dns.Resolve(Dns.GetHostName()); IPAddress addresshost = iphostinfo.addresslist[0]; StreamReader sr = new StreamReader("\\dispositivi.txt"); while(sr.readline()!= null) { string nome = sr.readline(); string indirizzo = sr.readline(); if(!(addresshost.tostring().equals(indirizzo))) this.combobox1.items.add(nome); this.textbox6.text = "OK"; } } } 116

Capitolo 6 Conclusioni In questa tesi è stato presentato ed illustrato lo sviluppo di uno strato di rete, atto a permettere la comunicazione tra dispositivi mobili facenti parte di una rete MANET, in cui non esiste nessun tipo di infrastruttura o server centralizzati. Tale lavoro si è collocato all'interno del progetto MAIS che si occupa dello sviluppo di modelli e prodotti che permettono l'implementazione di sistemi informativi adattativi capaci di fornire servizi a dierenti tipi di reti e dispositivi. Gli obiettivi raggiunti nel presente lavoro sono stati i seguenti: il primo, è stato quello di comprendere che nelle tecnologie attuali che supportano la congurazione di reti MANET non esiste il concetto di routing. Questa constatazione è stata possibile solo dopo una serie di esperimenti (Appendice B) che hanno rilevato tale mancanza. Un altro obiettivo è stato quello di capire (pur avendo a disposizione poco materiale, visto che questi argomenti sono di attuale ricerca) il reale e totale funzionamento di un protocollo di routing, denominato DSR. La comprensione del protocollo è stata una fase essenziale di questa tesi, poichè ha poi permesso in un secondo momento la sua l'implementazione. Un altro obiettivo è stato quello di capire come (con quali strumenti e metodologie) riuscire a progettare e sviluppare applicazioni per piccoli dispositivi come PDA, utilizzando l'ambienti di sviluppo come Visual Studio.NET. Con grande soddisfazione si è compreso come è possibile applicare, in tale sviluppo, tutte le tecniche e metodologie OO (Object Oriented) già note nello sviluppo di applicazioni destinate ai personal computer e workstation. E' stato altresi semplice inoltre passare dal linguaggio di programmazione JAVA (studiato in vari corsi universitari) al linguaggio di programmazione utilizzato C#, essendo anch'esso un linguaggio di programmazione Object Oriented. L'obiettivo più importante che si è riusciti a raggiungere è stato, dopo aver appreso cosa si intende per protocollo di routing, quello di sviluppare un prototipo di applicazione (destinata ai PDA) basata su architettura peer- 117

Conclusioni to-peer. Questa applicazione è in grado di creare un vero e proprio strato di rete, dando la possibilità ai dispositivi mobili di poter comunicare, pur non essendo sicamente nello stesso range trasmissivo. La tecnologia di comunicazione mobile che ha permesso di fare ciò è stato Wi-FI (802.11b). Inne, sono stati eettuati vari test che hanno permesso sia di congurare al meglio i parametri del protocollo implementato sia di testare il funzionamento del protocollo in condizioni critiche. In tutto sono state implementate le sei operazioni: bind, close, islinked, receive, release e send. Le suddette operazioni compongono l'api del protocollo. Lo stage interno da me svolto è stato sicuramente una dell'esperienze più entusiasmanti che abbia mai eettuato. Tramite esso ho potuto mettere in pratica tutto ciò che in questi anni ho appreso nei corsi universitari, dai fondamenti della programmazione e delle architetture hardware, alla progettazione di applicazioni e sistemi più avanzati in particolare nel campo dei sistemi distribuiti. Ma la cosa più interessante è stato lavorare con tecnologie di nuova generazione, acquisire giorno dopo giorno dimestichezza con esse e riuscire, inizialmente con una accurata analisi del problema, ad implementare un prototipo software, mai n ad ora realizzato (poichè attualmente questi argomenti sono solo di ricerca). Mi ritengo molto soddisfatto per la scelta da me svolta per concludere il corso dei miei studi. 118

Appendice A Hardware e Software A.1 Congurazione dell'ambiente di sviluppo Per ottenere una piattaforma di sviluppo che funzioni in maniera adeguata è necessario eseguire l'installazione di diversi tool in un preciso ordine; una installazione diversa porterebbe generare un malfunzionamento dei vari componenti. L'ordine di installazione deve essere il seguente: 1. Microsoft Active Sync vers. 3.7 o successive; 2. Visual Studio.NET 2003; 3. SDK PDA 2003. La disinstallazione deve avvenire nell'ordine inverso a quello specicato. A.2 Visual Studio.NET 2003 Per costruire applicazioni che possono essere caricate su emulatori o PDA, le tappe da seguire sono le seguenti: 1. aprire Visual Studio.NET 2003 2. andare su File, scegliere nuovo progetto 3. selezionare il tipo di linguaggio di programmazione da utilizzare e il modello Applicazioni per Smart Device. Nella Figura A.1 viene mostrato lo scenario appena descritto. Una volta fatto ciò apparirà la schermata mostrata in Figura A.2. Questa identica la creazione guidata che consente di creare un progetto per lo sviluppo di un'applicazione da eseguire su un dispositivo Smart Device. Sempre prendendo come riferimento la Figura A.2, vengono mostrati nel riquadro in basso a 119

Hardware e Software Figura A.1: Scelta del progetto Figura A.2: Applicazione SmartDeviceApplication 120

A.2 Visual Studio.NET 2003 sinistra l'elenco dei dispositivi che si possono utilizzare per eseguire un'applicazione. Detto ciò bisogna innanzitutto specicare la piattaforma di destinazione (Pocket PC o Windows CE) e in seguito selezionare il progetto da creare, ossia: un'applicazione per Windows; una libreria di classi; un'applicazione non graca o progetto vuoto. A.2.1 Congurazione Microsoft LoopBack Adapter Se non si è in possesso di un dispositivo mobile palmare, l'applicazione Smart Device che si andrà a creare, potrà essere testata con l'utilizzo dell'emulatore. Prima di provare l'applicazione però si deve installare la scheda di rete Loop- Back Adapater. Ciò è di fondamentale importanza per utilizzare l'emulatore in un ambiente in cui non è disponibile una connessione di rete. Per quanto riguarda l'installazione, bisogna procedere come una normale installazione di hardware già presenti su workstation. Nella Figura A.3 viene mostrata Figura A.3: Installazione della scheda di rete Microsoft LoopBack la selezione della scheda di rete Microsoft LoopBack. Una volta terminata l'installazione, bisogna impostare l'indirizzo di rete come 169.254.0.x, dove x può essere compreso nell'intervallo 0-16. 121

Hardware e Software Nel caso in cui, all'interno della stessa rete, siano presenti due o più workstation con tale scheda installata, è necessario che gli indirizzi assegnati dieriscano (da qui deriva la possibilità di modicare l'ultima parte dell'indirizzo da assegnare) gli uni dagli altri, in modo da evitare conitti dovuti alla presenza di schede dello stesso tipo, con medesimi indirizzi. A.3 Applicazione Smart Device Una volta creata un'applicazione Smart Device i passi seguenti permettono l'esecuzione: 1. Cliccare su pulsante Genera e scegliere Generare la soluzione; 2. cliccare sul pulsante Debug e scegliere Avvia senza eseguire il debug 3. selezionare il dispositivo, come viene mostrato nella Figura A.4 Figura A.4: Distribuzione Smart Device Una volta eseguiti tali passi, se il dispositivo selezionato non ha installato il.net Compact Framework, questo verrà automaticamente distribuito insieme all'applicazione. Se si sceglie di caricare l'applicazione sull'emulatore Pocket PC o sul dispositivo Pocket PC, il risultato di una possibile realizzazione è quello mostrato in Figura A.5. Visual Studio.NET 2003 permette il salvataggio dello stato dell'emulatore 122

A.4 Congurazione di una MANET o di disattivarlo. Ogni volta che si disattiva lo stato, se si distribuisce di nuovo un'applicazione verrà ridistribuito anche il.net Compact Framework. Il salvataggio dello stato dell'applicazione non viene fornito dal dispositivo sico PDA; in questi dispositivi infatti si può solo chiudere l'applicazione, ed essa rimarrà presente nella memoria. Va inoltre menzionato che quando si carica un'applicazione sui PDA è importante ricordarsi di settare nella Form creata la Minimize Box. Questa modalità permette di chiudere l'applicazione eliminando contemporaneamente il processo dalla memoria. In Figura A.6 viene mostrato tale esperienza. Figura A.5: Risultato di un'applicazione Smart Device A.4 Congurazione di una MANET La creazione di una rete MANET è possibile se si ha a disposizione una scheda wireless integrata (nel caso di PDA o laptop di ultima generazione) od esterna. 123

Hardware e Software Di seguito si farà vedere come si imposta una rete ad hoc sia su un portatile che su di un PDA. Figura A.6: Chiudere un'applicazione caricata su un PDA Come si imposta una rete ad hoc su un dispositivo portatile Il portatile in considerazione è ACER 433, sistema operativo Windows XP Home, in cui non è presente una scheda wireless, per cui si è utilizzata una scheda esterna Wi-FI, denominata NETGEAR. Per prima cosa si devono installare i drivers relativi a tale scheda, e poi procedere nella creazione della rete. I passi da seguire sono questi: 1. inserire la scheda di rete wireless nell'apposito porta PCIMCA; 2. andare sul pannello di controllo, scegliere connessione di rete, connessione senza li, e con il tasto destro, cliccare su attiva; 124

A.4 Congurazione di una MANET 3. in ultimo, sempre su connessione di reti senza li, premere il tasto destro e scegliere proprietà. Dopo aver scelto proprietà apparirà la schermata mostrata in Figura A.7. Figura A.7: Impostatazione di una rete ad hoc Se si clicca sulla casella Reti senza li compariranno tutte le reti presenti alle quali ci si può connettere. La Figura A.8 mostra la presenza di due reti: maisemecuno rappresenta una rete non ad hoc, in cui è presente un access point (rete dipartimentale), Manet è una rete ad hoc, creata da noi. Le tappe che si sono svolte per poter creare la rete ad hoc Manet sono state le seguenti: 1. specicare l'indirizzo IP, per identicare la macchina all'interno di una rete ad hoc (è comodo utilizzare la classe degli indirizzi IP C che possiede 21 bit di networkid e 8 bit di hostid; tale classe utilizza indirizzi a partire da 192.0.0.0 per arrivare a 223.255.255.255); 125

Hardware e Software Figura A.8: Presenza di reti ad hoc 2. scegliere Reti senza li, premere il tasto aggiungi, apparirà una schermata in cui si richiede un SSID, che identica il nome della rete ad hoc che si vuole creare. Nella Figura A.9 viene mostrato come si imposta l'indirizzo IP relativo alla macchina da utilizzare all'interno della rete ad hoc. Dopo averlo introdotto, automaticamente verrà fornito l'indirizzo Subnet mask (gli ID di rete e gli ID di host all'interno di un indirizzo IP vengono distinti utilizzando una Subnet mask; ogni Subnet mask è un numero a 32 bit che utilizza gruppi consecutivi di bit di uno per identicare le porzioni dell'id di rete e di zero per identicare le porzioni dell'id di host di un indirizzo IP) che è 255.255.255.0. In genere i valori predeniti per la Subnet mask (come mostrato nella tabella A.1) sono validi per la maggior parte delle reti che non hanno dei requisiti specici e in cui ogni segmento di rete IP corrisponde a una singola rete sica. In alcuni casi è possibile utilizzare Subnet mask personalizzate per implementare il subnetting IP. Con il subnetting IP è possibile suddividere la porzione di ID dell'host predenito di un indirizzo IP per specicare le subnet, che sono suddivisioni dell'id di rete originale basato sulla classe. Attraverso la personalizzazione della lunghezza della Subnet mask, è possibile ridurre il numero di bit utilizzati per il reale ID host. Nel nostro caso si 126

A.4 Congurazione di una MANET Figura A.9: Impostazione del'indirizzo IP è preferito impostare direttamente l'indirizzo IP e la relativa Subnet mask. Nella Figura A.10 viene mostrata la schermata di creazione della rete Manet. Classe di bit per Subnet Mask Subnet indirizzi Mask Classe A 11111111 00000000 00000000 00000000 255.0.0.0 Classe B 11111111 11111111 00000000 00000000 255.255.0.0 Classe C 11111111 11111111 11111111 00000000 255.255.255.0 Tabella A.1: Tabella indirizzi Nello spazio SSID va indicato il nome della rete ad hoc, che si intende creare; il riquadro invece dove è presente l'autenticazione di rete, indica se si vuole avere un autenticazione condivisa o aperta. In tal caso viene utilizzata una chiave di rete per fornire l'autenticazione alla rete senza li. In base allo standard 802.11 per reti senza li, quando si utilizza una chiave di rete per l'autenticazione, la rete funziona in modalità di autenticazione a Chiave Condivisa. Se invece non viene utilizzata nessuna chiave, la rete funziona in modalità Sistema Aperto. Il riquadro dove compare crittograa dei dati specica se la rete senza li selezionata è abilita dall'autenticazione WEP (Wired Equivalent Privacy). 127

Hardware e Software Se questa casella di controllo è selezionata, durante l'invio dei dati sulla rete, viene utilizzata una chiave per crittografare i dati. Figura A.10: Creazione di una rete ad hoc Come si imposta una rete ad hoc su un dispositivo palmare Si premette che tutte le Figure che verranno riportate sono relative al dispositivo emulatore in dotazione con Visual Studio.NET 2003. L'impostazione di una rete ad hoc è relativa ai dispositivi palmari PDA: IPAQ serie 5550 sistema operativo windows CE, IPAQ serie 5540 sistema operativo windows CE (che diererisce dal IPAQ serie 5550 solo per l'impostazione del canale comunicativo; tale canale deve essere precisato all'inizio della creazione di una rete ad hoc). I passi che si devono compiere per creare una rete ad hoc tra diversi dispositivi palmari sono molto simili a quelli che si sono fatti per il dispositivo portatile, in particolare: 1. selezionare start, e scegliere impostazioni, 2. selezionare connessioni (come viene mostrato nella Figura A.11) 128