R.E.V.E.N.G.E. RELIABLE AND VERSATILE NEWS DELIVERY SUPPORT FOR AGENCIES Corso di Reti di Calcolatori LS – AA Professore: Antonio Corradi Referente progetto: Stefano Monti Presentazione di Chiara Chiappini

Sommario Introduzione al progetto: caratteristiche R.E.V.E.N.G.E Introduzione agli strumenti utilizzati: RTI DDS Architettura realizzata: Sistema centrale e Sistema locale QOS: affidabilità e tolleranza ai guasti e scalabilità Test Conclusioni e sviluppi futuri

R.E.V.E.N.G.E.: caratteristiche Sistema di consegna di notizie Requisiti fonti Requisiti fruitori Notizie 1.Priorità 2.Min-max notizie consegnabili in un’unità di tempo 3.Grado di attendibilità delle notizie 4.Livello affidabilità 1.Qualità di servizio specificata come affidabilità delle consegne 2.Tempi min-max di consegna della notizia 3.numero min-max di notizie da ricevere nell’unità di tempo 4.Argomenti di interesse 5.Possibilità di esclusiva su alcuni tipi di notizie 1.Tempo massimo di consegna 2.Livello di priorità 3.Argomenti trattati 4.Località di provenienza

R.E.V.E.N.G.E.: obiettivi Riuscire a mettere in comunicazione fonti e fruitori altamente diversi ed eterogenei Supportare diversi livelli di qualità di servizio sia per le fonti, sia per i fruitori Definire un sistema di contrattazione tra fruitori e sistema modificabile durante l’esecuzione Supporto per fruitori mobili Supporto per fonti e fruitori di tipo push e pull

RTI DDS Middleware per sistemi distribuiti basati su scambi di dati Interazione publish-subscribe Discovery automatico di nuove entità Utilizzo dell’implementazione RTI Permette utilizzo di diverse piattaforme e linguaggi in quanto l’interfaccia è definita tramite IDL Offre parametri relativi alla qualità del servizio

Architettura globale 1/2 Volendo fornire un sistema di distribuzione in grado di coprire un’area molto vasta, abbiamo distribuito il sistema di consegna su più località Sistemi locali in grado di distribuire notizie tra fonti e fruitori di loro appartenza

Architettura globale 2/2 Un sistema centrale in grado di inoltrare le notizie a fruitori non appartenenti al sistema locale di generazione della notizia Il fruitore riceve in modo trasparente news dal sistema centrale, senza conoscere l’esatto luogo di generazione …perché quest’architettura?

Sistema centrale Gestione centralizzata delle esclusive: vantaggi e svantaggi Inoltro notizie e alternative possibili Perdita di connettività dei fruitori: tenere sempre aggiornata la gestione delle esclusive per 1. evitare casi di mancati invii per esclusive non correttamente rilasciate 2. evitare invii inutili a fruitori ormai sconnessi

Affidabilità e tolleranza ai guasti 1/2 Recovery in seguito alla caduta di un sistema locale Scelta del sistema locale più vicino a cui associarsi con broadcast di richiesta e attesa: la prima risposta ottenuta determina la scelta

Affidabilità e tolleranza ai guasti 2/2 Architettura master-slave Replicazione nello spazio: copie calde del sistema centrale Possibilità di istanziare più slave con scelta statica dello slave da mettere in esecuzione Failure trasparency per i sistemi locali Non è gestita la replicazione delle news: i costi di gestione non avrebbero giustificato il vantaggio ottenuto

Scalabilità Possibilità di aggiungere nuovi sistemi locali senza dover apportare modifiche o aggiunte nel sistema: l’elevata scalabilità è fornita dal middleware DDS utilizzato L’aggiunta di una fonte è trasparente al fruitore: conseguenza del disaccoppiamento fornito dal Sistema

Test ● Frequenza di generazione di notizie sostenuta dal Sistema: fino ad 1 ms. Tempi di consegna delle notizie variando la frequenza di generazione Tempi di registrazione Tempi di consegna delle notizie variando il numero dei fruitori Solo Sistema Locale 2 Sistemi Locali e Sistema Centrale

Conclusioni e sviluppi futuri E’ stato sviluppato un sistema in grado di distribuire notizie realizzando un disaccoppiamento tra fonti e fruitori Il sistema realizzato funziona correttamente senza perdite nelle consegne per frequenze di generazione fino a 15 notizie al secondo Come sviluppi futuri si può prevedere una gestione load balancing del Sistema Centrale