Progetto
Message Queues Service
Olivelli Enrico
Corso di Reti di Calcolatori LS
A.A. 2003-2004
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
Idea base
?
N3
N1
L’utente Bob vuole inviare
un messaggio a Fred
N2
Bob affida il msg al
servizio QMS presso N1
Il gruppo QMS si coordina
ed il messaggio viene
replicato su N2 ed N3
Fred comunque
recupera il
messaggio da
QMS attraverso N3
Anche nel caso che il nodo
N1 si guastasse
Dietro le quinte…
 Il client di Bob richiede una modifica ad una
coda (aggiungere un messaggio)
 Il nodo N1 richiede l’accesso esclusivo alla
coda per modificarla
 Il nodo N1 modifica la coda
 Il nodo N1 rilascia la coda
Two Phase
Lock Protocol
Ordinamento
atomico
Coordinamento (1)
 Per ogni coda
– Uno stack di messaggi di coordinamento
– Un insieme di possibili possessori della coda
 Nodi ordinati (a priori o dinamicamente)
Ow = N1
Locked!
Ow = N1
Ow = N1
N1
N2
N3
N1 Req Lock
N1 Req Lock
N1 Req Lock
N2
N1
N1
Agree
Change
Unlock
Lock
N1
N1 Change
Unlock
N1 Change
Unlock
N1
N3 Agree Lock
N1 Agree Lock
La coda viene modificata solo quando tutti i nodi
sono d’accordo sul fatto che N1 (e solo N1!) la
modificherà
Coordinamento (2)
 Richieste concorrenti di modificare una coda
N1
OW=N1
OW=N3,N1
Locked!
N2
OW=N1
OW=N3,N1
N3
OW=N3
Locked!
OW=N1
N1 Req Lock
N1 Req Lock
N3 Req Lock
N1N1
Agr
Unlock
Lck N1
N3
N1Req
Unlock
Lock
N1
N1Req
Unlock
Lock
N2 Agr Lck N1
N3 Unlock
N2N3
Agr
Unlock
Lck N3
N3
N3Agr
ReqLck
Lock
N1 Adesso N3 può modificare la coda
N3 Unlock
Adesso N1 può modificare la coda
N3 Agr Lck N3
N1 Agr Lck N3
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 l’aggiunta di
un nodo
– Continuità di servizio anche a fronte di guasto di
un nodo (purché resti almeno un nodo attivo nel
gruppo)
Gestione del gruppo (2)
 Aggiunta di un nuovo nodo al gruppo
Richiesta di join a N1
Freeze !
Copia stato code
Copia info su Gruppo
Info sul nuovo nodo
Ready
Ora il nuovo nodo fa
parte del gruppo
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
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)
Client API
 Interfaccia standard
– Protocollo http/https
– XML
 ADT Messaggio
– Mittente / Destinatario / Corpo
– Stringhe con significato a carico dell’applicazione
client
 API semplice
– Creazione/Distruzione di code
– Inserimento/Lettura/Estrazione di messaggi
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 l’asincronicità 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
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
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 nell’accesso
per modificare le code
 Sistema poco scalabile
– Numero di messaggi scambiati
– Tutte le entità da sincronizzare per ogni
operazione significativa
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 all’invio dei messaggi
– Etichettamento sul client e poi ricostruzione della
sequenza
 Ordinamento CAUSALE dei messaggi
– Non mostrare messaggi “effetto” senza “causa”