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