Progetto di un Group Communication System

1
Progetto di un Group Communication System

• Reti di Calcolatori LS
• A.A. 2003-2004
• Giampaolo Capelli

2
Obiettivi

• Realizzazione di un sistema per la comunicazione
  di gruppo
• basato su view (stato del gruppo visibile a un
  membro), con ipotesi di gruppo dinamico
• membri del gruppo peer-to-peer coordinamento
  senza centralizzazione
• comunicazione tramite invio di messaggi di
  gruppo invio di un messaggio a tutti i membri
  del gruppo (a quelli della view)

3
Obiettivi (2)

• Aggiunta di reliability al multicast
  ritrasmissione messaggi persi, ma senza
  duplicazione
• Tolleranza ai guasti dei membri del gruppo crash
  detection
• Ordinamento FIFO e causale dei messaggi
• Ogni membro può offrire dinamicamente al gruppo
  dei servizi
• acceduti come oggetti remoti
• scoperti tramite discovery

4
View

• View conoscenza che un membro ha del gruppo
• Gruppo dinamico variabile nel tempo, uso di un
  meccanismo di membership per costruire le view
• Problema di sincronizzazione e consistenza delle
  view, anche a fronte di eventuali crash dei membri

5
Scenario
1
1
1
2
2
2
3
1
3
3
4
2
4
4
3
4
6
Membership

• Problema della consistenza delle view nel tempo,
  a fronte di tre tipi di evento
• join adesione al gruppo
• leave uscita dal gruppo
• crash blocco
• join e leave notificati al gruppo con messaggi
  dagli stessi membri che aderiscono o abbandonano
• crash rilevato in modo ipotetico da ogni membro,
  basandosi su un timeout

7
Supporto per lo scambio di messaggi

• Multicast di IGMP, a cui si aggiunge reliability
• Il mittente ha la responsabilità di verificare
  lavvenuta ricezione dei messaggi inviati
  attende conferma (ack) di ricezione da parte dei
  membri della view
• Due categorie di messaggi
• di controllo
• ordinari (applicativi)
• Ordinamento causale oneroso, viene imposto solo
  sui messaggi ordinari
• Ordinamento FIFO imposto per tutti i messaggi
  tranne quelli critici, esempio di ipotesi di crash

8
semantica della Reliability per la consegna dei
messaggi

• sincronizzazione fra le view risolta in maniera
  passiva, nessun uso di sincronizzazioni forti
  (come ad es. 2 phase lock). Modifica delle view a
  fronte di
• rilevazioni di crash basate su ipotesi da
  confermare
• messaggi di join o leave ricevuti in maniera
  asincrona
• Possibili inconsistenze temporanee fra view dei
  membri
• garanzia di consegna dei messaggi a tutti i
  membri, in ordine e senza duplicati sotto le
  ipotesi di
• view complete e consistenti
• membri non bloccati
• tempi di ricezione compatibili con timeout di
  crash detection
• Altrimenti, consegna ai membri presenti nella
  view del mittente, a meno di loro crash

9
Protocollo di join

• Il nuovo arrivato, 3, manda un messaggio di join
  al gruppo, ancora non ne conosce la composizione
• Gli altri rispondono con un messaggio di conferma
  (has joined), utile a 3 per costruire la propria
  view (discovery)

has joined
join
10
Protocollo di join (2)

• il nuovo entrante, durante il join, non ha
  conoscenza del gruppo, perciò non può controllare
  che il proprio messaggio di adesione venga
  ricevuto da tutti
• è sufficiente che raggiunga un membro, il quale,
  divulgando il messaggio di tipo has joined,
  propagherà a tutti la notizia della sua entrata

11
Crash Detection

• a carico dei membri ancora vivi
• Non è un meccanismo esatto, funziona tramite
  ipotesi di crash (problemi di rete possono
  causare finti crash)
• Legato alla reliability del multicast un
  mittente aspetta conferma di ricezione, allo
  scadere di un timeout ritrasmette, ma dopo n
  volte sospetta dei destinatari che non hanno
  risposto.
• dimensione del timeout critica per le
  prestazioni
• rispetto alla frequenza media dei crash o alla
  velocità di comunicazione della rete
• Timeout piccolo ? sistema instabile (continui
  sospetti)
• Timeout grande ? molte inconsistenze (membri
  bloccati considerati come ancora vivi)

12
Crash Detection (2)
13
Crash Detection (3)

• È possibile la ricezione di messaggi da un membro
  M escluso per ipotesi di crash
• se M è stato escluso ingiustamente per un ritardo
  di risposta dovuto a rallentamenti nella rete
• oppure se, dopo il blocco, M riprende
  lesecuzione
• In entrambi i casi M non invia messaggi di join
  un suo messaggio provoca comunque la divulgazione
  dei messaggi has joined negli altri, che lo
  considerano nuovamente nel gruppo

14
Ritrasmissioni

• Messaggi inviati vengono bufferizzati fino a che
  non si ricevono gli ack dei destinatari o ne è
  stato dichiarato il crash
• Periodicamente, se non arriva lack, si riinviano
  fino a un certo numero di volte
• Fino a che il crash detector non inizia il
  protocollo di crash detection mandando al gruppo
  un sospetto

15
Ordinamento dei Messaggi

• FIFO tramite uso di numeri di sequenza
  progressivi e riordinamento sui riceventi
• Causale (solo per msg applicativi) protocollo
  basato su vector clock e causal delivery rule
• Ogni membro gestisce un vettore di clock logici,
  prima di inviare un msg incrementa di uno la
  propria componente e inserisce nel msg una copia
  del vettore
• Sui riceventi a ogni ricezione di un messaggio
  ordinario, si ritarda il delivery fino a che non
  è vera la causal delivery rule
• Al delivery si aggiornano le componenti del
  vector clock locale relative agli altri
  maxvalore nel msg, valore corrente

16
Causal delivery rule

• Delivery (consegna al livello applicativo)
  ritardato fino a che sono vere entrambe
• VT(msg)sender VT(receiver)sender_id1
• VT(msg)k lt VT(receiver)k, ?k, k?sender_id
• Il cui significato è
• Il msg è il successivo inviato dal mittente
• Dallultimo msg inviato dal mittente, gli altri
  non ne hanno mandati altri

17
Protocollo per causal order

• Gruppo in evoluzione nel tempo necessaria una
  fase preliminare di scambio di informazioni di
  clock tra membri.
• In questa fase si ignora la causal delivery rule
  e non è garantito lordinamento causale
• esempio in caso di aggiunta di un nuovo membro
• non è un problema, se in questa fase si mandano
  solo msg di controllo

18
Protocollo per causal order
C0,0,3
C3,0,3
C3,6,3
C3,6,4
C3,6,5
C3,7,5
B3,6,4
B0,5,0
B3,5,0
B3,6,0
B3,7,5
B3,6,5
3,7,5
A2,0,0
A3,6,5
A3,7,5
A3,0,0
A3,6,0
A3,6,4
19
Pubblicazione di servizi

• I membri possono pubblicare dei servizi (come
  oggetti remoti) a disposizione del gruppo. I
  membri non hanno alcuna conoscenza a priori dei
  servizi.
• Un membro può
• eseguire discovery dei servizi, ottenendo
  lelenco e la locazione di quelli attualmente
  disponibili, assieme alle funzionalità che offre
• richedere un particolare servizio e invocarlo, se
  disponibile

20
Realizzazione del prototipo

• Uso della piattaforma Java
• Socket multicast (con datagrammi UDP)
• Servizi come oggetti remoti acceduti con RMI,
  esecuzione di rmiregistry sui membri
• Uso della reflection di Java per conoscere
  linterfaccia dei servizi (signature dei metodi)
• Semplificazioni
• un servizio ? membro
• ack mandati in unicast con UDP

21
Limiti e sviluppi futuri

• IGMP per il multicast uso limitato
• Sistema poco scalabile
• alto numero di messaggi di controllo
• meccanismo pesante per la gestione degli ack si
  attende un ack per ogni messaggio
• Possibili migliorie
• politiche di ritrasmissione con ack relativi a un
  insieme di messaggi e selective repeat, ack
  negativi
• uso di unicast, invece che multicast, per le
  ritrasmissioni e i messaggi di hello
• aggiungere meccanismo di publish/subscribe per la
  richiesta e notifica di servizi

22
Conclusioni

• protocolli e soluzioni per group communication
  system view-oriented con coordinamento fra pari
• supporto per gruppo dinamico
• fault tolerant e crash detection dei partecipanti
• qualità nel servizio di consegna dei messaggi
• ordinamento FIFO e causale dei messaggi
• servizi conoscibili tramite discovery e
  accessibili come oggetti oggetti remoti.
• timeout T del crash detector punto cruciale per
  la stabilità compromessa in caso se T troppo
  piccolo rispetto ai tempi medi di comunicazione
  dellinfrastruttura di rete