Chat con replicazione e QoS Progetto per il corso di Reti di Calcolatori LS Prof.Antonio Corradi Introduzione La chat rappresenta un servizio ormai diffuso e sfruttato non solo nell’ambito del tempo libero I servizi di messaggistica vengono ormai utilizzati anche all’interno di molti ambienti lavorativi Facilita la diffusione delle informazioni in tempo reale Consente e stimola un dialogo molti a molti Architetture I servizi di chat possono presentare 3 architetture distinte: – – – Multicast Ad anello Client/Server Ognuna di queste ha pro e contro che ne limitano l’utilizzo in certe situazioni Architettura Client Server E’ la più diffusa. PRO Presenta bassi costi di comunicazione e coordinazione tra le entità in gioco CONTRO Poco scalabile, richiede la presenza di un’entità centrale Obiettivi del progetto Introdurre replicazione nel modello nei punti critici Consentire una topologia dinamica a più livelli per garantire una maggiore flessibilità del servizio Rendere trasparente al cliente la struttura e gli eventi non connessi strettamente al servizio Per la realizzazione si è deciso di avvalersi del linguaggio Java e di RMI. Master Server e Slave Servers Ogni client, per richiedere il servizio, effettua la connessione ad un server (detto Master) Il Master mantiene informazioni sui client connessi e i messaggi di chat da questi inviati Ogni Master è affiancato da una o più copie in grado di replicare il servizio (Slave) Il Master si preoccupa di aggiornare costantemente lo stato degli slave, mentre questi lo monitorano continuamente per individuare eventuali crash Observer Pattern che consente di ottenere le funzioni di un Hot Standby Manager Ogni server (master o slave) ne è dotato Si occupa di rendere effettivo l’aggiornamento delle copie nascondendone la molteplicità al server principale Riceve l’ordine di aggiornamento direttamente dal Master e lo inoltra agli Slave Aggiornamento Slave L’Observer propaga l’aggiornamento a tutte le copie Ogni slave deve registrarsi presso il Master Observer L’aggiornamento può riguardare informazioni sui client connessi o sugli slave registrati (a conoscenza solo dell’observer) Elezione nuovo Master Qualora gli slave rivelino un problema del Master Server, lanciano un meccanismo di elezione per stabilire chi debba subentrare al suo posto Lo Slave incaricato si preoccuperà di aggiornare sia gli altri slave che i client presenti Replicazione a copie calde L’operazione di aggiornamento è del tutto trasparente all’utente isAlive() consente allo slave di monitorare le condizioni Master Se lo slave non riceve l’update viene lanciata una nuova elezione Aggiunta QoS Tentativo di rispettare il principio di minima intrusione nel bilanciamento del carico Operazioni dinamiche di bilanciamento solo all’atto della connessione di un client Distinzione tra visitatori e utenti registrati (in determinate condizioni negazione del servizio ai visitatori) Diffusione ritardata dei messaggi per diminuire il traffico di rete Bilanciamento del carico La comunicazione tra client di diversi master è ritardata per efficienza Alla connessione, il cliente viene rediretto verso il Master meno carico Il Master invia alcune informazioni sul suo carico di lavoro APPLICAZIONE DEMO Conclusioni La realizzazione del progetto ha permesso: – – Di esplorare le problematiche tipiche della replicazione in ambiente distribuito Di entrare a contatto con alcuni dei meccanismi di coordinazione ed elezione Dove è stato possibile, per alcuni dei problemi affrontati si è cercato di sperimentare più meccanismi Si è ottenuto un servizio con una struttura gerarchica in grado di garantire un servizio continuo e con una certa qualità Struttura finale del sistema