P2P Reliable Multicast Messenger Progetto e realizzazione di un software peer to peer per comunicazioni di gruppo

Introduzione Il progetto Il progetto consiste nella realizzazione di un software di messaggistica istantanea, senza la presenza di un server centralizzato, che fornisca alcune garanzie di affidabilità. Obiettivi Questo progetto si pone anche l’obiettivo di sperimentare protocolli di comunicazione alternativi a quelli esistenti per scontrarsi con le difficoltà che ne derivano.

Architettura Peer

Struttura di un Pacchetto Corpo del messaggioMittente del pacchettoID della conversazione Tipo di pacchetto: ATOMIC:token per le operazioni atomiche NEWUSER:creazione nuovo utente NEWCONV:creazione nuova conversazione MESSAGE:messaggio testuale DISCOVER:scoperta di nuove conversazioni HEART:heartbeat per la rilevazione dei crash

Struttura di un Peer

Atomicità Operazioni che richiedono atomicità: Inserimento di un nuovo utente (per garantire la consistenza dell’id) Aggiunta di una conversazione (per garantire la consistenza dell’id) Invio di un messaggio (per garantire la relazione d’ordine) Il protocollo è il seguente: 1.L’utente che deve eseguire una operazione atomica incrementa il valore di una variabile locale booked che rappresenta il numero di richieste di prenotazione del token, 2.Appena arriva il token se la variabile booked è maggiore di zero l’utente si impossessa del token, decrementa il valore di booked ed esegue l’operazione atomica inviando il messaggio relativo, 3.Quando il messaggio torna al mittente viene rilasciato il token. Un token di anello + uno per ogni conversazione Per garantire ordinamento e sincronizzazione

Affidabilità (1) Ipotesi di guasto Non sono ammessi guasti simultanei di due utenti consecutivi nell’anello (TTR<TBF), Non sono ammessi guasti in fase di inserimento nell’anello. Replicazione Meccanismo di replicazione passivo a copie calde Ogni peer è copia del successivo tenendo traccia dei messaggi che il successivo ha ricevuto ma non ha ancora inviato al suo successivo. Ogni peer possiede una nextQueue che viene aggiornata a ogni conferma di invio ricevuta dal successivo (checkpoint event-driven). Il successivo, al suo crash, viene escluso dall’anello e la nextQueue del precedente viene inviata al nuovo successivo. Per evitare perdita e duplicazione dei messaggi

Affidabilità (2) Protocollo 1.A estrae un pacchetto dalla outQueue, lo invia a B e lo inserisce nella sua nextQueue (checkpoint), 2.B riceve il pacchetto, lo analizza e lo inserisce nella sua outQueue, 3.B estrae il pacchetto dalla outQueue, lo invia a C e invia la conferma ad A, 4.A toglie il pacchetto dalla sua nextQueue (checkpoint). Quando B va in crash si esegue la seguente procedura di recovery: 1. A si accorge del crash di B perché non riesce più a inviargli pacchetti HEART, 2. A chiude la sendSocket con B e apre una nuova sendSocket con C, 3. A invia a C tutti i pacchetti che sono nella nextQueue, 4. C deve controllare che i pacchetti in arrivo da A non siano già presenti nella sua coda di ingresso. Indispensabile per evitare la duplicazione dei pacchetti !!!! Chiamiamo A, B e C tre peer consecutivi nell’anello.

Protocolli (1) Inserimento nell’anello 1.A si collega al sistema specificando l’indirizzo IP e la porta della serverSocket di B e imposta immediatamente la sua receiveSocket collegata con B. 2.B in modo atomico invia un messaggio NEWUSER nell’anello al fine di avvisare gli utenti dell’inserimento di un nuovo utente (aggiornamento del MAXID). 3.Quando il NEWUSER arriva al precedente di B esso provvede ad impostare A come nextNext (successivo del suo successivo). 4.Quando il NEWUSER torna a B esso provvede ad inviare ad A le seguenti informazioni: 1.MAXID degli utenti 2.MAXID delle conversazioni 3.Le informazioni dell’utente C che diventerà il successivo di A 4.Le informazioni dell’utente successivo a C che diventerà il successivo del successivo di A 5.La outQueue e la nextQueue 5.A riceve le informazioni ed aggiorna le sue strutture locali. 6.B imposta la sua sendSocket collegata con A. 7.A imposta la sua sendSocket collegata con C. 8.C imposta la receiveSocket collegata con A. Chiamiamo A l’utente che si vuole collegare al sistema, B l’utente al quale A si collega e C l’utente successivo a B. Se all’indirizzo specificato da A non viene trovato nessun utente il sistema provvede alla creazione dell’anello che consiste nel collegare la sendSocket di A con la sua receiveSocket e di impostare gli utenti successivi uguali ad A. Infine inserisce nell’anello il token ATOMIC.

Protocolli (2) Creazione di una conversazione 1.A crea la conversazione specificandone il titolo. 2.A invia in modo atomico un messaggio NEWCONV al fine di aggiornare il MAXID delle conversazioni. 3.A inserisce nell’anello un messaggio DISCOVERY che indica id e titolo della conversazione. 4.A inserisce nell’anello il token ATOMIC relativo alla conversazione creata. Monitoraggio delle conversazioni 1.A un DISCOVERY contenente id e titolo della conversazione. 2.Se A non possiede nella propria lista (conversations) la conversazione con id specificato la aggiunge altrimenti ignora il messaggio. 3.A ritrasmette il DISCOVERY. Chiamiamo A l’utente che vuole creare una nuova conversazione.

Protocolli (3) Comunicazione tra gli utenti 1.L’utente scrive e invia un messaggio relativo a una joinedConversation. 2.Viene inviato in modo atomico un pacchetto MESSAGE che indica id del mittente, id della conversazione e testo del messaggio. 3.Gli utenti che sono iscritti alla conversazione visualizzeranno il messaggio e ritrasmetteranno il pacchetto. 4.Il mittente del pacchetto visualizzerà il proprio messaggio e lo toglierà dall’anello. Uscita dall’anello B rileva il crash di C quando non riesce ad inviargli pacchetti HEART, B stabilisce una connessione con D e lo imposte come suo next, D invia le informazioni di E a B che lo imposta come nextNext, B invia la nextQueue a D che la aggiunge alla sua inQueue controllando che non ci siano pacchetti doppi, B invia ad A le informazioni relative a C che A imposterà come suo nextNext. Vettore delle conversazioni a cui l’utente sta partecipando AEBD C

Conclusioni Protocollo alternativo per la gestione dell’anello (no gestore, no time-out, no election-token). Motivazioni: Difficile dimensionare il time-out (quanti utenti collegati?) Ulteriore ritardo nelle comunicazioni (time-out per ogni crash) Notevole utilizzo delle risorse (trasmissioni continue) Struttura semplice per realizzare il multicast ma poco adatta per applicazioni real-time (un software di messaggistica istantanea richiede che il ritardo nelle comunicazioni sia il minimo possibile).