Delay Tolerant Network Architecture per SAMOA:

Mobile Social Computing applicato a situazioni di emergenza

Reti di Calcolatori LSProfessor Antonio Corradi

Ingegner Dario Bottazzi

Presentazione diFrancesco Fiori

Obiettivo del progettoIl 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.

Il framework SAMOA• Socially Aware and MObile Architecture (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

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

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

Scenari di Emergency RescueDurante 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? La  creazione  di  reti  sociali  contex aware  tra  utenti  fisicamente vicini per una rapida diffusione delle informazioni -> Utilizzo del framework SAMOAUlteriore problematica: possibilità che nodi della rete sociale rimangano isolati per un periodo di tempo prolungatoPossibile soluzione? Implementazione di un servizio aggiuntivo che permetta di inviare messaggi tra entità non direttamente connesse tramite un meccanismo di forwarding -> DTN Architecture

Delay Tolerant Networking Architecture• La DTN Architecture si 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ù nodigateway: nodo con elevate capacità computazionali che ha il compito

di gestire i messaggi che riceve da altri nodi e di forwardarli

Delay Tolerant Networking Architecture• 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:

DTN Architecture DTN Service

Regione: parte della rete globale che comprende uno o più nodi

Place-depent Social Network: gli utenti della regione saranno gestiti tramite il PSNM

Gateway: nodo con elevate capacità computazionali che ha il compito di gestire i messaggi ricevuti da altri nodi e di effettuarne il forwarding

Manager (sarà anche forwarder): nodo della rete responsabile della memorizzazione dei messaggi DT e del forwarding dei messaggi memorizzati nella cache ai nodi con cui entra in prossimità fisica

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

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)

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.

DTN Service: la cache• La cache è stata realizzata su un database db4o (DataBase For Objects), 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

Record della cachemessageHash dtnMessageByte

s readable deleteAfterSend

DTN Service: la cache• Oltre al campo messaggio, ogni tupla del database contiene altri campi necessari alla gestione:

• message hash• la flag readable • la flag deleteAfterSend

• thread TTLController: serve per controllare il time to 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

Test effettuati e conclusioniI test sono stati eseguiti su una rete locale utilizzando quattro computer: 2 manager e 2 client

Test di forwarding:solo 2 entità connesse alla volta-> test positivo

Test di carico elevato:tutte e 4 le entità connesse Contemporaneamente-> qualche malfunzionamento

Test effettuati e conclusioniAspetti negativi sorti dai test:• bassa velocità di scambio file allegati di grosse dimensioni (troppi pacchetti persi)• problemi di gestione vari (failure bizantine) 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à• recoverability e reability: consistenza del sistema grazie a un buon utilizzo degli stati anche in caso di disconnessioni temporanee