Progetto Message Queues Service

1
ProgettoMessage Queues Service

• Olivelli Enrico
• Corso di Reti di Calcolatori LS
• A.A. 2003-2004

2
Obiettivi del progetto

• Un servizio di gestione di code
• Affidabilità
• Tolleranza ai guasti
• Flessibilità
• Indipendenza dal linguaggio di programmazione e
  dal sistema operativo client

• Case study interessante per
• Replicazione attiva
• Assenza di Gestione Centralizzata
• Oggetti attivi
• Ordinamento Atomico
• Protocollo Ricart Agrawala

3
Idea base
N3
N1
N2
Lutente Bob vuole inviare un messaggio a Fred
Fred comunque recupera il messaggio da QMS
attraverso N3
Bob affida il msg al servizio QMS presso N1
Il gruppo QMS si coordina ed il messaggio viene
replicato su N2 ed N3
Anche nel caso che il nodo N1 si guastasse
4
Dietro le quinte

• Il client di Bob richiede una modifica ad una
  coda (aggiungere un messaggio)
• Il nodo N1 richiede laccesso esclusivo alla coda
  per modificarla
• Il nodo N1 modifica la coda
• Il nodo N1 rilascia la coda

Two Phase Lock Protocol
Ordinamento atomico
5
Coordinamento (1)

• Per ogni coda
• Uno stack di messaggi di coordinamento
• Un insieme di possibili possessori della coda
• Nodi ordinati (a priori o dinamicamente)

N1
N2
N3
Ow N1
Ow N1
Ow N1
Locked!
N1 Req Lock
N1 Req Lock
N1 Req Lock
N1 Unlock
N2 Agree Lock
N1 Unlock
N1 Unlock
N1 Change
N1 Change
N1 Change
N3 Agree Lock
La coda viene modificata solo quando tutti i nodi
sono daccordo sul fatto che N1 (e solo N1!) la
modificherà
N1 Agree Lock
6
Coordinamento (2)

• Richieste concorrenti di modificare una coda

OWN1
N1
N2
N3
OWN1
OWN3
OWN3,N1
OWN3,N1
Locked!
Locked!
OWN1
N1 Req Lock
N1 Req Lock
N3 Req Lock
N1 Req Lock
N3 Req Lock
N1 Agr Lck N1
N1 Unlock
N1 Unlock
N1 Unlock
N2 Agr Lck N3
N2 Agr Lck N1
N3 Unlock
N3 Unlock
N3 Req Lock
N3 Agr Lck N3
Adesso N3 può modificare la coda
N3 Agr Lck N1
Adesso N1 può modificare la coda
N1 Agr Lck N3
N3 Unlock
7
Gestione del gruppo (1)

• Il gruppo deve coordinarsi non solo per gestire
  le code
• Aggiunta di un nuovo nodo
• Partenza di un nodo
• Dichiarazione del fallimento di un nodo
• Recovery di uno stato consistente

• QMS garantisce
• Continuità di servizio anche durante laggiunta
  di un nodo
• Continuità di servizio anche a fronte di guasto
  di un nodo (purché resti almeno un nodo attivo
  nel gruppo)

8
Gestione del gruppo (2)

• Aggiunta di un nuovo nodo al gruppo

Freeze !
Info sul nuovo nodo
Ora il nuovo nodo fa parte del gruppo
Ready
Il gruppo viene congelato, tutti i messaggi di
coordinamento sulle code e tutte le richieste dei
client vengono poste in un buffer
Quando il gruppo viene dichiarato di nuovo
pronto i messaggi bufferizzati vengono
processati come se fossero stati ricevuti in
ritardo
9
Gestione del gruppo (3)

• Partenza di un nodo dal gruppo
• Il nodo informa il gruppo della propria partenza
• Gli altri nodi si dimenticano del nodo
• Eliminare i messaggi di lock/agree pendenti
• Avviare le operazioni sospese in attesa dell
  agree del nodo che parte
• Dichiarazione del fallimento di un nodo
• Un nodo ha un sospetto di fallimento di un altro
  nodo
• Vengono informati tutti i nodi del fallimento
• Il nodo allontanato se ancora attivo deve
  iniziare nuovamente il protocollo di join
  (vedendosi allontanato dal gruppo)

10
Client API

• Interfaccia standard
• Protocollo http/https
• XML
• ADT Messaggio
• Mittente / Destinatario / Corpo
• Stringhe con significato a carico
  dellapplicazione client
• API semplice
• Creazione/Distruzione di code
• Inserimento/Lettura/Estrazione di messaggi

11
Prototipo

• Applicazione Web Java
• Portabilità
• Semplicità nel deployment
• Librerie standard per XML e HTTP
• Libreria Java QMS Client API
• Semplificazioni
• Protocollo di join al gruppo semplificato
• Persistenza solo in memoria RAM
• Componenti collaterali sviluppati
• Scheduler per gestire lasincronicità delle
  operazioni da portare avanti (il nodo è
  praticamente un oggetto attivo)
• Servlet per interfaccia HTTP N2N e C2N
• Amministrazione Web
• Predisposto per estensioni
• Sistema Publish/Subscribe
• Riordinamento dei messaggi

12
Caratteristiche del servizio

• Affidabilità
• Tolleranza ai guasti
• No gestione centralizzata
• Apertura / Indipendenza dal linguaggio
• Interfaccia basata su protocolli/formati standard
• Servizio general purpose
• Il sistema non pone particolari vincoli sul
  significato dei messaggi trattabili

13
Limiti

• Richiesta di canali di comunicazione affidabili
  fra i nodi
• Messaggi ritardati ma mai persi
• Grafo dei nodi completamente connesso
• Over-head dovuto alla sincronizzazione
  nellaccesso per modificare le code
• Sistema poco scalabile
• Numero di messaggi scambiati
• Tutte le entità da sincronizzare per ogni
  operazione significativa

14
Sviluppi futuri

• Differenziare le politiche di gestione delle code
• Qualità di servizio
• Sicurezza
• Servizio publish/subscribe
• Il client non è costretto a fare polling ma può
  registrarsi come interessato a sapere quando un
  certo tipo di messaggio è stato inserito in una
  coda
• Ordinamento in base allinvio dei messaggi
• Etichettamento sul client e poi ricostruzione
  della sequenza
• Ordinamento CAUSALE dei messaggi
• Non mostrare messaggi effetto senza causa