Progetto RE.VE.N.GE. (REliable and VErsatile News delivery support for aGEncies) Reti di Calcolatori L-S Anno Accademico 2005/2006 Nardini Elena 0000232607.

Presentazione sul tema: "Progetto RE.VE.N.GE. (REliable and VErsatile News delivery support for aGEncies) Reti di Calcolatori L-S Anno Accademico 2005/2006 Nardini Elena 0000232607."— Transcript della presentazione:

1 Progetto RE.VE.N.GE. (REliable and VErsatile News delivery support for aGEncies) Reti di Calcolatori L-S Anno Accademico 2005/2006 Nardini Elena 0000232607 Docente: Corradi Antonio Referente progetto: Ing. Stefano Monti

2 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.

3 Sistema RE.VE.N.GE. Il sistema è composto principalmente da tre parti: 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 Fonti Fruitori

4 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.

5 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;

6 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.

7 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.

8 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.

9 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.

10 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.

11 Architettura lato fruitore (2/7) Sistema Contrattazione:IP,PORT ……………… REGISTRY SISTEMA DI CONTRATTAZIONE 1:Nome servizio,IP,PORTA 2:Ok CLIENT 1:Nome servizio2:IP,PORT 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.

12 Architettura lato fruitore (3/7) SISTEMA DI CONTRATTAZIONE CASO 1 CLIENT DB 1:UserName;Password; Sistema di Consegna 4:contratti disponibili 2:Utente presente?3:No 5:Contratto scelto 6:Memorizza Contratto e Utente 7:Ok (Per contratti Pull indirizzo del Sistema di Consegna) CASO 2 SISTEMA DI CONTRATTAZIONE CLIENT DB 1:UserName;Password; Sistema di Consegna 3:Si 5:Nuovo Contratto scelto 6:Modifica contratto 2:Utente presente? 4:contratti disponibili 7:Ok (Per contratti Pull indirizzo del Sistema di Consegna) 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.

13 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.

14 Architettura lato fruitore (5/7) FRUITORE CASO PULL CLIENT SISTEMA DI CONSEGNA SERVER 1:Get my new messages 2:New messages 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.

15 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. FRUITORE CASO PUSH SERVE R SISTEMA DI CONSEGNA CLIENT 1:new messages

16 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.

17 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. Sistema di Contrattazione Master Sistema di Contrattazione Slave REGISTRY 1:Are you alive? …………. Time-out scaduto 2:Nome Servizio,IP,PORTA 3:Ok

18 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.

19 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.

20 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.