Reti di Calcolatori LS Professor Antonio Corradi Ingegner Dario Bottazzi Presentazione di Francesco Fiori

Il progetto si è concentrato sulladattamento 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.

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

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

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

Durante una situazione di emergenza ci sono tre problematiche da affrontare: Tecnologiche: difficoltà nell'implementare gli adeguati sistemi di comunic azione 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 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

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 laffidabilità 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

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 ArchitectureDTN 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

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

Il DTN Service si occupa dellinvio/ricezione di messaggi DT I DT messages vengono memorizzati in una cache per forwarding futuri anche dopo un certo periodo di tempo I ruoli allinterno 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)

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 dellintermediazione 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.

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 laccesso alla cache i file allegati vengono salvati esternamente su disco visto che db4o non è adatto a grosse mole di dati Record della cache messageHashdtnMessageBytesreadabledeleteAfterSend

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

I 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

Aspetti 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