P2P Reliable Multicast Messenger

1
P2P Reliable Multicast Messenger

• Progetto e realizzazione di un software peer to
  peer per comunicazioni di gruppo

2
Introduzione
Il progettoIl 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
lobiettivo di sperimentare protocolli di
comunicazione alternativi a quelli esistenti per
scontrarsi con le difficoltà che ne derivano.
3
Architettura
4
Struttura di un Pacchetto
5
Struttura di un Peer
6
Atomicità

• Operazioni che richiedono atomicità
• Inserimento di un nuovo utente (per garantire la
  consistenza dellid)
• Aggiunta di una conversazione (per garantire la
  consistenza dellid)
• Invio di un messaggio (per garantire la
  relazione dordine)

• Il protocollo è il seguente
• Lutente che deve eseguire una operazione atomica
  incrementa il valore di una variabile locale
  booked che rappresenta il numero di richieste di
  prenotazione del token,
• Appena arriva il token se la variabile booked è
  maggiore di zero lutente si impossessa del
  token, decrementa il valore di booked ed esegue
  loperazione atomica inviando il messaggio
  relativo,
• Quando il messaggio torna al mittente viene
  rilasciato il token.

Un token di anello uno per ogni conversazione
7
Affidabilità (1)

• Ipotesi di guasto
• Non sono ammessi guasti simultanei di due utenti
  consecutivi nellanello (TTRltTBF),
• Non sono ammessi guasti in fase di inserimento
  nellanello.

• 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
  dallanello e la nextQueue del precedente viene
  inviata al nuovo successivo.

8
Affidabilità (2)

• Protocollo
• A estrae un pacchetto dalla outQueue, lo invia a
  B e lo inserisce nella sua nextQueue
  (checkpoint),
• B riceve il pacchetto, lo analizza e lo inserisce
  nella sua outQueue,
• B estrae il pacchetto dalla outQueue, lo invia a
  C e invia la conferma ad A,
• A toglie il pacchetto dalla sua nextQueue
  (checkpoint).
• Quando B va in crash si esegue la seguente
  procedura di recovery
• A si accorge del crash di B perché non riesce
  più a inviargli pacchetti HEART,
• A chiude la sendSocket con B e apre una nuova
  sendSocket con C,
• A invia a C tutti i pacchetti che sono nella
  nextQueue,
• C deve controllare che i pacchetti in arrivo da
  A non siano già presenti nella sua coda di
  ingresso.

9
Protocolli (1)
Se allindirizzo specificato da A non viene
trovato nessun utente il sistema provvede alla
creazione dellanello che consiste nel collegare
la sendSocket di A con la sua receiveSocket e di
impostare gli utenti successivi uguali ad
A. Infine inserisce nellanello il token ATOMIC.
10
Protocolli (2)
11
Protocolli (3)
Vettore delle conversazioni a cui lutente sta
partecipando
12
Conclusioni

• Protocollo alternativo per la gestione
  dellanello (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).