A High-Available Instant Messaging Service

A High-Available Instant Messaging Service
Bombardi Fabio 165168
University of Bologna
Reti di Calcolatori LS – Prof. Antonio Corradi
A.A. 2004/2005
[email protected]
TU
UT
Abstract L’Instant Messaging ben si presta come caso di studio per una applicazione distribuita. Si vuole
realizzare una applicazione di Instant Messaging come MSN Messenger dove più applicazioni Client
possono scambiarsi messaggi in tempo reale durante la loro connessione ad Internet. Il modello prevede che i
Client si registrino presso un server che memorizza i dati relativi agli utenti e il loro stato attuale (e.g. Online,
Offline, etc.). Il server si preoccupa anche di gestire la lista dei contatti dei Client e di notificare un Client per
eventuali cambiamenti di stato di un suo contatto. In aggiunta al semplice servizio di Instant Messaging si
vuole 1) fornire un servizio ad alta disponibilità: si prevede quindi un sistema di replicazione per il server, hot
spot del sistema, e 2) la possibilità di recapito posticipato dei messaggi nel caso in cui un contatto non sia
online nel momento dell’inoltro. Per lo sviluppo si è utilizzato CORBA come middleware di supporto alla
programmazione distribuita, utilizzando però solamente quei servizi essenziali quali Naming e Notification
Service e demandando le strategie di coordinamento, replicazione e persistenza al progetto del Sistema.
L’Instant Messaging è un buon trampolino di lancio
per la realizzazione di una applicazione distribuita in
quanto permette l’analisi e lo sviluppo di un sistema
in cui occorra realizzare strategie di coordinamento,
replicazione, persistenza affichè venga fornito un
servizio con un alto grado di disponibilità.
Questo articolo si suddivide quindi nei seguenti
capitoli dove verranno presentate e discusse le scelte
riguardanti 1) l’Architettura del sistema 2)
i
protocolli utilizzati (coordinamento, replicazione,
persistenza, etc.) 3) l’implementazione del Sistema 4)
gli sviluppi a cui il sistema potrà essere sottoposto
nell’immediato futuro 5) i riferimenti cui ci si è
ispirati per la realizzazione del sistema.
1.
Architettura del sistema
L’architettura che si è utilizzata per la realizzazione
del nostro servizio di Instant Messaging si rifà al
modello Client/Server anche se lo contorna con
soluzioni avanzate che ne rendono l’architettura
meno centralizzate, là ove si è ritenuto necessario
non sovraccaricare il Server. La scelta del Modello
Client/Server (Figura 1) deriva dalla necessità di
fornire in modo “semplice” una garanzia di consistenza dello
Stato del Sistema. Ovvero, la realizzazione del sistema
di Instant Messaging si sarebbe potuta realizzare in
svariate modalità (MOM, P2P) nelle quali però il
carico
progettuale
sarebbe
cresciuto
esponenzialmente poiché la garanzia di consistenza
dello stato del sistema in tali modelli è proporzionale
alla decentralizzazione degli stessi.
Si è comunque cercato di realizzare un buon schema
architetturale, facendo un’analisi del traffico del
sistema, e cercando di rendere il più possibile
flessibile (decentralizzato) quel traffico a cui il
Sistema è maggiormente sottoposto quando
raggiunge uno stato di regime di funzionamento,
come verrà di seguito spiegato.
1.1 Server
Il Server si preoccupa di registrare le informazioni
relative agli utenti (universal number, nick, etc.) e il
loro stato attuale (online, offline, etc.). Esso si
preoccupa anche di gestiere la lista dei contatti di un
Client e di notificare i Client qualora uno qualunque
di essi cambi stato (online offline e viceversa ).
Esso inoltre si prende cura, nel caso in cui un Client
invii un messaggio ad un altro Client che però risulti
offline, di inoltrare in maniera differita i messaggi al
Client correntemente offline, una volta che questi sia
di nuovo online.
Come risulta sempre in architetture Client/Server, il
Server è l’hot spot del sistema, quindi occorre
studiare una politica di replicazione per far fronte alla
disponibilità del sistema ed evitare DoS (Denial of
Service) ed una politica di persistenza dei messaggi in
memoria di massa per evitare una perdita definitiva
delle informazioni (leggi “stato”) del Server, nel caso
in cui si verifichi un Crash di quest’ultimo.
1.2 Client
Il Client è l’utilizzatore del Servizio di Instant
Messaging. Una volta registratosi persso il servizio
esso è in grado di comunicare in tempo reale con
altri Client correntemente connessi al servizio.
2.
Protocolli
I protocolli del sistema riguardano svariati aspetti e
problematiche dei moderni sistemi distribuiti, come
ad esempio il coordinamento dei Client verso il Server e
dei Client verso gli altri Client. La replicazione del
Server per le motivazioni espresse
colui con cui si vuole parlare (Figura 2.2). Questo
accade una sola volta, in quanto il Client che presenta
richiesta al server per un indirizzo di Client remoto,
memorizza quest’ultima informazione in locale, in
modo tale da non dover ripresentare richiesta al
Server, sgravandolo così di carico inutile.
Figura 1
nella sezione precedente, e la persistenza dei messaggi
non ancora recapitati ad alcun Client, dovuto al fatto
che sono stati inviati a chi non era connesso al
servizio al momento dell’invio.
2.1 Registrazione al Sistema
Un clinet prima di utilizzare il sistema di instant
messaging, deve registrarsi presso il servizio (Server)
e fornire un Nick, che il Server assegnerà unicamente a
quel Client, e sarà il tramite con il quale gli altri Client
potranno fare il dispatch di colui con cui desiderano
instaurare una comunicazione. Vedi Figura 2.1
2.2 Comunicazione fra Client (Online)
Quando un Client presenta al Server la richiesta di un
utente remoto con cui parlare, il Server lo fornisce
solamente se possiede un utente registrato al Servizio
con quel Nick, altrimenti solleva una eccezione, e il
Client non è in grado di aggiungere quel contatto alla
propria lista locale.
Figura 2.1
Una volta che un utente si sia registrato presso il
sistema è in grado di usufruire del servizio.
Per comunicare con altri Client attualmente connessi
al servizio, egli deve fare il dispatch del Client voluto
al server il quale fornirà al richiedente l’indirizzo di
Nel cason in cui, invece, esista presso il Server un
Client registrato con il Nick richiesto, il Server
fornisce al richiedente l’indirizzo dell’utente remoto
con cui si vuole parlare.
A questo punto, il Client che ha presentato richiesta
al Server può registrare le info nella sua lista dei
contatti locale e, se vuole, può instaurare una
comunicazione peer-to-peer con il Client di cui a
richiesto il dispatch. Vedi Figura 2.3
Si è optato per una comunicazione peer-to-peer dei pari
per non sovraccaricare ulteriormente il server,
aumentando in questo modo la decentralizzazione del
sistema, rendendo più lasco l’accoppiamento tra il
Server e i Client in fase di Comunicazione che, in un
Servizio di Instant Messaging a regime, ovvero una
volta che il sistema abbia un certo numero di utenti
Figura 2.2
registrati con una propria lista di contatti locale,
risulta essere il traffico maggiore.
Per ottenere una persistenza dei messaggi nel caso in
cui si abbia Crash del sistema, si attua una
replicazione del server, che serve anche come
garanzia di disponibilità del servizio, in quanto evita
che possa avvenire un Denial of Service.
Figura 2.3
2.3 Comunicazione fra Client (Offline)
Se un Client invia un messaggio ad un altro Client
che è offline, in questo caso il messaggio inviato
viene bypassato al Server (Figura 2.4) che lo
memorizza per consegnarlo la prossima volta che il
Client destinatario si riconnette al Servizio. Figura
2.5
Figura 2.4
Figura 2.5
2.4 Protocollo Online/Offline
Affichè si tenga traccia dei Client correntemente
collegati al Sistema, si è pensato ad un semplice
protocollo: quando un Client entra nel Sistema, dopo
essersi registrato ovviamente, per rendere
consapevoli i Client che hanno manifastato interesser
verso di lui (inserendolo nella loro lista dei contatti
locale), esso deve effettuare il ben noto login presso
il Server. Nel momento in cui un Client effettua il
login nel Sistema, il server si prende carico di
comunicare la cosa ai Client attualmente connessi alla
rete.
Per rendere più lasca la centralizzazione del Sistema,
la comunicazione di un’avvenuta connessione al
Sistema da parte di un Client, avviene attraverso lo
scambio di messaggi. Figura 2.6
Il Server invia un messaggio contenente il nome
(Nick) del Client che ha effettuato la connessione, e il
suo indirizzo in un canale che offre un servizio di
broadcast, e il messaggio viene recapitato a tutti i
Client correntementi connessi al Servizio, cosicchè
coloro che hanno quel particolare Client registrato
nella loro lista dei contatti locali possano
aggiornanrne lo stato corrente.
L’aggiornamento dello stato è essenziale, in quanto è
importante che un Client sappia che un certo suo
Contatto sia o no offline, poiché da questo dipende il
fatto che i messaggi inviati al particolare Contatto
siano o meno bypassati al Server.
2.5 Replicazione del Server
Figura 2.6
Come già detto in precedenza, si vuole fornire un
servizio ad alta disponibilità. Per far questo, ci sono
svariate metodologie. Per esempio, si potrebbe far
uso di Clusterizzazione del Server, in cui i Client sono
a conoscenza di tutte le copie dei Server presenti
online e possono collegarsi ad uno di essi in maniera
non deterministica, i quali quindi si suddividono la
gestione dei Client registrati al Servizio e i messaggi
inviati a Client che sono correntemente offline.
Occorre inoltre un protocollo che ci permetta di
garantire un controllo sullo stato attuale del sistema,
in modo da avere in ogni istante un Sistema Coerente
(e.g. HeartBeat).
La soluzione a Cluster si rifà alla modalità di
replicazioen a Copie Calde, in quanto tra i Server,
non vi è una Copia Master sono tutti pari.
Ovviamente questo comporta un estremo overhead
di sincronizzazione tra le varie copie dei Server.
Questo tipo di replicazione è sembrata troppo
eccessiva per il Servizio che si vuole fornire, il quale
non necessità di un grado di disponibilità così elevato
quale può essere quello reggiunto da un cluster
distribuito.
Nel nostro caso basta una semplice duplicazione del
Server.
Attuiamo quindi un approccio a Copie Fredde, in cui
abbiamo una copia Master e un’unica copia Slave,
che si aggiorna in maniera Time Driven.
In questo modo, in caso di Crash del sistema,
avremmo un Denial of Service minino per un tempo
pari ad un MTTR della stessa durata del quanto di
tempo impiegato dalla copia Slave del Server per
Aggiornarsi.
3. Implementazione
Per l’implementazione del Servizio di Instant
Messaging, si è utilizzato CORBA come Middleware
di Supporto.
CORBA ci fornisce una infrastruttura di appoggio
alla programmazione di Servizi Distribuiti.
Quello di cui ci si è serviti sono stati due
CORBAServices di base quali il Naming Service e il
Notification Service.
Il Naming Service è stato utilizzato in quanto occorre
che ogni Client, ovunque si trovi, sia in grado di
collegarsi al Server per l’erogazione del Servizio.
Il Notification Service, d’altra parte, lo si è utilizzato in
quanto mette a disposizione un servizio di gestione
degli eventi tipo Publish/Subscribe tramite lo
scambio di messaggi.
Per fare questo ci mette a disposizione un canale che
fornisce un servizio di invio dei messaggi in
broadcast.
Si è utilizzato tale servizio per implementare la
notifica di entrata (online) e uscita (offline) dalla rete
dei Client.
Figura 2.7
Il protocollo risulta quindi molto semplice: in caso di
Crash della copia Master del Sistema, nel momento
in cui la copia Slave interroga il Master per effettuare
l’aggiornamento dello stato esso non ottiene risposta.
Nel nostro caso, l’aggiornamento avviene attraverso
l’invocazione di un metodo del Master da Parte della
copia Slave: in caso di Crash il Master non viene
trovato e viene generata una Eccezione.
Nel momento in cui la copia Slave riceve l’eccezione,
capisce che qualcosa è andato storto e si elegge copia
Master. Figura 2.7
Tale protocollo risulta molto semplice ma altrettanto
efficiente in quanto c’è un bassissimo overhead di
coordinamento delle copie Server.
Nel momento in cui ci si accorge del Crash del
sistema non basta far altro che attivare un’altra copia
Slave e il gioco è fatto.
In teoria, tramite tale servizio, avremmo potuto
realizzare il nostro Sistema gestendolo solo a
Scambio di Messaggi ma, come già detto, si è
preferito avere una semplice garanzia di successo per
alcune operazioni fondamentali richieste al Server dai
Client.
L’applicazione che ne deriva, risulta essere un po’
ibrida, ma le tematiche trattate non perdono di
generalità. Infatti ogni problema può essere risolto
sia col modello message passing che con quello ad
invocazione remota.
Presentiamo qui ora, a semplice titolo informativo,
la specifica IDL che si è utilizzata per
l’implementazione del nostro Sistema in CORBA.
Instant Messaging Service CORBA IDL Specification:
1.
2.
3.
4.
5.
module fabio {
module bombardi {
module instantMessaging {
enum IMClientStatus {ONLINE, OFFLINE,
AWAY};
6.
7. typedef string IMClientName;
8. typedef string IMClientID;
9.
10. typedef sequence<IMClientName>
IMClientNameSeq;
11.
12. struct IMClientInfo {
13.
IMClientName
name;
14.
IMClientID
id; // IOR
15.
IMClientStatus status;
16. };
17.
18. typedef sequence<IMClientInfo>
IMClientInfoSeq;
19.
20. struct IMServerClientRegistry{
21.
IMClientNameSeq names;
22.
IMClientInfoSeq info;
23. };
24.
25. struct IMServerOfflineMsgRegistry{
26.
IMClientNameSeq names;
27.
sequence<string> msgs;
28. };
29.
30. interface IMClientProxy{
31.
void sendMsg(in string msg, in
string name);
32. };
33.
34. exception AlreadyRegistered {};
35. exception UnknownClient
{};
36.
37. interface IMServerProxy {
38.
void registerContact(in
IMClientInfo info)
39.
raises (AlreadyRegistered);
40.
41.
void deregisterContact(in
IMClientName name)
42.
raises (UnknownClient);
43.
44.
void login(in IMClientInfo info)
45.
raises (UnknownClient);
46.
47.
void logout(in IMClientName
name)
48.
raises (UnknownClient);
49.
50.
void addContact(in IMClientName
name, out IMClientInfo info)
51.
52.
raises (UnknownClient);
void sendOfflineMessage(in
string name, in string msg)
53.
raises (UnknownClient);
54.
55.
void update();
56.
57.
void getInfo(out
IMServerClientRegistry cRegistry, out
IMServerOfflineMsgRegistry
msgRegistry);
58. };
59. };
60. };
61. };
I sorgenti sono stati inseriti nel package
fabio.bombardi.instantMessaging.
Il Client ha bisogno di fornire come metodo remoto
quello utilizzato dagli altri Client per instaurare la
comunicazione peer-to-peer sendMsg().
Poiché come linguaggio applicativo si utilizza JAVA,
non ci si è preoccupati della sincronizzazione. Si è
infatti optato per la soluzione più semplice, ovvero
definire i vari metodi remoti che possono essere
chiamato contemporaneamente da più entità del
sistema come synchronized.
La specifica IDL del Server invece è molto più
complessa,
in
quanto
i
protocolli
visti
precedentemente, necessitano di metodi differenti. Il
Server fornisce quindi i seguenti metodi che devono
poter essere chiamati in remoto.
Abbiamo i metodi necessari ai protocolli si
sincronizzazione Client/Server e Client/Client:
•
•
•
•
•
•
registerContact() utilizzato dai
Client per registrarsi presso il Servizio di
Instant Messaging.
deregisterContacr() il duale del
metodo precedente.
login() utilizzato dai Client per
connettersi alla rete di InstantMessaging.
logout() utilizzato dai Client per
disconnettersi
dalla
rete
di
InstantMessaging.
addContact() utilizzato dai Client per
aggiungere un contatto nella loro lista
locale.
sendOfflineMessage()
utilizzato
dai Client nel caso in cui tentino di inviare
un messaggio ad un utente offline. In
questo caso abbiamo detto che vi è un
bypass dei messaggi al Server, che si
preoccuperà di recapitarli la prossima volta
che il Client destinatario si connetterà al
Servizio.
Ci sono poi i metodi necessari al protocollo di
replicazione del Server:
•
•
update() utilizzato dal gestore del Time
Slot di aggiornamento della copia Slave del
Server.
getInfo() utilizzato dalla copia Slave
del Server nel momento in cui necessita di
rendere consistente il proprio stato con
quello della copia Master.
I Client inoltre non dispongono della possibilità di
rifiutare i messaggi e via dicendo.
Ancora, la lista dei contatti locale non è resa
persistente, ovvero quando un client si disattiva e poi
successivamente si riattiva, la sua lista dei contatti
viene resettata. Per far fronte a qusto problema, una
prima soluzione potrebbe essere quella di far gerstire
la lista dei contatti di ogni Client al Server.
Ovviamente, ancora, andiamo ad aggiungere
dell’overhead alla comunicazione (anche se quella
non a regime).
Le altre parti della specifica IDL sono relative alla
definizione delgli opportuni Abstract Data Type
necessari allo sviluppo dell’applicazione.
5.
Grande importanza deve avere anche l’analisi delle
Eccezioni.
Ogni metodo remoto infatti deve sollevare
opportune eccezioni in modo tale che chi invoca tali
metodi possa aggangiarsi a tali eccezioni (viste come
hook) in modo tale da riconoscere e gestire le
situazioni anomale che si verificano.
Non tutti i riferimenti bibliografici ovviamente trovano
una piena applicazione nel progetto del sistema
sviluppato. Essi sono stati letti a sostegno di un
background di conoscenza che ci potesse rendere abili
ad analizzare quali scelte fossero migliori per il caso in
esame.
Si veda per esempio lo studio di riferimenti riguardati il
clustering di entità per fornire alta disponibilità, così
come i protocolli necessari alla loro coordinazione (e.g.
heartbeat).
4.
Riferimenti bibliografici
Sviluppi Futuri
Si potrebbe in primo luogo pensare di
reimplementare il servizio secondo un modello
puramente message passing. In questo modo si
andrebbe ad aumentare la decentralizzazione del
sistema, ma occorrerebbe un ulteriore sforzo per
progettare
gli
opportuni
protocolli
di
sincronizzazione (e.g. heartbeat, notifica di avvenuta
ricezione del messaggio, etc.).
Il sistema così come è stato progettato fornisce un
Servizio di Instant Messaging di Base, in cui vengono
aggiunte funzionalità quali l’alta disponibilità e la
persistenza dei messaggi inviati ai Client di cui
conosciamo l’esistenza perché sono registrati nella
nostra lista dei contatti locale, ma il cui stato è
“offline”.
Moltri altri servizi possono essere aggiunti a questo
scheletro di base, come la possibilità di inviare
messaggi criptati, oppure l’autenticazione dei Client nel
momento in cui effettuano il login alla rete.
Un altro servizio utile da aggiungere potrebbe essere
quello dello scambio di file.
Inoltre molteplici miglioramenti possono essere
apportati nell’architettura, anche se ciò, pur
migliorando la decentralizzazione del Sistema,
possono lederne la Semplicità portando un overhead
magari eccessivo per quello che si vuole
effettivamente fornire (e.g. replicazione tramite
Clustering, etc.)
Non è inoltre prevista QoS, e quindi nessuna garanzia
di rispetto dei tempi di risposta sia Client/Server che
Client/Client.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
A.Corradi. “Dispense di reti di calcolatori LS
A.A. 2004/2005”.
http://www.lia.deis.unibo.it/Courses/RetiLS/
Gerald Brose, Andreas Vogel, Keith Duddy.
“JAVA Programming with CORBA” 3rd Edition.
OMG PRESS, Wiley Distribution.
Stefano Russo, Carlo Savy, Domenico Catroneo,
Antonio Sergio. “Introduzione a CORBA”.
McGraw-Hill.
Quiang Cao, Chang Sheng, Xie. “A Selfadaptation, High-Availability Cluster File System
For Network Application”.
Info-tech and Info-net, 2001. Proceedings. ICII
2001 - Beijing. 2001 International Conferences
on , Volume: 5 , 29 Oct.-1 Nov. 2001
Pages:323 - 327 vol.5
Nicholas A. Solter, Ashutosh Tripathi.
“Architecture and protocol for reliable event
delivery to clients of a high-availability cluster”.
Parallel and Distributed Processing Symposium,
2004. Proceedings. 18th International , 26-30
April 2004.
Pages:28
Alan Robertson. “Linux-HA Heartbeat System
Design”.
Linux-HA
Intra-Cluster
Communications. Proceedings. ALS conference
on 14 October, 2000.
Jin Jing, Abdelsalam (Sumi) Helal, Ahmed
Elmagarmid. “Client-Server Computing in
Mobile Environments”. ACM Comp. Surveys,
v.31, n.2, Mar.1999.
RFC 2778. “A Model for Presence and Instant
Messaging”.
http://www.faqs.org/rfcs/rfc2779.html
[9]
[10]
RFC 2779. “Instant Messaging/Presence
Protocols Requirements”.
http://www.faqs.org/rfcs/rfc2778.html
Mourad Debbabi, Mahfuzur Rahman. “The War
of Presence and Instant Messaging: Right
Protocols
and
APIs”.
Consumer
Communications and Networking Conference,
2004. CCNC 2004. First IEEE , 5-8 Jan. 2004
Pages:341 – 346.