Progetto di Reti di Calcolatori LS
a cura di
Gesualdi Marco
Miniello Giuseppe
Vukovic Veljko
Obiettivi
 Realizzare un sistema di distribuzione di notizie su
larga scala da parte di un’agenzia di stampa
 Mettere in comunicazione fonti e fruitori
 Entità eterogenee
 Diverse qualità di servizio
 Robustezza
 Gestione di 2 diverse tipologie di comunicazione: pull
e push
Architettura del sistema
Supplier
Consumer
Consumer
Consumer
Notification
System
Supplier
Supplier
Notification System
Entità utilizzata per gestire:
 Comunicazione con supplier e consumer
 Registrazione e deregistrazione delle entità
 Persistenza delle news nel sistema attraverso uso di un
vettore con eliminazione news scadute
 Mantenimento argomenti disponibili in base a quelli
inviati dai supplier
 Contratto stabilito con consumer
Consumer
Componente molto leggero
 Riceve news in base al filtraggio stabilito
 Stabilisce un contratto con il Notification System
 Gestione comunicazione pull e push (attraverso Proxy)
 Connessione e disconnessione dal Notification System
Supplier
Componente leggero con i seguenti servizi
 Creazione ed eliminazione di argomenti
 Creazione ed invio di news
 Connessione e disconnessione dal Notification System
 Gestione contratto con Notification System
Gestione argomenti
 Una lista di argomenti per ogni supplier
 Modifiche di tale lista implicano comunicazione con
Notification System
 Tutti gli argomenti “ereditano” da un argomento padre
General
Comunicazione con Notification
System
Due tipi di comunicazione:
 pull, il supplier salva le news su un file
 push, utilizzato handler per creare eventi di invio news
e per ricevere conferma da parte del Notification
System
Filtraggio
Passaggio
filtri
una modalità
di comunicazione
 Utilizzo
deidei
filtri
deldaNotification
Service
di CORBA
ad un’altra
attraverso ildel
passaggio
dell’oggetto
 Utilizzo
di estensione
Trader Constraint
Language,
FilterInfo,
caratterizzato da:
basato
su BNF
 Filter: filtro
rappresentante
argomenti
 Effettuato
a livello
del Notification
Serviceeper
sottoargomenti
negoziati
migliorare
le prestazioni:
consumer e proxy ricevono
 filterId:
id interesse
del filtro e non tutti gli eventi (overhead
solo
eventi di
eccessivo)
 exclusiveFilter: filtro rappresentante gli argomenti e
sottoargomenti esclusivi negoziati
 exclusiveFilterId: id del filtro esclusivo
Filtraggio: Esempio
Filtraggio per notizie non esclusive con argomento
Sport e sottoargomento Calcio
$isExclusive == FALSE and $argument == 'Sport’
and $subArguments == ‘Calcio’
notizie non esclusive
sottoargomento Calcio
argomento Sport
Test su intero sistema
 Due categorie di test:
 Operational Test: verifica delle funzionalità del sistema
 Load test: per analizzare il comportamento in caso di
overloading
 Sono state inviate un numero crescente di news, da 25
a 1000
 Entità suddivise su 3 macchine differenti:
 Notification System e Proxy Factory Manager
 Proxy Factory
 Consumer e Supplier
Test su intero sistema
 Modalità push:
 Andamento curve simile se normalizziamo
 Ritardo medio nel distribuito: 137 ms. Legato al traffico in rete
 Modalità pull:
 A causa del timeout per il pull del Notification Service di CORBA
comportamento molto simile tra distribuito e locale
Modalità push
Modalità push: ritardo medio
tra invio e ricezione
Modalità pull
Test specifici
Per verificare corretto comportamento del supplier:
 creazione di file xml di configurazione corretto e non
corretto e analisi del comportamento,
 verifica corretto comportamento in caso di caduta del
supplier o semplice disconnessione,
 analisi comportamento in caso di inserimento errato
dei parametri di una news
 verifica del corretta creazione e cancellazione di
argomenti
 verifica del filtraggio
Conclusioni
 Entità leggera e performante
 Filtraggio efficace, facile da modificare e da estendere
 Gestione efficace della comunicazione (impiego di
poca banda)
 Sviluppi futuri:
 aggiungere altri parametri per il filtraggio
 gestire in modo più efficace l’esclusività della news e
l’attendibilità di un supplier