PERMESSO

1. Presentazione di Davide Sansovini PERMESSO PERsistent MESSaging in ad hOc networks Corso di Reti di Calcolatori LS – AA 2005-2006 Professore: Antonio Corradi Referente progetto: Eugenio Magistetti

2. Sommario • Introduzione • Caratteristiche progettuali • Ordinamento dei messaggi • Lamport • Scelte implementative • Quality of Service • Replicazione messaggi

3. Introduzione: le MANET • Composte da dispositivi portatili con scarse capacità: laptop, PDA, smart phone… • Nessuna infrastruttura di supporto • Altamente dinamiche e canali instabili

4. PERMESSO: Caratteristiche • Permettere la comunicazione fra due utenti: • Chatting sincrono: entrambi gli utenti sono connessi nello stesso momento • Chatting asincrono: gli utenti sono connessi in istanti di tempo distinti • Con o senza server • Gestione fasi di ingresso e uscita dalla rete • Con o senza server • Relazione di amicizia biunivoca per poter comunicare

5. Ordinamento dei messaggi • Ha lo scopo di mostrare all’utente i messaggi secondo il relativo ordine di invio • Come realizzarlo? • Orologi dei dispositivi • Unico clock o clock sincronizzati • Tempo universale (UTC, NTP) • Lamport Sincronismo?!? Sincronismo & overhead Reti isolate!! Limitare l’overhead e il costo aggiunto

6. Lamport • Realizzazione sistema di clock logici ad un costo accettabile • Relazione d’ordine parziale “” • Eventi concorrenti: time(A)<time(B) non implica AB • LCj = max (TSricevuto, LCjcorrente) + 1 • Basso utilizzo delle risorse: un intero • Relazione d’ordine totale “” con vector clock • In caso di LC uguali si guarda la priorità • Vj[k] = max (Vj[k], Vi[k]) per ogni k • Elevato utilizzo di risorse: vettore di interi da memorizzare e aggiornare • Impatto sulla dimensione del messaggio • Overhead dovuto alla dinamicità della MANET • In entrambi i casi perdita del concetto del tempo fisico

7. Chatting Sincrono C A B • Messaggi ordinati in base al TS trasportato • Logicamente: M1 precede M3 perché legati da relazione causale tramite M2 • Ritardo della rete risolto • Ricezione di M4 poi di M5 ma ordinamento inverso per il TS. • M4M5 • Eventuale canale nascosto • Aggiornamento LC = Sezione critica 10 7 0 8 M1 TS=8 9 M2 TS=7 11 12 TS=11 M3 12 13 C A B 2 7 3 TS=3 4 M4 TS=2 8 3 M5 9

8. Timestamp Service Sender Receiver Payload Chatting Asincrono senza PS A • Memorizzazione dei messaggi nella propria memoria  TS impostato all’atto di invio • Delivery verso il destinatario se si è connesso o verso un altro nodo se il mittente abbandona la rete  il TS non deve essere modificato • Il Timestamp è inserito in tutti i pacchetti e non modificabile • Il payload è vuoto in pacchetti di servizio (join, left…), contiene il testo (textmessage) o contiene altri pacchetti se è un forwardpacket B:4 D:5 C:3 B:10 B D C

9. Chatting Asincrono con PS PS • Preparazione del messaggio ed inoltro al PS • TS messaggio originale non modificato • Trasferimento LC al PS dal FORWARDPACKET • Ma il clock logico come viene aggiornato? • LC trasportato nei messaggi nella fase di join • LC = 0 quando si connette • LC aggiornato dai FRIENDONLINE PS:5 PS:9 A B:4 C:8 PS:12 B C C:11 PS A B C (not friend) (friend) 7 10 0 8 TS=10 11 11 TS=0 TS=0 1 TS=0 8 12 12 TS=12 13 TS=8 13 9 14

10. Quality of Service • Si vuole ridurre la probabilità di perdita dei messaggi nel caso del chatting asincrono. • Se il server non è connesso si dovranno replicare i messaggi sugli altri nodi presenti nella rete. • Nel caso in cui il server è connesso, è lui a gestire i messaggi e si dovrà realizzare una replicazione della sua memoria.

11. QoS senza server • Scenario: • Ogni dispositivo può avere nella propria memoria sia “messaggi offline” spediti da lui sia messaggi lasciati da altri che sono usciti dalla rete. • Se questo cade improvvisamente, tutti i messaggi memorizzati vanno persi. • Soluzione: • In fase di uscita inviare i messaggi offline ai due utenti con più memoria disponibile invece che solo ad un nodo. • Rimane invariata la procedura per l’eliminazione dei messaggi più vecchi da effettuarsi in entrambi i nodi. • Emergono problemi per la gestione dei duplicati: • Nel join alla rete si ricevono gli stessi messaggi più volte. • Aggiunta di un campo hash nel pacchetto come identificativo per filtrare i duplicati. • Se si calcola l’hash nel momento della creazione del messaggio non si deve ricalcolare tutte le volte che ricevo un messaggio.

12. Server Master client 3 1 Server Slave 2 QoS con server • Scenario: • In caso di caduta del server si perdono tutti i messaggi offline presenti nella sua memoria. • Soluzione: • Replicazione del server tramite il modello master-slave. • Copie calde per avere lo slave aggiornato. • Aggiornamento copia primaria lazy per non ritardare eventuali risposte. • Lo slave deve controllare periodicamente la presenza del master e sostituirlo se necessario. • Ripetizioni dei messaggi di controllo per evitare di interpretare nel modo sbagliato la mancata ricezione di una risposta.

13. Sviluppi futuri • Bilanciamento del carico di lavoro del server  considerando che non ha capacità illimitate ma simili agli altri. • Sistemi di ack e ripetizioni dei messaggi per avere la certezza della consegna  si utilizza UDP. • Gestione multi-hop  si è supposto che gli utenti sono in visibilità diretta. • Sicurezza (identificazione degli utenti, cifratura dei messaggi, …)  attualmente trascurata.