Sistema di replicazione master-multislave con server di backup per un servizio di chat di Marco Andolfo matr

Uno sguardo al servizio di chat Servizio ad ampia diffusione Uno degli strumenti principali per comunicare in rete Svariati forme di utilizzo –Dialogo tra amici –Coordinamento di un gruppo di lavoro –Strumento offerto da portali multimediali –…

Descrizione generale Modello considerato: client-server Gli utenti devono registrarsi per usufruire del servizio La registrazione è effettuata da un server di chat che eroga anche il servizio Gli utenti sono suddivisi in gruppi a seconda del tipo di argomento su cui verte la conversazione Gli utenti si scambiano messaggi in tempo reale (è il server che si incarica di far reperire i messaggi ai destinatari) Il server gestisce la lista degli utenti connessi Ruolo centrale del server

Protocollo comunicazione Registrazione 1)Invio i miei dati al server …… …… ……. … …… …… ……. … 3) Per connettersi si utilizzerà lo username fornito al server al passo 1 Autenticazione 1) Invio username 2) Verifica username 3) Il server notifica i partecipanti che aggiornano la loro lista utenti 4) Il server invia la lista utenti 2) Registrazione utente

Protocollo di comunicazione user1 user2user3 Scambio di messaggi “ciao” user1->“ciao” Gestione utenti Logout Il server notifica I partecipanti Aggiorna lista utenti ! !

Realizzazione un prototipo e scelte architetturali Ruolo centrale del server: utilizzo di un sistema di replicazione master-multislave per –Far fronte a crash improvvisi del server –Garantire la disponibilità del servizio agli utenti Introduzione di un server di backup per –Garantire la persistenza delle informazioni del master –Permettere sia al master che agli slave di ottenere informazioni Scambio di messaggi e di file di testo in tempo reale –Copie di backup di messaggi e file in caso di errori di comunicazione Tecnologie utilizzate per lo sviluppo –Java per lo sviluppo dell’applicazione client e server –Java RMI come middleware di supporto alla comunicazione

L’applicazione client Dotata di GUI per l’invio di messaggi,file e visualizzazione lista utenti e messaggi ricevuti Modalità di ricezione –Messaggi: si interroga il master per vedere se ci sono nuovi messaggi (modalità a polling) –File: il master notifica ai client la ricezione di un nuovo file (uso di callback) Criteri di scelta della prima modalità –L’evento di ricezione di un messaggio ha una frequenza maggiore di quello di un file –Si evita di sovraccaricare il master in presenza di alto traffico Gli aggiornamenti della lista utenti sono notificati dal master

Architettura server Server di Backup (BS) Master Slaves Gestisce gli slave Gestisce gli utenti Verifica l’autenticazione degli utenti Invia i messaggi ed i file Interagisce con il server di backup Backup dei messaggi e dei file Mantiene una copia della lista utenti Mantiene informazioni sul master e sugli slaves interagisce sia con il master che gli slaves Sono equiprioritari Sono gestiti dal master Interagiscono con il server di backup

Scenari 1a) Il client si connette e master aggiorna la lista utenti 1b) Il master si connette a BS che aggiorna la lista utenti di backup 2a) Il client si disconnette e master aggiorna la lista utenti 2b) Il master si connette al BS che aggiorna la lista utenti di backup 1)Invio file/messaggio 2)Master contatta BS per salvare il file/messaggio 3)File/messaggio inviato ai destinatari copi a

Sistema di replicazione 1) Un nuovo slave contatta il BS per avere l’indirizzo master a cui connettersi 2)Il master registra lo slave nella sua lista 3)Il master invia la lista delle porte degli slave aggiornate al BS 4) Il nuovo slave contatta periodicamente il master per controllare che non sia andato in crash Slaves. … Slaves. … Slaves.Ports … Slaves.Ports … “OK”

Protocollo di elezione 1)Il master non risponde più agli slave 2)Gli slave chiedono al BS chi è il nuovo master 3)BS fornisce la porta del nuovo master 4)Gli slave confrontano la propria porta con quella fornita 5)Il nuovo master scarica la lista utenti dal BS ed aggiorna i riferimenti ai client 6)Il nuovo master registra gli slave 7)Il nuovo master invia a BS il suo indirizzo e chiede se deve essere reinviato un mess/file New Master ? New Master Port Check BS calcola la porta del nuovo master Porta del nuovo master calcolata in modo random tra quelle degli slave Ricalcolata ad ogni aggiornamento della lista slave Si suppongono slave equiprioritari

Test Sessioni di test qualitativi Sessioni di test quantitativi per –Misurare il tempo di ritardo necessario ad inviare messaggi e file degli utenti –Studiare il carico computazionale del server master all’aumentare del numero progressivo di utenti da gestire per ogni prova Oltre alla versione finale test anche sulla prima versione monoserver Introduzione di classi per supportare la raccolta dei dati (mediante file di log)

Test: risultati L’aumento del tempo di risposta al servizio è stato influenzato dal numero di utenti collegati Stesse considerazioni valgono per il carico computazionale del server Confrontando le due versioni – Il carico computazionale della versione finale è superiore rispetto alla prima –Ciò è dovuto all’introduzione del sistema di replicazione e di backup

Possibili sviluppi futuri Introdurre la replicazione anche per il server di backup Scambio per qualsiasi tipo di file Utilizzo di altri middleware per operare in ambienti eterogenei (vedi Corba) Utilizzare le informazioni del backup server per comunicare in altri ambienti (es. su mobile system)

Bibliografia Sito ufficiale di Java: sun.java.com Slide del corso di Reti di Calcolatori LA: “ Java RMI (Remote Method Invocation)”, “Java RMI: callback”, “Java RMI esercitazione 6” Slide del corso di Reti di Calcolatori LS: “Chiamate di Procedura Remota: il caso Java RMI ” Slide del Corso di Reti di Calcolatori LS: “Modelli di replicazione e di supporto alla tolleranza ai guasti Funzionamento di una chat: