Progetto di: Daniele De Angelis Corso di: Reti di Calcolatori LS Un sistema fault tolerance per protocollo Diffie-Hellman

Sviluppare un sistema per il protocollo Diffie Hellman per un numero di partecipanti superiore a 2 Garantire consistenza nell’accordo di chiave Obiettivi

Ogni utente deve avere la possibilità di: unirsi al gruppo comunicare in cifrato per mezzo di una chiave condivisa aggiornata dinamicamente uscire dal gruppo Il sistema deve: mantenere consistente l’accordo di chiave reagire a fronte di variazioni del gruppo e a fronte di fault Requisiti

Descrizione del protocollo GDH

Message Comunicazione uno molti La struttura a ring semplifica il progetto e ottimizza le risorse L’ultimo nodo è il gestore Intercambiabilità del ruolo a fronte di variazioni Struttura del sistema

1 createGroup(name,endpointpeer) or enterGroup(name,endpoint) or groupList() 2 Refresh Inizializzazione del sistema 3 GroupInfo Gestore del gruppo Mantiene le informazioni per ogni gruppo Mantiene una sessione per ogni peer, rinnovata periodicamente (soft state)

P1 P4 P2 P3 Il protocollo GDH(1) Fase di UpFLow

P1 P4 P2 P3 Il protocollo GDH(2) Fase di DownFlow

P1 Pn Pn+1 Protocolli Ingresso nel gruppo: Avviene sempre con il primo nodo Uscita dal gruppo: Uscita volontaria oppure guasto P2 P1 P3 Aggiornamento della chiave per ambedue le operazioni

Ipotesi di guasto singolo Ogni peer mantiene in memoria le informazioni che riguardano il successore del successore Indentificazione del guasto mediante HeartBeat al successore Recupero: Recupero dei dati del nuovo successore Invia di un messaggio di notifica al nuovo successore Propagazione del messaggio fino al nodo gestore e ripristino chiave di gruppo Il server automaticamente cancella il peer dal gruppo Tolleranza ai guasti

Middleware ICE Middleware DOC (ZeroC) Più efficiente di Corba Invocazione statica (SLICE) Asyncronous method dispatch per invio di messaggi di accordo di chiave Invocazione sincrona per il refresh della sessione sul server e per messaggi di identificazione del guasto Applicato per tutte le interazioni

Struttura di un peer RingRecovery ClientProtocol ClentFactory Messaggi di protocollo Richiamato all’inizio per instanziare un servant Messaggi HeartBeat Succesore nextSuccessore new RecoveryThread ICEICE ICEICE Verso il server e verso il successore

Struttura del server ServerGrFactory ServerGroup new GroupInfo Server parallelo: genera un servant per ogni cliente ICEICE Messaggi di gestione gruppi Messaggi di refresh della sessione

Informazioni del peer Nome Indirizzo IP Porta Informazioni del gruppo Nome del gruppo Informazioni del primo nodo del gruppo Informazioni scambiate Per la connessione P2P Per sapere con chi iniziare il protocollo

Sistema efficiente Estendibile anche per sistemi eterogenei La struttura a ring è autosufficiente Possibili estensioni Sviluppo di Location Service (copia fredda mediante messaggi di refresh) Sistema master-slave per il server Replicazione per ogni peer (disconnessioni momentanee o diverse utilità) Conclusioni e svilppi futuri