Sistema di replicazione
master-multislave con server
di backup per un servizio di
chat
di
Marco Andolfo matr.0000232246
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
Autenticazione
4) Il server invia la lista utenti
1)Invio
i miei
dati al server
1) Invio
username
3) Per connettersi si
utilizzerà lo username
fornito al server al passo 1
3) Il server notifica i
partecipanti
che aggiornano la
loro lista utenti
……
……
…….
2) Registrazione …
…
utente
2) Verifica username
Protocollo di comunicazione
Logout
Il server notifica
I partecipanti
“ciao”
user1
user1->“ciao”
Scambio di messaggi
user1->“ciao”
!
!
Gestione utenti
Aggiorna lista utenti
user2
user3
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
• Gestisce gli slave
• Gestisce gli utenti
• Verifica l’autenticazione
degli utenti
• Invia i messaggi ed i file
• Interagisce con il server
di backup
Slaves
Master
• 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
Server di
Backup (BS)
• Sono equiprioritari
• Sono gestiti dal master
• Interagiscono con il
server di backup
Scenari
1) Invio file/messaggio
2) Master contatta BS per
salvare il file/messaggio
3) File/messaggio inviato
ai destinatari
copi
a
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
Sistema di replicazione
“OK”
Slaves
Slaves
.
.Ports
…
…
…
…
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
Protocollo di elezione
1)
2)
3)
4)
Il master non risponde più agli slave
Gli slave chiedono al BS chi è il nuovo master
BS fornisce la porta del nuovo master
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
Check
New
Master
?
New
Master
Port
• 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:
http://it.wikipedia.org/wiki/Chat
