Servizio di newsgroup con replicazione dei server Studente: Letizia Cheng Cheng Sun Matricola: Reti di Calcolatori LS – Prof. A. Corradi A.A. 2003/2004

Introduzione Newsgroup: gruppo di discussione che si forma attorno a un tema ben definito e pubblica i messaggi inviati dai partecipanti in bacheche elettroniche, visibili a tutti Newsgroup: gruppo di discussione che si forma attorno a un tema ben definito e pubblica i messaggi inviati dai partecipanti in bacheche elettroniche, visibili a tutti Un servizio di newsgroup deve permettere di Un servizio di newsgroup deve permettere di –Inserire un nuovo messaggio in bacheca –Rispondere ad un messaggio –Leggere messaggi

Obiettivo: Utilizzo semplicità dello schema C/S ma con studio delle problematiche relative a Utilizzo semplicità dello schema C/S ma con studio delle problematiche relative a –Tolleranza ai guasti –Concorrenza e performance del sistema –Accesso trasparente lato client Soluzione: Utilizzo di replicazione attiva dei server Utilizzo di replicazione attiva dei server Accesso al servizio tramite un servizio di naming Accesso al servizio tramite un servizio di naming

Il sistema realizzato Lato client si accede al servizio tramite un servizio di naming Lato client si accede al servizio tramite un servizio di naming Lato server è costituito da un numero dinamico di servitori Lato server è costituito da un numero dinamico di servitori Permette di eseguire le operazioni di Permette di eseguire le operazioni di –Inserimento di un nuovo messaggio in bacheca –Risposta ad un messaggio –Lettura messaggi

Struttura del sistema

Progetto del lato server deve tenere conto Comunicazione con gli altri server attivi per mantenere la consistenza dei dati Comunicazione con gli altri server attivi per mantenere la consistenza dei dati –Conoscenza reciproca Struttura a ring Rilevazione della caduta di un nodo e ricomposizione degli elementi del ring Rilevazione della caduta di un nodo e ricomposizione degli elementi del ring Variazione dinamica del numero di server attivi Variazione dinamica del numero di server attivi Operazioni di bind e unbind

Struttura lato server Registro di 1°livello Registro di 2°livello ServizioBinding ServerN+1 ServRef0 ServRefN Server0 ServerN ServizioID Servizio ID univoci ServerN+1

Progetto: operazioni newsgroup Uso di callback per le operazioni Uso di callback per le operazioni –client Non deve aspettare elaborazione del server Non deve aspettare elaborazione del server Implementa un’interfaccia di operazioni invocabili dal server Implementa un’interfaccia di operazioni invocabili dal server

Inserimento/risposta a un messaggio Bacheca locale 1) writeMsg() 2) Callback 3) transmitMsg() n) transmitMsg() Cliente newsgroupServer i Server i+1 Server i-1

Lettura di messaggi Bacheca locale 1) readMsg() 2) Callback Cliente newsgroupServer i Server i+1 Server i-1

Criteri di ricerca di messaggi di interesse Oggetto dei messaggi Autore e oggetto dei messaggi Autore, oggetto e ora d’invio dei messaggi Messaggi di risposta di un dato messaggio Tutti i messaggi Messaggio particolare identificato tramite un ID

Aggiornamento dello stato dei server Eseguito by – need Eseguito by – need –In seguito all’inserimento di un nuovo messaggio in bacheca Utilizzo di una politica ottimista Utilizzo di una politica ottimista –Aggiornamento dei server attivi dopo aver comunicato la riuscita dell’inserimento al client Uso modalità best effort Uso modalità best effort Controllo dello stato dei server: ci sono stati failure? Controllo dello stato dei server: ci sono stati failure?

Modifica del ring o dello stato dei suoi componenti Per fare una qualunque modifica al ring Per fare una qualunque modifica al ring –Inserimento di messaggio messaggio nuovo nodo nuovo nodo –Eliminazione di un nodo Ho bisogno di una autorizzazione ottenuta tramite il possesso di un token

Algoritmo per ottenere il token 1. Si richiede il token a tutti i componenti del ring 2. Se tutti danno il consenso, il server i ottiene il token (che poi deve essere liberato) 2. Se tutti danno il consenso, il server i ottiene il token (che poi deve essere liberato) 3. Se non tutti danno il consenso (in caso di richiesta simultanea) si aspetta un tempo casuale prima di rinoltrare la richiesta Ok token

Implementazione Utilizzo di Java RMI, perché offre Utilizzo di Java RMI, perché offre –Un servizio di naming già funzionante –La possibilità di gerarchizzare i registri in due livelli –Un meccanismo per poter comunicare in remoto con una certa sicurezza

Struttura delle classi

Demo applicazione

Sviluppi futuri Decentramento del servizio di nomi univoci Decentramento del servizio di nomi univoci Supporto per la persistenza dei dati Supporto per la persistenza dei dati Altre logiche di assegnamento di un server a un cliente Altre logiche di assegnamento di un server a un cliente …

Conclusioni Col sistema realizzato si è cercato di ottenere Col sistema realizzato si è cercato di ottenere –Tolleranza ai guasti –Concorrenza e performance –Accesso trasparente lato client migliori rispetto al classico C/S, senza rinunciare ad un’architettura molto semplice Poteva essere inserita una gestione della qualità di servizio, ma si reputa, dato il servizio, il principio di minima intrusione, che il sistema abbia comunque un buon rapporto costo, prestazione, almeno per questa prima versione Poteva essere inserita una gestione della qualità di servizio, ma si reputa, dato il servizio, il principio di minima intrusione, che il sistema abbia comunque un buon rapporto costo, prestazione, almeno per questa prima versione