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

Presentazione sul tema: "PERMESSO PERsistent MESSaging in ad hOc networks Corso di Reti di Calcolatori LS – AA 2005-2006 Presentazione di Davide Sansovini Professore: Antonio Corradi."— Transcript della presentazione:

1 PERMESSO PERsistent MESSaging in ad hOc networks Corso di Reti di Calcolatori LS – AA 2005-2006 Presentazione di Davide Sansovini 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?!? Reti isolate!! Limitare l’overhead e il costo aggiunto Sincronismo & overhead

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  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 A C B 3 4 7 8 2 3 TS=3 TS=2 9 A C B 10 70 9 12 11 M1 M2 12 13 M3 TS=7 8 TS=8 TS=11 M5 M4

8 Chatting Asincrono senza PS  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 A B D C:3B:4 C B:10 D:5 ServiceSenderReceiver Timestamp Payload

9 Chatting Asincrono con 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 B:4 PS A B C PS:9 C:8 PS:12 C:11 A PS B 100 12 11 (not friend) 12 13 TS=0 8 TS=8 TS=10 C 7 9 8 11 (friend) TS=0 1 TS=12 13 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 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. client Server Master Server Slave 1 2 3

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.