Reti di Calcolatori L-S
Anno Accademico 2005/2006
Progetto RE.VE.N.GE.
(REliable and VErsatile
News delivery support for
aGEncies)
Nardini Elena 0000232607
Docente: Corradi Antonio
Referente progetto: Ing. Stefano Monti
Requisiti di Progetto
Si vuole sviluppare un sistema di supporto per la distribuzione di notizie su larga scala da
parte di agenzie di stampa (ad esempio ANSA).
Il sistema deve essere in grado di:




mettere in comunicazione fonti e fruitori d’informazione tra loro altamente diversi
ed eterogenei;
supportare diversi livelli di qualità di servizio sia per le fonti che per i fruitori;
rendere possibili diverse tipologie d’interazione, ad esempio di tipo pull e push;
dare la possibilità anche a terminali molto leggeri (PDA, telefoni cellulari, ecc.) di
accedere al servizio di distribuzione.
Il sistema REVENGE deve essere realizzato facendo uso del Message Oriented Middleware
(MOM) IBM Message Queue.
Sistema RE.VE.N.GE.
Il sistema è composto principalmente da tre parti:



Fonti
Fonti: rappresentano i produttori di informazioni che possono interagire con il
Sistema di Distribuzione;
Sistema di Distribuzione: ha il compito di portare le notizie dalle fonti ai fruitori in
base alle caratteristiche delle notizie stesse;
Fruitori: in modo duale rispetto alle fonti, rappresentano le entità che ricevono
dal sistema di Distribuzione le notizie e le informazioni richieste.
Sistema di Distribuzione
Fruitori
IMB Message Queue
IBM Message Queue è un middleware orientato ai messaggi (MOM) largamente diffuso in
ambito aziendale che consente:
 il disaccoppiamento delle applicazioni che ne fanno uso, mediante la capacità di
accodare i messaggi trasmessi in attesa di recapitarli;
 è in grado di eseguire su oltre 35 piattaforme hardware e fornisce il supporto per la
comunicazione punto-punto tra applicazioni java, C, C++ e COBOL.
I principali elementi che concorrono a delineare l’architettura interna di tale middleware sono:
 il messaggio (Message): è costituito da una collezione di dati inviati da un programma;
 la coda di messaggi (Message queue): rappresenta una risorsa dotata di un nome verso
la quale è possibile inviare e prelevare messaggi;
 il gestore delle code (Queue manager): si occupa di creare e di gestire le code;
 il canale (Channel): rappresenta una connessione logica tra un Client MQ e un Server
MQ oppure tra due Server MQ;
 l’agente di canale (Message Channel Agent): rappresenta il software che gestisce
l’invio e la ricezione di messaggi attraverso un canale. Ogni estremità di un canale
richiede un MCA.
Dimensionamento/Ipotesi di progetto
(1/2)







Sono stati raccolti dati statistici e previsioni ISTAT dal 2005 al 2015, per una messa in
opera del servizio nel 2007 e dimensionamento medio nel quinquiennio seguente (fino al 2011
compreso);
La popolazione è stata suddivisa per fasce di età e per ognuna di questa è stata stimata una
percentuale di utilizzo del servizio variabile nel corso degli anni;
Si suppone la presenza di 12 fonti (quante sono le attuali agenzie di stampa in Italia);
Esiste un sistema di contrattazione per la creazione di contratti con i fruitori;
Il sistema di contrattazione, nell’intervallo di tempo considerato, deve gestire circa 200.000
iscrizione annue -> circa 600 nuove connessioni al giorno -> in un lasso di tempo di 8 ore
circa 100 iscrizioni/ora -> con un tempo di contrattazione medio di 6 minuti -> 10 connessioni
contemporanee -> è possibile gestire il servizio di contrattazione attraverso un sistema
centralizzato;
Si suppone che ogni sistema di consegna sia in grado di gestire 20.000 fruitori. Il 5% di
questi (quindi 1.000) è di tipo Pay e si suppone di garantire per questi un numero minimo
di 5 e massimo di 50 messaggi all’ora e un ritardo massimo di 200 secondi;
I 20.000 utenti garantiscono che ogni sistema di consegna sia interessato a praticamente tutti
gli argomenti;
Dimensionamento/Ipotesi di progetto
(2/2)





Si suppone che le 12 fonti emettano messaggi di dimensione variabile, ma mai per ipotesi
superiore ai 2 MB (nel caso siano presenti immagini allegate);
Le tratte che collegano i nodi del sistema di distribuzione saranno collegate con linee che
garantiscono una banda di circa 200 KB/s per garantire anche un buon tempo di
trasmissione nel caso di notizie da 2MB (circa 10 secondi a notizia);
Il sistema di consegna dovendo garantire un minimo di 5 messaggi all’ora per un massimo
di 1.000 utenti Pay, con messaggi di dimensione massima, dovrà avere almeno una linea
di uscita con banda di 3MB/s;
Per il ritardo massimo, consideriamo nel caso peggiore che la notizia attraversi 15 nodi
prima di raggiungere il sistema di consegna, con un ritardo per ogni nodo (dovuto al suo
instradamento) di circa 1 secondo. Con messaggi da 2MB su tratte con banda di 200 KB/s.
ogni messaggio impiega in condizioni di poco traffico (garantito dal monitoring) circa 10 s.
-> il ritardo totale è di circa 165 secondi dall’immissione della notizia nel sistema al
raggiungimento del sistema di consegna più lontano;
Per le esclusive l’instradamento è precompilato al momento dell’accettazione del messaggio.
Architettura globale del sistema




Il sistema realizzato permette la distribuzione di notizie
su scala nazionale, è distribuito geograficamente e
organizzato in modo gerarchico su più livelli.
Le agenzie di stampa (fonti) presenti sul territorio
sono 12 e sono connesse alla rete di livello più alto
(nodo radice ITALIA). È possibile espandere il sistema a
livello mondiale.
I fruitori si connettono ad un proprio sistema di consegna
posizionato nell’ultimo livello gerarchico della rete.
La rete di distribuzione effettua una consegna totale
perché si assume che ogni sistema di consegna
gestisca un parco fruitori abbastanza elevato da
garantire una quasi totale copertura degli argomenti.
Struttura dei messaggi



Le notizie rappresentano l’unità di scambio delle informazioni all’interno del sistema
RE.VE.NG.E. e vengono trasportate tramite messaggi.
I messaggi possono essere di due tipi: notizie o notizie esclusive.
Ogni messaggio contiene:
 La fonte di origine;
 L’argomento della notizia che può essere: sport, cronaca, politica, estero, gossip,
finanza;
 Contenuto della notizia;
 Scadenza;
 Una priorità che dipende dalla fonte che produce la notizia;
 Il ritardo da quando è stato immesso nel sistema di distribuzione;
 Un timestamp aggiunto dal sistema di consegna.
I fruitori
Ogni potenziale fruitore deve stabilire un contratto con il sistema di contrattazione. Un
contratto permette di scegliere:

se essere fruitore pull o push: i primi interrogano attivamente il Sistema di Consegna
per richiedere la consegna di nuove notizie, i secondi vengono invocati in modo
asincrono ogni qual volta nuove notizie sono disponibili;
 gli argomenti di interesse;
 se essere fruitore Pay o Not Pay: nel primo caso viene garantita una certa qualità di
servizio, in particolare: affidabilità riguardo alla consegna, un numero minimo e
massimo di notizie nell’unità di tempo, un tempo massimo di consegna della notizia
dalla sua immissione nel sistema e la possibilità di avere delle esclusive. Nel secondo
caso invece, non viene garantita alcun tipo di qualità di servizio;
 se essere un fruitore mobile: per fruitore mobile si intende un fruitore che può
accedere al sistema di consegna con terminali leggeri, con connettività di tipo wirless e
non sempre connesso alla rete. Per tali utenti si ha un contratto di tipo NotPay e con
un modello di consegna di tipo pull.
Architettura lato fruitore (1/7)
L’architettura lato fruitore si basa sui seguenti ruoli fondamentali:





Registry: permette di pubblicare i servizi offerti o di ritrovare il servitore di un particolare
servizio di cui a priori non si è a conoscenza;
Sistema di Contrattazione: è un sistema centralizzato a cui un potenziale fruitore deve
rivolgersi per stipulare un contratto con il sistema o a cui un fruitore deve rivolgersi per
modificare il proprio contratto già esistente;
Client: può rappresentare un utente che vuole stipulare un contratto con il sistema o un
fruitore che lo vuole modificare;
Sistema di consegna: rappresenta l’entità che riceve i messaggi dal sistema di distribuzione
per consegnarli ai fruitori a lui associati;
DataBase centrale: rappresenta un contenitore di informazioni necessarie al sistema.
Architettura lato fruitore (2/7)
Appena il sistema di contrattazione si attiva, deve registrare il proprio servizio presso
il Registry.
Un client può rintracciare il sistema di contrattazione tramite il Registry.
In caso di fallimento dell’operazione richiesta al Registry, questo risponde con una
indicazione di errore.
La comunicazione con il Registry avviene tramite socket con connessione.
REGISTRY
1:Nome
servizio,IP,PORTA
Sistema Contrattazione:IP,PORT
………………
2:IP,PORT
1:Nome servizio
CLIENT
SISTEMA DI
CONTRATTAZIONE
2:Ok
Architettura lato fruitore (3/7)
Il sistema di contrattazione ha un server parallelo in grado di servire più richieste contemporaneamente.
La comunicazione fra Client e Sistema di Contrattazione avviene tramite socket con connessione.
CASO 1
1:UserName;Password;
Sistema di Consegna
4:contratti disponibili
SISTEMA DI
CONTRATTAZIONE
5:Contratto scelto
CLIENT
7:Ok
(Per contratti
Pull indirizzo
del Sistema di
Consegna)
6:Memorizza
Contratto e
Utente
3:No
2:Utente presente?
DB
CASO 2
1:UserName;Password;
Sistema di Consegna
4:contratti disponibili
CLIENT
5:Nuovo Contratto
scelto
7:Ok
(Per contratti
Pull indirizzo
del Sistema di
Consegna)
SISTEMA DI
CONTRATTAZIONE
6:Modifica
contratto
3:Si
DB
2:Utente presente?
Architettura lato fruitore (4/7)




Persistenza dei messaggi: nel sistema di consegna i messaggi vengono mantenuti fino a
scadenza, perché l’insieme di fruitori è variabile. I fruitori possono essere aggiunti al sistema di
consegna dinamicamente o perché hanno creato un nuovo contratto o perché il proprio è
caduto e questo rappresenta il suo sostituto.
Dato che i messaggi rimangono fino a scadenza, ogni volta che un messaggio arriva al sistema
di consegna, questo gli aggiunge un time stamp. In tal modo si mantiene traccia dell’ultimo
messaggio ricevuto dal fruitore.
Ogni sistema di consegna è munito di un gestore di code con due code associate: una per le
notizie normali, e una per le esclusive. Ad ogni coda è associato un thread che rimane in attesa
dell’arrivo di nuovi messaggi.
Un fruitore può avere un contratto Pay o un contratto NotPay. Nel primo caso per garantire una
maggiore affidabilità della comunicazione, fruitore e sistema di consegna utilizzano le socket
con connessione. Nel secondo caso non vi è nessuna garanzia, quindi vengono utilizzate le
socket senza connessione.
Architettura lato fruitore (5/7)
Caso push:
Lato fruitore è presente un client che periodicamente interroga un server concorrente lato sistema
di consegna.
Per ogni richiesta il Server attiva un thread che si occupa di autenticare il client, di controllare se
vi sono nuovi messaggi, aggiorna il timestamp a lui associato. Se trova Messaggi scaduti li
elimina.
Il server attiva al massimo un numero prefissato di thread.
CASO PULL
FRUITORE
1:Get my new
messages
CLIENT
SISTEMA DI
CONSEGNA
SERVER
2:New messages
Architettura lato fruitore (6/7)
Caso pull:
Lato sistema di consegna è presente un servizio che periodicamente attiva un certo numero
massimo di thread che fungono da client. A tale thread viene associato un fruitore per il quale
deve controllare se sono arrivati nuovi messaggi. In caso affermativo i messaggi vengono
consegnati ad un thread server in ascolto lato fruitore e viene aggiornato il timestamp
corrispondente.
Se il thread trova messaggi scaduti, li elimina.
CASO PUSH
FRUITORE
SISTEMA DI
CONSEGNA
1:new messages
SERVE
R
CLIENT
Architettura lato fruitore (7/7)
Fruitori mobili:
 hanno un contratto di tipo NotPay e una modalità di consegna di tipo pull;
 sono fruitori dotati di connettività wirless e non sempre connessi alla rete, per questo
motivo è stata introdotta la figura del proxy.
Proxy:
 si pone fra il sistema di consegna e il fruitore e funge da client al posto di quest’ultimo;
 mantiene una lista locale di fruitori mobili che periodicamente va ad aggiornare
accedendo al DB centrale;
 si comporta come se fosse un normale fruitore NotPay di tipo pull;
 mantiene in locale l’insieme dei messaggi nuovi arrivati per conto dei fruitori mobili e
non ancora acceduti da questi. Il fruitore mobile potrà accedere ai propri messaggi
connettendosi ad un server web che potrebbe trovarsi sullo stesso nodo del proxy. Il
server web deve identificare il fruitore e in caso affermativo visualizza i nuovi messaggi
arrivati.
Tolleranza ai guasti (1/2)




La tolleranza ai guasti è stata gestita sia per il sistema di consegna che per il sistema di
contrattazione; in entrambi i casi si è fatta ipotesi di guasto singolo.
Caso sistema di contrattazione: la tolleranza ai guasti viene affrontata attraverso la
replicazione e per le ipotesi fatte basta una sola copia -> modello passivo con copia fredda.
Il sistema di contrattazione slave è munito di un servizio che invia periodicamente al master un
KeepAlive per capire se è ancora attivo. Oltre un timeout impostato, si considera il master
caduto. In tale caso il servizio attiva lo slave e lo registra sul registry al posto del master.
Lo slave si mette in attesa di nuove richieste, mentre il servizio continua a mandare un
keepalive al master per controllare se si riattiva. Se questo accade, il servizio avverte lo slave
che terminato di servire la richiesta corrente si disattiva. Il master a questo punto dovrà
reinserirsi sul Registry.
1:Are you alive?
Sistema di
Contrattazione
Master
………….
Time-out scaduto
Sistema di
Contrattazione Slave
2:Nome
Servizio,IP,PORTA
3:Ok
REGISTRY
Tolleranza ai guasti (2/2)




Il client che si accorge che il sistema di contrattazione è caduto, attiva un servizio di
recovery che si occupa automaticamente di: accedere al registry, recuperare l’indirizzo
aggiornato del sistema di contrattazione, connettersi a questo e rieseguire in automatico le
operazioni che fino a quel momento il client ha eseguito per non obbligare l’utente a
ricominciare da capo.
Caso sistema di consegna: anche in questo caso, per le ipotesi fatte basta una sola copia
per garantire la continuità del servizio. Ogni sistema di consegna è idempotente -> per
rispettare il principio di minima intrusione ogni sistema di consegna ha come sostituto un
altro sistema di consegna. Il sistema di consegna sostituto viene assegnato staticamente.
Possiamo quindi avere per un sistema di consegna due tipi di fruitori: permanenti e
temporanei.
L’availability viene garantita solo per i fruitori di tipo Pay: se un fruitore di tipo pull si accorge
che il sistema di consegna è caduto, attiva un servizio di recovery che va a cercare nel DB
centrale il nodo sostituto e lo connette a questo. Nel caso invece di un fruitore di tipo push, il
servizio di recovery dopo aver cercato e trovato il sostituto, aggiunge il fruitore fra quelli
temporanei.
Gestione della Qualità di Servizio






La qualità di servizio riguarda principalmente i fruitori di tipo pay.
Viene garantita la persistenza delle notizie fino a scadenza;
Comunicazione con connessione -> affidabile;
Si cerca di garantire un numero minimo di messaggi all’ora: se non stiamo rispettando il
vincolo, viene data priorità alla consegna dei messaggi per i fruitori di tipo pay fino a quando
non si torna al minimo concordato;
Si cerca di garantire un numero massimo di messaggi all’ora: se non stiamo rispettando il
vincolo, viene bloccato l’invio di messaggi;
Il contratto per i fruitori di tipo pay prevede che la consegna di un messaggio avvenga con un
ritardo massimo da quando viene immesso nel sistema di distribuzione. Questo aspetto
viene gestito principalmente dal sistema di distribuzione; il sistema di consegna si occupa di
controllare il ritardo che il messaggio ha e nel caso superi il tempo massimo stipulato, per
velocizzare il servizio, verranno momentaneamente sospese le consegne dei messaggi per i
fruitori di tipo notPay fino a che tale valore non rientra nel limite stabilito da contratto.
Conclusioni e sviluppi futuri





È stato realizzato un prototipo del sistema che, come richiesto dai requisiti, permette
il disaccoppiamento fra la fonte e il fruitore;
Il sistema supporta l’eterogeneità;
L’architettura è facilmente estendibile a livello continentale;
Non sono stati effettuati test troppo attendibili;
Non è stato approfondito l’aspetto riguardante il DB centrale, i fruitori mobili e la
sicurezza nelle trasmissione di informazioni.