Progetto di un sistema di comunicazione di gruppo con multicast causale Reti di Calcolatori L-S Marco Canaparo Matricola

Struttura della presentazione Requisiti Analisi dei requisiti Analisi dei protocolli utilizzati Implementazione Conclusioni e sviluppi futuri

Requisiti del progetto Realizzazione di un group communication system view- oriented dinamico; Membri del gruppo peer-to-peer: coordinamento senza un’entità privilegiata; Comunicazione tramite invio di messaggi al gruppo protocollo IGMP; Per quanto riguarda lo scambio di messaggi si deve rispettare ordine FIFO e causale; Aggiunta di reliability tramite ritrasmissione di messaggi persi Meccanismo per la crash detection (fault tolerance) Implementazione di servizi acceduti come oggetti remoti(RMI)

Analisi dei requisiti – sistema di view Sistema view-oriented Ogni componente possiede una view che rappresenta lo stato attuale del gruppo Ogni view dovrà essere aggiornata e consistente con le view degli altri componenti Utilizzo di un meccanismo per le informazioni di membership Tre eventi che danno origine alla modifica delle view Join : adesione al gruppo Leave : uscita dal gruppo Crash : blocco di un membro

Analisi dei requisiti – meccanismi per la reliability Multicast IGMP al quale si aggiunge affidabilità Gestione dell’omissione dei messaggi Il mittente ha la responsabilità di verificare l’avvenuta ricezione dei messaggi inviati attraverso la ricezione degli ack Monitoring e crash detection Sistema per l’individuazione di componenti bloccati  Crash verrà rilevato in modo ipotetico da ogni membro basandosi su timeout

Sincronizzazione view - osservazioni Ambiente asincrono Messaggi di “join” e “leave” vengono ricevuti in modo asincrono Possibili inconsistenze temporanee tra le view dei membri anche a fronte di eventuali crash I messaggi verranno consegnati a tutti i membri in ordine e senza duplicati se: View complete e consistenti Membri non bloccati Tempi di ricezione sono compatibili con timeout di crash detection

Multicast – reliability M1 outputBufferinputBufferM Reliability: ogni messaggio in uscita viene mantenuto nel supporto finché tutti i destinatari non inviano un messaggio di ack a testimoniare l’avvenuta ricezione. Periodicamente in assenza di ack si effettuano dei rinvii per un certo numero di volte M M M2 M3 Ordinamento FIFO dei messaggi: attraverso la numerazione dei pacchetti lato mittente e la bufferizzazione lato ricevente

Protocolli utilizzati - join M1M2 M3 M1 M2 M1 M3 M2 M1 M3 M4 M1 M2 M3 join has-joined M4 ack Join: fase critica M4 non conosce i processi che fanno parte del gruppo

Protocolli – leave M1M2 M3M4 M1 M2 M1 M3 M2 M1 M3 M4 M1 M2 M3 leave ack

Protocolli – crash detection M1M2 M3M4 M1 M2 M1 M3 M2 M1 M3 M4 M1 M2 M3 ack msg

Protocolli – crash detection M1M2 M3M4 M1 M2 M1 M3 M2 M1 M3 M4 M1 M2 M3 suspect-crashed applicativo F

Protocolli – crash detection M1M2 M3M4 M1 M2 M1 M3 M2 M1 M3 M4 M1 M2 M3 F hello crashed

Protocolli – crash detection Unreliable failure detector È un meccanismo che funziona tramite ipotesi di crash A carico dei membri non crashed Legato alla presenza o meno di omissione di messaggi e al dimensionamento del timeout Critica la scelta del dimensionamento del timeout Piccolo  sistema con continui sospetti Grande  eccessivo numero di inconsistenze

CBCAST Ordinamento causale garantisce che i messaggi in relazione causa-effetto di mittenti diversi siano ricevuti dai gruppi in ordine. Si basa su: Vector time: protocollo di consegna basato su un orologio logico Legge per il delivery causale

CBCAST – Vector time pipi pjpj pkpk pkpk pjpj pipi … VT(p i ) pkpk pipi pjpj … pjpj pipi pkpk … M pipi VT(p i ) =VT(p i )+ 1 p j confronta VT di M con il proprio VT e lo modifica così  k є 1 … n : VT(p j )[k] = max(VT(p j )[k], VT(m)[k]) VT(p k ) VT(p j )

CBCAST – Vector time Ogni membro p i è dotato di un vettore di clock logici nel quale sono memorizzati sia il valore del clock del processo stesso sia quello degli altri Prima di inviare un messaggio incrementa il clock logico relativo a se stesso e inserisce il vettore nel messaggio Lato ricevente alla consegna del messaggio si modifica il proprio vector clock scegliendo il massimo tra il valore contenuto nel messaggio e il valore corrente

CBCAST – causal delivery rule Lato ricevente prima di effettuare la consegna del messaggio sarà necessario che siano state verificate le condizioni per il delivery causale. 1. VT(msg)[sender_id] = VT(receiver)[sender_id] + 1; 2. VT(msg)[k] <= VT(receiver)[k],  k, k≠sender_id; Il messaggio msg è il successivo inviato dal sender Dall’ultimo messaggio inviato dal mittente, gli altri membri non ne hanno inviati altri

CBCAST A{4,6,5} B{4,6,5} C{4,6,5} M1{4,6,6} B{4,6,6} A{4,6,6} M2{4,7,6} C{4,7,6} A{4,7,6} M1{4,7,6}

Pubblicazione dei servizi Ogni membro del gruppo deve offrire agli altri dei servizi accessibili tramite oggetti remoti What-services: richiedo tutti i servizi offerti da tutti i componenti del gruppo Request-service service_name: cliente è interessato ad un preciso servizio con un certo nome Make-service: utilizzo del servizio scelto I servizi disponibili non sono noti a priori ma possono cambiare nel tempo per questo si è deciso di utilizzare meccanismi di riflessione del codice

Implementazione

Conclusione e sviluppi futuri I test sono stati svolti prevalentemente in locale Applicazione con lo scopo di sperimentare protocolli per la comunicazione in un group communication system Si sono scelti i gruppi view-oriented con modifica nel tempo dei componenti del gruppo qualità del servizio nella consegna dei messaggi e loro ordinamento Inoltre c’è la possibilità di inserire servizi per i vari componenti del gruppo accessibili come oggetti remoti Limiti Utilizzo di più thread per l’implementazione dei componenti del gruppo. Tecnica poco efficiente Eccessivo utilizzo dei messaggi multicast anche per l’invio di messaggi di hello Failure detector che riesce a correggere il tempo di timeout in caso di errore nell’individuazione di crash Possibilità di avere una politica di negative ack Estensione a più gruppi