Progetto PERMESSO PERsistent MESSagging in ad h Oc

Progetto PERMESSO PERsistent MESSagging in ad h. Oc networks Presentazione di Agnese Dal Monte Progetto di Gruppo di Manuela Bassetti, Agnese Dal Monte, Elisabetta Visciotti Reti di Calcolatori LS – AA. 2006 -07 Prof. Antonio Corradi Tutor del progetto: Eugenio Magistretti

Agenda � Introduzione ◦ Scenario Applicativo ◦ Specifiche e scelte progettuali ◦ Struttura generale � Chatting sincrono ◦ ◦ � Apertura conversazione Scambio di messaggi Chiusura conversazione Valutazioni e risultati sperimentali Amicizia ◦ Ricerca amici per UUID ◦ Valutazioni e risultati sperimentali ◦ Cancellazione di un amico (cenni)

Scenario applicativo � MANET ◦ Mancanza di infrastruttura e di nodi coordinatori ◦ Scarsa affidabilità del mezzo di comunicazione ◦ Frequenti cambiamenti di topologia � Dispositivi portatili ◦ Dispositivi eterogenei (smarthphone, PDA, laptop) a capacità computazionale e memoria più o meno limitate. ◦ Scarsa autonomia (alimentazione a batteria) Stato dell’ arte e strumenti Strumenti proprietari e non standard con forti problemi di compatibilità

Specifiche e scelte progettuali � Specifiche di progetto ◦ ◦ � Utilizzo della J 2 ME Utilizzo di UDP come protocollo di trasporto Comunicazione attraverso l’interfaccia wireless 802. 11 Creazione di protocolli ad-hoc Assunzioni semplificative ◦ Dispositivi a distanza 1 -hop ed in diretta visibilità ◦ Dispositivi con IP fisso (una volta entrati nella MANET) ◦ Rete MANET preesistente � Scelte ◦ J 9 di IMB configurazione CDC 1. 1 e PP ◦ Web. Sphere Everyplace ME con emulatore Nokia ◦ db 4 o come database per memorizzare i dati locali

Struttura generale Servizi di Amicizia per UUID Amicizia per Profilo Cancellazione Chatting Sincrono instant messaging tra due amici presenti contemporaneamente nella MANET Chatting Asincrono messaggistica persistente tra due amici non presenti contemporaneamente nella MANET (in presenza o meno del Persistent Server) Servizio di Discovery e Servizio di presenza Gestione entrata ed uscita dei nodi e rilevazione di eventuali cadute � Il sistema si basa sullo scambio di messaggi Datagram UDP. Per ogni servizio è stata dedicata una porta nota a priori.

Chatting Sincrono Il servizio permette lo scambio di messaggi tra due amici presenti contemporaneamente nella MANET. � � Specifiche: una porta dedicata al servizio e creazione di un thread per ogni conversazione dispatching dei messaggi al thread che gestisce la specifica conversazione Scelta: numero massimo di conversazioni apribili (dovuta alle caratteristiche dei dispositivi: ridotta capacità computazionale, memoria limitata, problemi di schedulazione dei thread, interfacce grafiche limitate) Al servizio si accede dalla schermata principale selezionando il nome dell’amico online con cui dei Apertura Scambio si vuole comunicare. Si aprirà così il pannello conversazione messaggi di conversazione. Chiusura conversazione

Apertura conversazione La conversazione è avviata dopo un protocollo di handshake Viene visualizzato il pannello in attesa di avviare una conversazione. OPEN_CONVERSATION ACK_OPEN_ACCEPT Viene visualizzato il pannello e avviato il thread dedicato alla conversazione. E’ avviato il thread dedicato alla conversazione. ACK_OPEN_REFUSE: Node. B ha un numero massimo di conversazioni aperte. ACK_OPEN_DELETE: Node. B non ha l’utente A nella lista degli amici e ha scelto di forzare la propria eliminazione dalla lista di A.

Scambio dei messaggi Per garantire la visualizzazione FIFO dei messaggi di ogni conversazione (senza essere però bloccanti) sono stati inseriti: � � � Un numero di sequenza ◦ Numero di sequenza relativo ai messaggi inviati da un mittente allo specifico destinatario Un “algoritmo di ordinamento” ◦ E’ stato creato un buffer locale per ogni conversazione in cui memorizzare i messaggi giunti fuori sequenza per poi essere visualizzati in ordine all’arrivo del messaggio atteso o al riempimento del buffer (o allo scadere di un timeout). Ack cumulativo ◦ Ogni t messaggi ricevuti viene inviato un ack con l’indicazione del messaggio atteso. Il mittente conserverà in un buffer locale alla conversazione un numero limitato di messaggi non confermati e provvederà eventualmente al rinvio.

Chiusura conversazione Questa fase è importante perché permette di liberare risorse allocate per la conversazione Il pannello della conversazione viene chiuso CLOSE_CONVERSATION ACK_CLOSE Il pannello della conversazione viene chiuso e le risorse liberate. Le risorse della conversazione sono liberate Una volta chiusa la conversazione sarà possibile riaprirla dopo una nuova fase di handshake.

Valutazioni e risultati sperimentali � Apertura conversazione ◦ Permessa solo se entrambi non ne hanno già aperte un numero massimo ◦ L’handshake è utilizzato anche per ristabilire relazioni di amicizia in caso di inconsistenza dei database (raro) ◦ Nel caso la percentuale di perdita risulti rilevante con più dispositivi, è possibile impostare ritrasmissioni ◦ Protocollo a timeout � Scambio di messaggi ◦ Esecuzione di stress-test ◦ L’algoritmo permette di ricostruire quasi completamente la sequenza grazie all’ack cumulativo e al buffer (di 3 -5 messaggi), senza essere bloccante. ◦ E’ gestito il passagio offline (senza fase di chiusura) di un utente � Chiusura della conversazione ◦ E’ prevista una ritrasmissione data l’importanza del liberare le risorse ◦ Protocollo a timeout Tempi per protocollo (ms) APERTURA CHIUSURA 203 212 198 180 176 156

Amicizia per UUID Il servizio permette di stabilire una relazione biunivoca di amicizia con un altro utente di cui si conosce l’identificativo univoco. L’UUID dell’utente viene specificato nell’apposita form. Il sistema gestirà la ricerca (attraverso un broadcast della richiesta) e l’aggiunta (in caso di risposta positiva dell’amico). UUID specificato FRIENDSHIP_UUID A Utente B aggiunto alla lista degli amici. Ricerca terminata. FRIENDSHIP_ACK In caso di rifuto dell’amico sarà L’utente B accetta la mandato comunque il messaggio di relazione di amicizia: ack per. A aggiunto terminare utente allal’attesa. Nel caso in la risposta dell’amico non sia listacui degli amici. data/ricevuta entro un certo timeout la ricerca viene interrotta.

Valutazioni e risultati sperimentali � Reliability: ritrasmissione della richiesta nel caso non si riceva una risposta entro un timeout. ◦ La percentuale di perdita senza ritrasmissione è bassa, con la ritrasmissione nulla. (Valutazione da rivedere nel caso di multi-hop e dense-MANET) ◦ Protocollo a timeout � Inconsistenza tra i database: se l’amico è già in lista verrà mandato direttamente un messaggio di ack positivo. Una possibilità sarebbe quella di non interrogare l’utente coinvolto ma di accettare in ogni caso la richiesta di amicizia. In questo caso si aumenterebbe l’efficienza in quanto non sarebbe necessario attendere una risposta dell’utente (anche se solo per un timeout).

Cancellazione di un amico (cenni) Il servizio permette di cancellare un amico online. L’amico che si desidera rimuovere dalla propria lista viene specificato nell’apposita form. Il sistema gestirà l’eliminazione. Utente B rimosso dalla lista degli amici. La cancellazione per ora è gestita come semplice notifica. FRIENDSHIP_DELETE L’utente A rimosso dalla lista degli amici. Il una dense-MANET o comunque con l’aumentare delle probabilità di perdita sarà necessario introdurre un messaggio di ACK e prevedere almeno una ritrasmissione.

Conclusioni � Cause dei maggiori problemi: ◦ Dinamicità della rete e natura best-effort ◦ Caratteristiche dei dispositivi ◦ Funzionalità ristrette e spesso non completamente implementate degli strumenti disponibili � Principali soluzioni adottate: ◦ Servizio di presenza e ritrasmissioni ◦ Limitato utilizzo delle risorse ◦ Implementazione delle funzioni necessarie o adattamento a quelle disponibili � Il database db 4 o non è risultato completamente affidabile per la facilità con cui viene corrotto o per l’insicura accessibilità dei suoi file. L’applicazione realizzata riesce comunque a garantire un buon livello di qualità di servizio e ad essere affidabile per un numero di dispositivi limitato.

Sviluppi futuri � Miglioramento persistenza dati locali ◦ Necessità di far fronte ai problemi rilevati con db 4 o ad esempio con la replicazione o adozione di un altro database in cui salvare le informazioni locali. � Estensione al caso multi-hop ◦ Introduzione di un algoritmo di routing che permetta di recapitare i messaggi anche ad utenti non in diretta visibilità (ed analisi dei tempi e delle ritrasmissioni necessarie). � Scalabilità ◦ Analisi del funzionamento e delle prestazioni in una dense-MANET � Sicurezza ◦ Introduzione di meccanismi e politiche per garantire la sicurezza.