Reti di Calcolatori LS Professor Antonio Corradi Ingegner Dario Bottazzi

1. Delay Tolerant Network Architecture per SAMOA:Mobile Social Computing applicato a situazioni di emergenza Reti di Calcolatori LS Professor Antonio Corradi Ingegner Dario Bottazzi Presentazione di Francesco Fiori

2. Obiettivo del progetto Il progetto si è concentrato sull’adattamento del framework SAMOA a scenari di emergenza dove la priorità è la comunicazione tra persone in difficoltà e la rapida disseminazione di informazioni nonostante le possibili carenze di infrastrutture per la comunicazione. Il lavoro svolto verte sullo sviluppo di un servizio per favorire la comunicazione sia sincrona che asincrona tra utenti appartenenti a reti sociali differenti oppure non direttamente connessi in quanto in una situazione di emergenza è possibile che un singolo nodo rimanga isolato per un tempo prolungato.

3. Il framework SAMOA SociallyAware and MObileArchitecture (SAMOA) è un middleware che integra un insieme di facilities per la gestione, la personalizzazione e la propagazione di una rete sociale a livello applicativo SAMOA supporta la creazione di reti sociali semantiche context-aware tra utenti fisicamente vicini, con stesse attitudini e interessi La rete sociale è centrata sull'utente e utilizza due tipologie di visibilità di contesto: Place visibility Profile visibility

4. Ruoli all’interno di SAMOA • Manager: utenti interessati a creare una propria rete sociale, hanno la responsabilità di definire i confini della località e scegliere i criteri sui partecipanti • Client: tutti gli utenti presenti all'interno dei confini stabiliti dal manager, sono i candidati a diventare i membri della rete sociale • Member: sono i client che entrano a far parte di una rete sociale

5. Architettura di SAMOA • Social Network Management Layer: fornisce meccanismi per l'estrazione della rete sociale e per la sua gestione • Basic Services Layer: fornisce un servizio di nomi, un meccanismo per la rilevazione di entità presenti nella medesima località e dei metodi per supportare la comunicazione • DTN Layer: fornisce il servizio per la gestione di messaggi Delay Tolerant inviati a entità SAMOA non necessariamente connesse in modo diretto

6. Scenari di Emergency Rescue Durante una situazione di emergenza ci sono tre problematiche da affrontare: Tecnologiche:  difficoltà  nell'implementare  gli  adeguati  sistemi  di comunicazione Sociologiche:  devono  comunicare  gruppi  di  persone  eterogenee Organizzative:  difficoltà  nella  gestione  di  molte  informazioni  imprecise Possibile soluzione? Lacreazione di reti sociali contex­aware trautenti fisicamente vicini per una rapida diffusione delle informazioni -> Utilizzo del framework SAMOA Ulteriore problematica: possibilità che nodi della rete sociale rimangano isolati per un periodo di tempo prolungato Possibile soluzione? Implementazione di un servizio aggiuntivo che permetta di inviare messaggi tra entità non direttamente connesse tramite un meccanismo di forwarding -> DTN Architecture

7. Delay Tolerant NetworkingArchitecture La DTN Architecturesi propone come obiettivo la possibilità di far comunicare tra loro reti indipendenti, mutuamente incompatibili caratterizzate da ritardi di trasmissione molto variabili, da periodi di perdita delle connessioni di durata arbitrariamente lunga, da alti tassi di errore e da forte asimmetria di trasmissione dei dati nelle due direzioni. Fornisce servizi chiave come la memorizzazione, la ritrasmissione e il forwarding di messaggi asincroni al fine di garantire l’affidabilità alla comunicazione Si basa su due concetti fondamentali: regione: parte della rete globale che comprende uno o più nodi gateway: nodo con elevate capacità computazionali che ha il compito di gestire i messaggi che riceve da altri nodi e di forwardarli

8. Delay Tolerant NetworkingArchitecture Il DTN Layer che abbiamo aggiunto all'architettura è un'estensione di SAMOA, è stato quindi necessario mappare le strutture tipiche della DTN Architecture con quelle del middleware:

9. Delay Tolerant Networking Manager Protocollo DTN: comprende tutte le primitive di invio e ricezione dei messaggi DT Un pool di thread per gestire l'invio dei messaggi DT e la ritrasmissione di pacchetti non giunti a destinazione Un pool di thread per gestire la ricezione dei messaggi DT e le richieste in caso di errore Una cache: un database all'interno del quale vengono memorizzati i messaggi DT. Ha anche il compito di aggiornare il TTL di ogni messaggio, provvedendo alla cancellazione dei messaggi scaduti Un gestore dello stato per gestire lo stato del protocollo DTN e lo stato del protocollo di scambio File

10. DTN Service Il DTN Service si occupa dell’invio/ricezione di messaggi DT I DT messages vengono memorizzati in una cache per forwarding futuri anche dopo un certo periodo di tempo I ruoli all’interno del DTN Service sono 3: sender (sia client che manager) receiver(sia client che manager) forwarder(solo manager) I messaggi DT vengono scambiati in base alla selezione del profilo dei destinatari, ci sono due differenti livelli di profilo specificabili dal sender del messaggio: Place Profile Target (PP) User Profile Target (UP)

11. DTN Service: scambio di messaggi Quando un client entra in prossimità fisica con un manager gli invia tutti i messaggi DT che ha memorizzato in cache Quando due manager entrano in prossimità fisica si inviano reciprocamente i messaggi DT che hanno memorizzato in cache Quando due client entrano in prossimità fisica non avviene nessuno scambio di messaggi DT. Due client necessitano sempre dell’intermediazione di un manager. Quando un manager riceve un messaggio DT verifica il match dei profili ed eventualmente inoltra il messaggio al proprio livello applicativo. Successivamente invia il messaggio agli altri manager. Infine verifica il match con i profili dei client presenti nella sua rete sociale (PSN) ed eventualmente provvede alla consegna ai client del messaggio appena ricevuto.

12. DTN Service: la cache La cache è stata realizzata su un database db4o (DataBaseForObjects), un database a oggetti open source su file facilmente integrabile con Java Tutti i messaggi, sia inviati che ricevuti, sia che si tratti di client che di manager, vengono salvati in cache I messaggi devono essere serializzati per essere inseriti in cache e deserializzati per esser letti e modificati Per rendere più leggero l’accesso alla cache i file allegati vengono salvati esternamente su disco visto che db4o non è adatto a grosse mole di dati

13. DTN Service: la cache Oltre al campo messaggio, ogni tupla del database contiene altri campi necessari alla gestione: messagehash la flagreadable la flagdeleteAfterSend threadTTLController: serve per controllare il timeto live di tutti i messaggi presenti in cache, è un thread che viene fatto partire dal costruttore della classe DTNMCache e può esserne specificato l'intervallo tra un controllo e l'altro

14. Test effettuati e conclusioni I test sono stati eseguiti su una rete locale utilizzando quattro computer: 2manager e 2client Test di forwarding: solo 2 entità connesse alla volta -> test positivo Test di carico elevato: tutte e 4 le entità connesse Contemporaneamente -> qualche malfunzionamento

15. Test effettuati e conclusioni Aspetti negativi sorti dai test: bassa velocità di scambio file allegati di grosse dimensioni (troppi pacchetti persi) problemi di gestione vari (failurebizantine) nel test con tutte e 4 le entità connesse discordanze di TTL tra le varie entità: possibili forwarding per messaggi già ricevuti o scaduti Aspetti positivi: possibilità di comunicazione asincrona possibilità di utilizzare SAMOA anche in scenari di emergenza grazie alla nuove caratteristiche SAMOA ha acquisito maggiore affidabilità e dinamicità recoverabilitye reability: consistenza del sistema grazie a un buon utilizzo degli stati anche in caso di disconnessioni temporanee