Progetto Message Queues Service Olivelli Enrico Corso di Reti di Calcolatori LS A.A

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 N1 N2 N3 L’utente Bob vuole inviare un messaggio a Fred 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 Fred comunque recupera il messaggio da QMS attraverso N3 ?

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) N1N2N3 N1 Req Lock N1 Agree Lock N1 Unlock Ow = N1 Locked! N1 Req Lock N2 Agree Lock N3 Agree Lock N1 Unlock N1 Change 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 N1N2N3 N1 Req Lock N3 Req Lock N2 Agr Lck N3 N3 Agr Lck N3 N2 Agr Lck N1 N1 Agr Lck N1 OW=N1 OW=N3,N1 OW=N3 OW=N1 OW=N3,N1 N1 Agr Lck N3 Locked! N3 Unlock Adesso N3 può modificare la coda OW=N1 N3 Agr Lck N1 Locked! Adesso N1 può modificare la coda N1 Unlock

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 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 Ora il nuovo nodo fa parte del gruppo

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”