Presentazione di Davide Sansovini PERMESSO PERsistent MESSaging in

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

Sommario o Introduzione n o Ordinamento dei messaggi n n o Caratteristiche progettuali Lamport Scelte implementative Quality of Service n Replicazione messaggi

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

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

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

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

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

Chatting Asincrono senza PS A B: 10 o D: 5 B: 4 C: 3 B o D C o o Service Sender Receiver Timestamp Payload 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

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

Quality of Service o o o 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.

Qo. S senza server o Scenario: n n o Soluzione: n n o 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. 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: n n n 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.

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

Sviluppi futuri o o 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.