Tesi di Laurea. Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Tesi di Laurea. Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based"

Transcript

1 Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Relatore: Prof. Roberto Baldoni Correlatore: Dott. Leonardo Querzoni Laureando: Fabio Papale Anno Accademico 2008/2009

2 Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria Informatica Tesi di Laurea Un Meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Relatore: Laureando: Prof. Roberto Baldoni Fabio Papale Correlatore: matricola: Dott. Leonardo Querzoni Controrelatore: Prof. Giuseppe Santucci Anno Accademico 2008/2009

3 Ai miei genitori, per esser stati un costante sostegno durante questo lungo e difficile percorso. Alla mia dolce metà, per aver camminato al mio fianco dall inizio alla fine.

4 Ringraziamenti Per la seconda volta sono arrivato a questo momento, scrivere i ringraziamenti per la mia tesi di Laurea. Finalmente, si spera, che questa sia l ultima! Prima di tutto vorrei ringraziare il Professor Baldoni, per avermi ispirato con le sue parole, portandomi sulla retta via : giunto a Roma due anni fa, affascinato dall Intelligenza Artificiale, è bastata una sola lezione del suo corso per farmi appassionare più che mai ai Sistemi Distribuiti, portandomi a rivedere il mio intero piano di studi magistrali. Lo ringrazio inoltre per avermi affidato a Leonardo, che con la sua passione e perspicacia, mi ha guidato ed aiutato durante questo duro lavoro di tesi. Grazie a entrambi per avermi permesso di lavorare ad un idea così importante ed innovativa. Inoltre un enorme Grazie ai miei genitori e alla mia famiglia, per avermi sostenuto in questa pazza idea di specializzarmi a Roma. Grazie mamma e papà per tutto quello che avete sempre fatto per me, e non vi preoccupate più: finalmente è finita!!! Infine, un ultimo ringraziamento lo voglio fare a quella pazzerella che è venuta a Roma con me: Floriana, grazie per avermi aiutato e sostenuto in questi due anni, e soprattutto per tutti quei momenti (e vi assicuro che sono stati tanti) in cui ti rompevo le scatole cercando di spiegarti tutte le contorsioni mentali dei Sistemi Distribuiti e di questa tesi! Grazie Amore. Grazie a tutti. Fabio

5 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Indice Capitolo 1 - Introduzione Contributo della tesi Organizzazione del testo...8 Capitolo 2 - I sistemi Publish-Subscribe Descrizione del sistema Caratteristiche di disaccoppiamento Altri paradigmi di comunicazione Meccanismi di selezione delle notifiche Channel-based selection Topic-based selection Content-based selection Type-based selection Schemi misti Un approfondimento sui meccanismi topic-based e content-based Implementazioni CORBA Event Service TIBCO Rendez-vous SCRIBE TERA Elvin Gryphon SIENA JEDI Hermes REBECA

6 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 3 - Trasformare un sistema topic-based in content-based Introduzione al problema Una corrispondenza dinamica tra spazi continui e insiemi discreti Discretizzare lo spazio continuo multidimensionale L albero di sistema (ST) Il problema dei falsi positivi I protocolli di discretizzazione dinamica Garantire la consistenza degli alberi nel sistema distribuito L interfaccia content-based La pubblicazione di un evento Sottoscrizioni ed advertisements Annullamento di sottoscrizioni ed advertisements...52 Capitolo 4 - Test e risultati sperimentali L ambiente di simulazione I test effettuati Analisi dei tempi di risposta del sistema Efficienza della discretizzazione dinamica Costo della discretizzazione dinamica...63 Conclusioni...64 I risultati ottenuti...64 Sviluppi futuri...65 Appendice A - Implementazione del sistema...66 Bibliografia

7 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 1 Introduzione Le architetture dei grandi sistemi informativi sono, ancora oggi, nella quasi totalità dei casi, costruite su piattaforme client/server. Nel paradigma client/server due host interagiscono tra loro: uno richiede dati o funzionalità (client), mentre il secondo (server) li fornisce. Il tipo di comunicazione è sincrono: il client invia una richiesta al server; questo la elabora, e quindi invia la risposta al client. Durante tutto il periodo di interazione, client e server risultano impegnati esclusivamente nella transazione e quindi impossibilitati ad eseguire altre operazioni. Un esempio di architettura client/server ci è dato dal World Wide Web e nello specifico dal protocollo HTTP usato per richiedere pagine HTML ad un server web. In questo caso il client, impersonato da un browser, richiede al server una specifica pagina HTML; il server, ricevuta la richiesta, la elabora, ed invia il contenuto della pagina al client. In questo semplice esempio è possibile intravedere le caratteristiche del modello client/server che ne costituiscono la sua forza, ma anche la sua debolezza. Innanzi tutto è bene notare che nei sistemi client/server le entità che possono interagire in un dato istante sono solo due (client e server): questo rende molto più difficoltosa la realizzazione di applicazioni che richiedono comunicazioni uno-a-molti o molti-a-molti, infatti il server deve essere strutturato in modo tale che sia possibile gestire parallelamente più canali di comunicazione indipendenti con altrettanti client distinti. Inoltre il client, cioè l host che inizia la comunicazione, deve necessariamente conoscere l indirizzo di rete del server a cui richiedere le informazioni di cui necessita, e non potrà quindi ottenere servizi se non dai server a lui noti; questa caratteristica è detta accoppiamento spaziale. Il paradigma richiede, affinché la comunicazione abbia luogo, che 3

8 Capitolo 1: Introduzione entrambi gli host siano attivi al momento della comunicazione: se il client invia una richiesta, ma il server che deve riceverla non è in quel momento attivo, il client aspetterà inutilmente una risposta che non arriverà mai, fino allo scadere di un timeout; questa caratteristica prende il nome di accoppiamento temporale. Per concludere, come abbiamo già accennato, il paradigma prevede che i due host siano bloccati per tutto il periodo della comunicazione e non possano, durante questo periodo, compiere ulteriori operazioni: questa caratteristica è detta accoppiamento nel flusso delle operazioni. Nonostante i limiti che abbiamo ora visto, il modello client/server ha riscosso, dalla nascita delle reti di elaboratori ad oggi, un incredibile successo. Ciò è da imputare sia alla semplicità del modello stesso (solo due entità interagiscono con un chiaro flusso temporale delle operazioni), sia alla sua adattabilità a moltissimi ambiti applicativi. Più in generale il paradigma client/server risulta adeguato per tutte quelle applicazioni in cui esiste un soggetto che necessita di un servizio o di un informazione solo in un certo istante nel tempo e sa già da chi ottenere questo servizio; il fatto che l informazione venga prelevata dalla sorgente su richiesta ha portato a definire questo sistema anche come information pull. Naturalmente non tutte le applicazioni ricadono in questa categoria. Esistono applicazioni in cui è l informazione ad iniziare la comunicazione, e non la necessità di ottenere questa stessa informazione. In questo tipo di applicazioni l informazione interessa solitamente più di un soggetto e può essere prodotta in un istante imprecisato nel tempo: per questo genere di applicazioni è più naturale pensare ad una forma di interazione in cui sia l entità che produce l informazione ad inviarla a chi ha espresso un interesse verso quell informazione (information push). Un tipico esempio di information push è offerto dai sistemi di monitoring delle quotazioni azionarie: ad ogni variazione nella quotazione di un singolo titolo, vengono avvertite (ma d ora in poi diremo notificate) tutte le persone che hanno espresso il proprio interesse nei confronti di quel titolo. In questo ambito, gli 4

9 Capitolo 1: Introduzione operatori di borsa possono trovarsi nelle condizioni di dover prendere molte decisioni con estrema rapidità a partire dal momento del cambio di valore di un titolo. Un applicazione di monitoring basata sul modello client/server interroga costantemente un server posto presso la borsa valori per aggiornare i valori dei titoli (polling). Perché un applicazione del genere risulti utile deve effettuare interrogazioni con un alta frequenza per garantire all operatore un aggiornamento dei valori delle quotazioni con un ritardo massimo stabilito. Minore è il ritardo massimo accettabile, maggiore è la frequenza delle interrogazioni al server e di conseguenza lo spreco di risorse: infatti ad un incremento della frequenza di aggiornamento corrisponde un incremento della probabilità che tra due interrogazioni successive il valore dei titoli a cui l operatore è interessato non sia cambiato, rendendo quindi superflua l interrogazione. Inoltre un applicazione strutturata in questo modo difficilmente sarà scalabile verso un largo numero di client (ovvero in grado di richiedere una crescita di potenza elaborativa proporzionale alla crescita del numero di richieste da soddisfare): un singolo server dovrebbe elaborare costantemente, una ad una, tutte le richieste provenienti da tutti i client interessati ed inviare ogni volta lo stato aggiornato dei valori. Appare quindi chiaro che la realizzazione di un applicazione come questa porterebbe ad una forzatura del paradigma client/server. La ricerca improntata alla risoluzione di questi problemi ha portato all ideazione di nuovi modelli di comunicazione. Tra questi molto credito è stato dato negli ultimi tempi al Publish-Subscribe. Publish-Subscribe è un paradigma di comunicazione asincrono che garantisce un totale disaccoppiamento tra produttore e consumatori dell informazione. I consumatori, chiamati in questo ambito subscriber, possono esprimere il loro interesse verso un sottoinsieme degli eventi, cioè delle informazioni prodotte, ed essere successivamente notificati di ogni evento generato da un publisher (cioè un produttore di informazioni) che appartiene al sottoinsieme a cui essi 5

10 Capitolo 1: Introduzione sono interessati. Il punto di forza di questo modello risiede nel totale disaccoppiamento temporale, spaziale e del flusso delle operazioni tra il publisher ed i subscriber. L introduzione di questo nuovo modello all interno di applicazioni esistenti al posto di quello client/server ha permesso di migliorare l uso delle risorse da parte delle applicazioni stesse, lasciando inalterato il modo di operare degli utenti. Come si vedrà nel capitolo successivo (cfr. paragrafo 2.4), i sistemi Publish- Subscribe si differenziano principalmente in base al meccanismo di selezione delle notifiche. Nel corso degli anni, uno dei meccanismi che ha riscosso maggior successo è il topic-based, ed il motivo di tale successo è facilmente riconducibile alla sua estrema semplicità (per un approfondimento vedi anche paragrafo 2.5), la quale porta ad implementazioni molto efficienti. Il rovescio della medaglia di questo meccanismo è il problema dei falsi positivi, o più comunemente detti spam: siccome in un tale sistema gli utenti possono scegliere soltanto l argomento, cioè il topic, degli eventi o delle sottoscrizioni da pubblicare, senza poter esprimere ulteriori vincoli, la probabilità di ricevere degli eventi che in realtà non sono di interesse è alta. Per questo motivo, negli ultimi anni, la ricerca si è spinta verso altri meccanismi di selezione delle notifiche, individuando in quello content-based una valida alternativa al precedente. Ad oggi molte sono le proposte di sistemi Publish-Subscribe basate su tale meccanismo (cfr. paragrafo 2.6), che quindi permettono una selezione molto più granulare dell insieme di eventi di interesse, basata sui contenuti degli eventi pubblicati e non solo sull argomento; di conseguenza, tali sistemi riescono ad abbattere la probabilità di ricezione dei falsi positivi. Purtroppo, data la complessità di tali sistemi, che durante le pubblicazione devono essere in grado di realizzare un instradamento che sia funzione del contenuto degli eventi stessi, non si riesce ancora a raggiungere i livelli di efficienza dei sistemi Publish-Subscribe di prima generazione. 6

11 Capitolo 1: Introduzione 1.1 Contributo della tesi In questo lavoro di tesi si è cercato di superare i limiti di efficienza che affliggono i sistemi Publish-Subscribe content-based appena evidenziati, sviluppando principalmente due idee innovative: Realizzare un sistema Publish-Subscribe content-based al di sopra di un generico sistema topic-based, sfruttando quindi l efficienza di questi ultimi durante l instradamento di eventi e sottoscrizioni, e contemporaneamente riuscendo a fornire agli utenti un interfaccia altamente espressiva, tipica dei sistemi contentbased. Realizzare un associazione dinamica tra uno spazio continuo multidimensionale ed un insieme discreto di elementi, rappresentando questi i modelli dei dati su cui si basano rispettivamente i sistemi content-based e topic-based. In particolare, lo sviluppo di queste due idee ha richiesto: La realizzazione di un meccanismo dinamico di mapping in grado di associare ad ogni evento definito dal modello content-based sovrastante, uno ed un solo topic del sistema topic-based sottostante. L implementazione di un prototipo dotato di interfaccia content-based e del meccanismo di mapping dinamico del punto precedente. La scelta di un ambiente di simulazione topic-based in cui poter inserire il prototipo al fine di testare l efficienza del meccanismo dinamico ideato. L esecuzione di una serie di simulazioni e test sperimentali, e la relativa analisi dei risultati ottenuti. 7

12 Capitolo 1: Introduzione 1.2 Organizzazione del testo Nel capitolo successivo analizzeremo le caratteristiche salienti del modello Publish-Subscribe ed i suoi punti di forza rispetto a quello client/server; faremo quindi un confronto con altri paradigmi nati come alternativa al client/server, analizzeremo le varie tipologie di sistemi Publish- Subscribe, approfondiremo le differenze fra due di queste tipologie (i topicbased ed i content-based), per concludere poi con un analisi dei sistemi che rappresentano lo stato dell arte per le architetture Publish-Subscribe. Nel terzo capitolo entreremo nei dettagli di realizzazione delle idee alla base di questo lavoro di tesi; vedremo come sia possibile elevare un generico sistema topic-based in un più complesso sistema content-based, realizzando un meccanismo dinamico per il mapping tra i modelli dei dati dei due sistemi, senza modificare i meccanismi di instradamento degli eventi e delle sottoscrizioni propri del sistema topic-based. Il quarto capitolo sarà quindi interamente dedicato ai risultati degli esperimenti che abbiamo svolto tramite un prototipo appositamente sviluppato, ed integrato in un simulatore di un particolare sistema topic-based: TERA. Tali esperimenti, ideati con lo scopo di confrontare il sistema sviluppato con soluzioni basate su mapping statici, mostreranno come il nostro sistema, dotato di un meccanismo di mapping dinamico, riesca ad essere, ad un costo relativamente basso, molto più efficiente di sistemi content-based basati su mapping statico dello spazio degli eventi. 8

13 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 2 I sistemi Publish-Subscribe 2.1 Descrizione del sistema Un sistema Publish-Subscribe è essenzialmente costituito da un insieme di client che scambiano eventi tra di loro in modo asincrono comportandosi, secondo il caso, da produttori o consumatori di informazione [4, 5]. Un entit{ logica, chiamata event notification service (d ora in avanti ENS), agisce come mezzo di interconnessione, garantendo il disaccoppiamento tra i publisher ed i subscriber (Fig. 2.1). Possiamo immaginare l ENS come un servizio raggiungibile da tutti gli host tramite il quale essi possono comunicare; il modello architetturale sarà a breve approfondito. Figura 2.1: Architettura Publish-Subscribe Un evento è costituito da dati strutturati solitamente secondo uno schema nome-valore. Per riprendere l esempio precedentemente visto, un possibile evento nel sistema di monitoring delle quotazioni azionarie potrebbe essere [titolo ACME INC, valore=125.50]. Un evento può essere visto come un punto all interno di uno spazio n- dimensionale: se infatti immaginiamo che ciascuno degli n attributi definiti negli eventi rappresenti una coordinata in uno spazio fittizio, un singolo evento 9

14 Capitolo2: I sistemi Publish-Subscribe definisce un valore specifico per ogni coordinata, identificando quindi un punto nello spazio (Fig. 2.2). Questo spazio fittizio è chiamato event-space ed è una caratteristica di ogni applicazione basata sull uso del paradigma Publish- Subscribe. Figura 2.2: Esempio di spazio degli eventi bidimensionale Ogni subscriber dichiara a quali eventi è interessato tramite l invio all ENS di sottoscrizioni. Ogni sottoscrizione contiene un insieme di regole che l ENS userà per filtrare gli eventi pubblicati e notificare quindi al subscriber solo quelli di suo effettivo interesse. All interno dell event-space una sottoscrizione è rappresentabile come un sottospazio definito dai singoli filtri che la compongono (Fig. 2.2). In questo modo l interesse di una sottoscrizione verso un evento può essere facilmente verificato controllando l intersezione nell event-space tra la sottoscrizione e l evento (questa operazione è detta matching dell evento con la sottoscrizione). L inserimento di nuove sottoscrizioni o l eliminazione di sottoscrizioni esistenti avviene tramite l uso delle primitive subscribe() ed unsubscribe() sull API (Application Programming Interface) esposta dell ENS (Fig. 2.1). I publisher inseriscono eventi nel sistema tramite la primitiva notify() sull API dell ENS; questi provvederà quindi a notificare l evento ai subscriber interessati tramite l uso della stessa primitiva sull API di ogni singolo subscriber. L ENS `e un entità che funge quindi da mediatore tra tutti i publisher e tutti i subscriber mascherando l infrastruttura che permette la comunicazione tra essi. 10

15 Capitolo2: I sistemi Publish-Subscribe Questa entità è un astrazione la cui implementazione varia in modo significativo da sistema a sistema. Nei primi esempi di sistemi Publish-Subscribe l ENS era realizzato in modo centralizzato con un programma in funzione su un singolo server a cui facevano riferimento tutti i publisher e tutti i subscriber. In seguito ci si è resi conto che un implementazione centralizzata non poteva in alcun modo porre rimedio ai problemi di scalabilità propri delle architetture client/server, e si è quindi passati ad implementazioni distribuite. In queste ultime l ENS è composto da un insieme di processi indipendenti, chiamati broker, e posti su host distinti che interagiscono per portare a compimento tutte le operazioni richieste. In ogni caso, il tipo di implementazione usato per l ENS è un fattore che rimane completamente trasparente, sia ai publisher che ai subscriber, i quali interagiscono con esso esclusivamente tramite l API che esso espone. Nel seguito di questa tesi supporremo di avere a che fare sempre con implementazioni distribuite dell ENS, il cui modello architetturale sar{ ora brevemente descritto. Figura 2.3: ENS con un'infrastruttura distribuita In un sistema Publish-Subscribe distribuito l Event Notification Service è costituito da un insieme di N processi B1,...,BN, chiamati event brokers, i quali comunicano attraverso scambi di messaggi. Questi processi, ognuno in 11

16 Capitolo2: I sistemi Publish-Subscribe esecuzione su differenti host (o nodi), cooperano in modo da realizzare le funzionalità di un sistema Publish-Subscribe. La figura 2.3 mostra un esempio della struttura interna di un ENS distribuito dove vari brokers (B) collaborano per servire le richieste provenienti dai publisher (P) e dai subscriber (S). L architettura generale di un sistema Publish-Subscribe distribuito è mostrata in figura 2.4, ed è principalmente costituita da cinque livelli: Network, Overlay, Routing, Matching e Interface. Figura 2.4: Architettura generale di un ENS distribuito Livello di rete. I protocolli di rete legano il sistema Publish-Subscribe alla rete sottostante permettendo la trasmissione dei dati tra i partecipanti. Dato che un sistema Publish-Subscribe può essere distribuito su un insieme eterogeneo di reti, esso potrebbe utilizzare più di un singolo protocollo di rete sia per coprire le possibili eterogeneità software/hardware, sia per massimizzare le performance. Livello Overlay. Le primitive di comunicazione fornite dal livello di rete sono quindi usate dai broker per scambiare messaggi. Ogni messaggio è inviato da un broker Bi a un broker Bj attraverso un canale di livello applicativo, o link, li,j che li collega. Questi link sono delle pure astrazioni e non rappresentano delle connessioni durature o permanenti, quindi il vicinato di un broker nella rete 12

17 Capitolo2: I sistemi Publish-Subscribe overlay è determinata solamente da una relazione di conoscenza. Tutti i broker e i loro link di collegamento, formano una rete di livello applicativo, la overlay appunto, che incarna il sistema distribuito di notifica di eventi. Questa overlay può essere gestita con una soluzione ad - hoc, specificamente progettata per il particolare sistema Publish-Subscribe in considerazione,oppure con un generico protocollo di gestione dell overlay (Overlay Maintenance Protocol). Livello di Routing. In un sistema Publish-Subscribe distribuito gli eventi e le sottoscrizioni possono essere emessi da uno qualunque dei broker che costituiscono il sistema. Quindi il sistema deve essere equipaggiato con un sistema di instradamento degli eventi che sia in grado di realizzare dei corretti flussi degli eventi all interno dell ENS e raggiungere tutti i sottoscrittori interessati. Più formalmente: dato un evento e pubblicato su un broker Bi e una sottoscrizione s emessa su un broker Bj, se la sottoscrizione copre l evento, il meccanismo di instradamento deve instradare sia e che s su uno stesso broker Bk, dove il matching sarà elaborato. Questo meccanismo di routing è spesso riferito, in letteratura, come event routing, anche se comprende anche le sottoscrizioni. Durante l instradamento, un evento potrebbe essere ricevuto da qualche broker che non ospita nessuna sottoscrizione coprente; messaggi contenenti tali eventi sono chiamati messaggi di spam, perché il broker spreca risorse locali inutilmente. Tale problema verrà riaffrontato nel corso del terzo capitolo e, rinominato come Problema dei Falsi positivi, sarà studiato in modo approfondito per capire come può essere sfruttato per migliorare le prestazioni di un particolare tipo di sistema content-based, quello proposto in questo lavoro di tesi. Livello di Matching. Il matching è il processo di controllo se un evento è coperto da una sottoscrizione, cioè se un evento soddisfa le condizioni espresse dalla sottoscrizione. Questa operazione di solito viene effettuata dal sistema Publish-Subscribe in modo da determinare se notificare un evento ad un sottoscrittore oppure no, ma, a seconda della particolare implementazione del 13

18 Capitolo2: I sistemi Publish-Subscribe livello sottostante di instradamento, a volte esso può essere usato anche durante il processo di diffusione degli eventi. Livello di interfacciamento. Questo livello rappresenta come i client, per esempio i publisher ed i subscriber, interagiscono con l ENS. Due strategie opposte sono solitamente considerate. Con la prima strategia i broker che costituiscono l ENS sono dei server specializzati distribuiti e mantenuti da una azienda; ogni broker funge da access point per un numero molto largo di clienti, memorizzando le loro sottoscrizioni e pubblicando i loro dati. Una seconda strategia richiede invece che ogni client partecipi attivamente all interno del sistema anche come broker. Ogni broker, quindi, elabora solo le richieste provenienti dalle applicazioni locali che vogliono accedere al sistema. E comunque possibile un approccio misto, ma ad oggi, nessuna delle proposte esistenti lo adotta. 2.2 Caratteristiche di disaccoppiamento L intermediazione fornita dall ENS ha lo scopo di isolare completamente ciascun client da tutti gli altri. Tale isolamento è in grado di garantire: Disaccoppiamento spaziale: Gli elementi che interagiscono non devono necessariamente conoscersi dato che sia i publisher che i subscriber agiscono direttamente sull ENS; quando un publisher inserisce nel sistema un evento non sa quanti e quali subscriber saranno notificati; allo stesso modo quando un evento viene notificato ad un subscriber questi non sa da quale publisher l evento è stato inserito nella rete, ne quanti sono i publisher facenti parte del sistema. Questa caratteristica semplifica l uso del sistema in quanto richiede che ogni entità interagente (publisher o subscriber che sia) conosca esclusivamente un punto di accesso all ENS (solitamente l indirizzo di rete di un broker). Disaccoppiamento temporale: I subscriber interessati ad un dato evento non devono necessariamente essere collegati alla rete nell istante di inserimento di 14

19 Capitolo2: I sistemi Publish-Subscribe esso da parte di un publisher. Allo stesso modo all istante in cui un subscriber riceve l evento il publisher potrebbe essere già scollegato. Il disaccoppiamento temporale tra produzione e consumo dell informazione è totale. Questo semplifica la realizzazione delle applicazioni in quanto lo sviluppatore non deve più preoccuparsi di gestire il sincronismo tra produzione e consumazione dell informazione. Disaccoppiamento nel flusso delle operazioni: Il normale svolgimento delle operazioni all interno di un client non è in alcun modo interrotto dalla necessità di inviare o ricevere un messaggio dall ENS. L interazione con l ENS avviene in modo asincrono all interno dei client. 2.3 Altri paradigmi di comunicazione Parallelamente allo sviluppo dei sistemi Publish-Subscribe si è assistito alla nascita di altri paradigmi tutti improntati a risolvere i problemi che affliggono le architetture client/server. Nessuna delle alternative che ora andremo brevemente ad analizzare riesce però a fornire lo stesso grado di disaccoppiamento che abbiamo riscontrato nei sistemi Publish-Subscribe. Message passing: si tratta di un paradigma di comunicazione strettamente legato al concetto di socket, e come tale rappresenta una forma di comunicazione a basso livello. Con il message passing spesso vengono demandate all applicazione molte funzioni basilari, come l indirizzamento fisico o il data marshaling. La produzione dei messaggi è anche in questo caso asincrona, mentre rimane sincrono il consumo degli stessi. Produttore e consumatore sono accoppiati sia nel tempo, dato che entrambi devono essere contemporaneamente attivi al momento dello scambio dei messaggi, che nello spazio, dato che il produttore deve conoscere l indirizzo fisico del consumatore. 15

20 Capitolo2: I sistemi Publish-Subscribe RPC - invocazione remota: l invocazione remota di eventi, nelle sue numerose forme, è ad oggi il metodo più diffuso per implementare il calcolo distribuito. Con l uso di questo paradigma lo sviluppatore può utilizzare nella propria applicazione metodi remoti come se questi fossero locali. La semplicità del paradigma, unita alla sua potenza, ha decretato il suo successo sin dalla prima apparizione sotto forma di RPC (remote procedure call), per continuare nelle successive incarnazioni object-oriented (Java RMI, CORBA, Microsoft DCOM). D altra parte la natura uno-ad-uno della comunicazione con RPC rende poco naturale il suo uso in applicazioni che richiedono comunicazioni del tipo uno-amolti. Inoltre l intrinseca sincronia di RPC introduce forte accoppiamento temporale, spaziale e nel flusso delle operazioni sugli host interagenti. Notifications: si tratta di una forma primitiva di Publish-Subscribe. Con questa architettura i subscriber esprimono il loro interesse in un qualche tipo di informazione direttamente presso il publisher da cui quell informazione sarà originata. In questo caso si ha un completo disaccoppiamento nel flusso delle operazioni dato che l informazione verrà recapitata al subscriber solo nel momento in cui sarà disponibile, tramite l uso di un callback precedentemente dichiarato. Permane invece un forte accoppiamento spaziale dato che ogni subscriber interessato ad un certo genere di informazione dovrà conoscere in anticipo quale publisher sarà fonte di quell informazione. Shared spaces: il paradigma distributed shared memory fornisce agli host partecipanti al sistema di calcolo distribuito, uno spazio di indirizzamento comune; la comunicazione tra gli host avviene scrivendo e leggendo dati in questo spazio comune. Il tipo di memoria condivisa pi`u semplice `e fornito dai cosiddetti tuple-spaces, spazi di memorizzazione condivisi in cui le informazioni assumono la forma di tuple ordinate accessibili da tutti gli host partecipanti. La comunicazione tra host avviene tramite una primitiva di scrittura delle tuple (out()), una di lettura e cancellazione (in()), ed una di sola lettura (read()). Gli shared spaces garantiscono un completo disaccoppiamento temporale e 16

21 Capitolo2: I sistemi Publish-Subscribe spaziale tra i partecipanti, ma richiedono che il prelievo delle tuple dallo spazio condiviso sia sincrono. Code di messaggi: le code di messaggi riprendono molti degli aspetti principali dei tuple spaces aggiungendo caratteristiche di ordinamento temporale dei messaggi, e proprietà transazionali alle operazioni. Le operazioni di prelievo di informazioni dalle code sono simili alla primitiva in() dei tuple spaces, ma in questo caso quale informazione viene prelevata dipende dall istante di inserimento di questa nella coda e non dalla sua struttura. Come nel caso degli shared spaces le code di messaggi offrono disaccoppiamento nel tempo e nello spazio, ma non nel flusso delle operazioni. 2.4 Meccanismi di selezione delle notifiche La scelta di un adeguato metodo di selezione degli eventi è un argomento di cruciale importanza nella progettazione di un sistema Publish-Subscribe, in quanto la scalabilità del sistema stesso dipenderà da esso. Un metodo di selezione che imponga scelte troppo generiche porterebbe alla diffusione di notifiche inutili e costringerebbe i subscriber ad effettuare ulteriori filtraggi all arrivo delle notifiche stesse. D altra parte un meccanismo in grado di offrire un alta espressività, e quindi una maggiore specificità nella generazione dei filtri, renderebbe più complesso e computazionalmente impegnativo il meccanismo di routing delle notifiche, cioè quel meccanismo che, all interno dell ENS, porta le notifiche dal broker di ingresso a quelli su cui sono registrate le relative sottoscrizioni. Proprio il problema che si pone davanti a questa scelta ha ispirato questo lavoro di tesi, il cui contributo principale è la realizzazione di un sistema in grado di offrire un alta espressivit{, pur mantenendo la complessità, in termini di routing degli eventi, dei sistemi che impongono scelte troppo generiche. Analizzeremo ora i cinque principali approcci adottati nelle implementazioni oggi esistenti, mettendo in luce il loro grado di espressività. 17

22 Capitolo2: I sistemi Publish-Subscribe Channel-based selection. I primi esempi di sistemi Publish-Subscribe hanno adottato uno spazio degli eventi suddiviso in canali. Quando un evento viene inserito nel sistema è necessario specificare il canale di appartenenza. Questo meccanismo risulta molto efficace dal punto di vista della consegna degli eventi in quanto la suddivisione in canali degli eventi e dei subscriber permette di adattare noti algoritmi di multicasting al sistema di consegna delle notifiche. D altra parte sono evidenti i limiti di espressività: se un subscriber ha interesse per più canali simili dovrà inserire una sottoscrizione per ciascun canale; se un subscriber non è interessato a tutte le notizie pubblicate all interno di un canale, dovrà adottare qualche strategia di filtraggio una volta ricevuta una notifica. E chiaro quindi che questo metodo non permette un alta selettivi`a sulle notifiche se non moltiplicando il numero di canali. A questo si aggiunge l accoppiamento tra i publisher ed i subscriber dato dal fatto che un publisher deve conoscere in anticipo i canali possibili per poi scegliere quello su cui inserire una notifica, ed i subscriber devono conoscere i canali dai quali potranno ricevere le notifiche a cui sono interessati Topic-based selection. Il passo successivo nell evoluzione dei sistemi Publish-Subscribe è stata l introduzione di una gerarchia dei canali. In questi sistemi [6, 7, 8] è possibile creare canali (che in questo caso prendono il nome di topic) nidificati: quando un subscriber sottoscrive un canale riceve tutte le notifiche create in esso o in uno dei canali sottostanti nella gerarchia. Questa semplice modifica ha portato alla realizzazione di prodotti commerciali di successo tramite i quali è possibile implementare applicazioni anche molto complesse. Nonostante la maggiore flessibilità offerta dai sistemi topic-based, in essi possiamo riscontrare tutti i limiti propri dei sistemi channel-based. 18

23 Capitolo2: I sistemi Publish-Subscribe Content-based selection. Mentre con i due metodi precedentemente analizzati il contenuto di un evento rimaneva opaco all event notification service, nel caso di content-based selection [9, 10, 11] la selezione delle notifiche da recapitare ai subscriber si basa sull applicazione dei filtri, da cui le sottoscrizioni sono composte, al contenuto degli eventi. L incremento di espressività ottenuto permette di ridurre, se non annullare completamente, il rischio di notificare ad un subscriber un evento a cui non è realmente interessato. Il rovescio della medaglia è dato dalla complessità nell implementazione di efficaci algoritmi di routing delle notifiche e dalla minore scalabilità di sistemi basati su questo metodo. Il content-based routing garantisce un completo disaccoppiamento tra publisher e subscriber Type-based selection. Molto spesso, in un sistema topic-based, le notifiche appartenenti ad un canale oltre a mostrare un affinità nel contenuto, mostrano una quasi totale identità nella struttura. Questa idea ha portato a sostituire il concetto di topic con quello di tipo. Grazie a questa scelta la gerarchia dei tipi non deve essere più esplicitamente dichiarata (come nel caso topic-based), ma viene indotta dalla struttura delle classi che realizzano i tipi Schemi misti. Molte applicazioni richiedono la trasmissione di informazioni dalla struttura variegata che permette di attuare un approccio misto: un primo partizionamento con una metodologia topic-based, per poi affinare la selezione sugli attributi rimanenti per mezzo di tecniche di filtraggio tipiche dei sistemi content-based. Data la varietà delle applicazioni per cui è consigliabile l uso del paradigma Publish-Subscribe, un approccio misto ha il grande vantaggio di risultare più facilmente adattabile ai vari possibili scenari. 19

24 Capitolo2: I sistemi Publish-Subscribe 2.5 Un approfondimento sui meccanismi topic-based e contentbased Il paragrafo precedente ha fornito una visione generale di tutti i meccanismi di selezione degli eventi su cui si basano i sistemi Publish- Subscribe. In questo paragrafo si vuole dare un approfondimento su due dei meccanismi precedentemente introdotti, dato che sono gli elementi fondamentali di questo lavoro di tesi: i meccanismi topic-based e content-based. Come si vedr{ nel terzo capitolo, l obiettivo di questo lavoro di tesi è quello di trasformare un sistema Publish-Subscribe topic-based in un sistema contentbased, con l intento di superare i limiti imposti dal primo modello senza introdurre l eccessiva complessit{ che caratterizza le implementazioni del secondo modello. Questo paragrafo, quindi, analizza in modo più approfondito i due modelli confrontandone vantaggi e svantaggi. In un sistema topic-based il modello dei dati è estremamente semplice: esso è caratterizzato da un insieme discreto di argomenti, i topic, ai quali gli utenti devono riferirsi per pubblicare eventi o per comunicare i loro interessi, cioè effettuare le sottoscrizioni (figura 2.5). Questa estrema semplicità porta a realizzare implementazioni molto efficienti, che riescono ad avere dei livelli di routing e di matching (vedi paragrafo 2.1) molto efficaci e veloci. In un sistema content-based invece, il modello dei dati non è più un insieme discreto, bensì diventa uno spazio continuo multidimensionale definito da una serie di attributi (una dimensione per attributo), i quali a loro volta definiscono il contenuto degli eventi. Gli utenti di un sistema content-based, quindi, pubblicano eventi definiti all interno di questo spazio (ogni evento è un punto dello spazio multidimensionale), e comunicano le loro sottoscrizioni, le quali rappresentano una particolare regione multidimensionale contenuta nello spazio del sistema. In questo modo, ad un sottoscrittore saranno notificati solo e soltanto quegli eventi che ricadono nelle regioni di interesse da lui definite. 20

25 Capitolo2: I sistemi Publish-Subscribe Indubbi sono i vantaggi di una tale soluzione, ma come anticipato nel paragrafo precedente, essa comporta implementazioni dei livelli di routing e di matching abbastanza complesse. Figura 1.5: Confronto tra i meccanismi topic-based e content-based Questo lavoro di tesi, quindi, cerca di realizzare un implementazione efficiente del meccanismo content-based, prendendo come punto di partenza il meccanismo topic-based, per cercare di sfruttare l efficienza dei livelli di routing e di matching che si riesce ad ottenere con questo tipo di sistemi. Il terzo capitolo, quindi, affronta la problematica di come realizzare una tale implementazione. 2.6 Implementazioni Analizzeremo ora le principali implementazioni esistenti del paradigma Publish-Subscribe CORBA Event Service. Un richiesta CORBA standard genera un tipo di comunicazione sincrono. Per superare questa limitazione e permettere un maggiore disaccoppiamento nella comunicazione tra processi, l OMG ha introdotto il concetto di Event Service. L Event Service [5] `e un servizio offerto da CORBA che permette di disaccoppiare la comunicazione tra oggetti. Esso definisce due ruoli per gli 21

26 Capitolo2: I sistemi Publish-Subscribe oggetti: produttori e consumatori di informazione. L informazione viene fatta transitare dai produttori ai consumatori attraverso richieste CORBA standard. CORBA Event Service supporta due tipi di approccio per l avvio di una comunicazione e due per forma che la comunicazione può assumere. I due approcci possibili per instaurare una comunicazione sono il modello push e quello pull. Il primo permette ad un produttore di informazioni di iniziare il trasferimento dei dati verso i consumatori; il secondo permette al consumatore di iniziare la comunicazione richiedendo i dati ad un produttore. Nel primo caso l iniziativa è lasciata ai produttori, nel secondo ai consumatori. Il tipo di comunicazione può poi essere generico o tipizzato. Nel primo caso l informazione, oggetto della comunicazione, è completamente nascosta al servizio: la comunicazione avviene quindi per mezzo di semplici operazioni di push/pull nelle quali l unico parametro è il pacchetto contenente l informazione da trasferire. Nel secondo caso l informazioni è strutturata e può essere definita come lo sviluppatore preferisce. L Event channel permette a più produttori e più consumatori di comunicare in modo asincrono comportandosi esso stesso come produttore e consumatore. CORBA Event Service si configura quindi come una classica implementazione di servizio Publish-Subscribe channel-based. Successivamente l OMG ha rilasciato la specifica relativa a CORBA Notification Service [12], un evoluzione dell Event Service. All interno di CNS i messaggi possono essere di tre tipi: CORBA Any, un oggetto corba tipizzato in modo statico, o un Structured Event composto da un tipo, più campi filtrabili con una struttura nome-valore, ed un payload non filtrabile. Nel caso venga utilizzato quest ultimo genere di messaggi, il canale permette ai consumatori che vogliono dichiarare il proprio interesse, di specificare un filtro da applicare ai messaggi in transito attraverso il canale. Oltre a questa caratteristica, che avvicina CNS ai sistemi Publish-Subscribe content-based, è anche possibile federare più canali indipendenti in modo da formare una semplice rete per la diffusione degli eventi. 22

27 Capitolo2: I sistemi Publish-Subscribe TIBCO Rendez-Vous TIBCO Rendezvous [13] è un implementazione commerciale di grande successo del paradigma Publish-Subscribe. Si tratta di un sistema topic-based distribuito. Il suo funzionamento è incentrato sulla definizione di una spazio di indirizzi comune tanto ai messaggi quanto ai subscriber. Ciascun subscriber si registra presso il servizio indicando gli indirizzi a cui è interessato (il linguaggio per la dichiarazione degli indirizzi è reso più espressivo dalla possibilità di usare wildcards). Allo stesso modo, all atto della generazione di un messaggio da parte di un produttore, questo viene associato ad uno o più specifici indirizzi e recapitato quindi a tutti i relativi subscriber SCRIBE SCRIBE [6] è un implementazione del modello Publish-Subscribe topic-based basato su una overlay network gestita da Pastry [14]. SCRIBE è in grado di gestire un alto numero di topic, ciascuno associato al proprio gruppo di publisher e subscriber. Ogni subscriber deve dichiarare il proprio interesse per un certo topic al sistema; questo mantiene, per ogni topic, un albero di multicast che ha la sua base in un nodo di rendez-vous, e che contiene tutti i nodi che hanno dichiarato il proprio interesse nei confronti del topic. All inserimento di un evento all interno della rete, questo viene per prima cosa inviato al nodo di rendez-vous responsabile per il suo topic, e da questo inoltrato, tramite l albero di multicast, a tutti i subscriber. Questa particolare gestione dei topic basata sulla definizione di un nodo di rendezvous e sul mantenimento del relativo albero di multicast, deriva dall infrastruttura peer-to-peer sottostante offerta da Pastry. Il particolare metodo con cui, dato un topic, viene scelto il relativo nodo di rendezvous (basato sull hashing del topic stesso), permette una buona distribuzione del carico tra tutti i nodi appartenenti alla rete. 23

28 Capitolo2: I sistemi Publish-Subscribe TERA TERA [24] è un implementazione del modello Publish-Subscribe topic-based basato su overlay. La novità interessante che introduce questo lavoro è un meccanismo chiamato Interest Clustering, con il quale si cerca di ridurre il traffico inutile all interno dell ENS e soprattutto il numero di messaggi indesiderati, i cosiddetti spam, notificati agli utenti. Dato che questo è il sistema topic-based utilizzato per simulare e testare il sistema sviluppato in questo lavoro di tesi, è doveroso trattarlo un po più approfonditamente. Il meccanismo di interest clustering è basato sul concetto di similarità delle sottoscrizioni: quando le sottoscrizioni di un insieme di client sono sufficientemente simili, allora è possibile unire i client in un unico cluster. In questo modo il cluster riceverà principalmente traffico dati relativo alle sottoscrizioni che hanno dato vita al cluster stesso, diminuendo quindi la probabilità di ricevere spam. In un sistema Publish-Subscribe così fatto, la diffusione di un evento si divide in due fasi ben distinte: in una prima fase, chiamata Outer-Cluster Routing, l evento deve essere instradato nel sistema fino a trovare il cluster associato alle sottoscrizioni che coprono l evento; quindi, trovato il cluster, inizia la seconda fase, chiamata Inner-Cluster Diffusion, in cui l evento viene inviato a tutti i client costituenti il cluster. TERA, essendo topic-based, implementa un controllo della similarità delle sottoscrizioni molto semplice ed efficiente: due sottoscrizioni si dicono simili se esse si riferiscono allo stesso topic. In questo modo quindi, possiamo avere due casi: o le sottoscrizioni non sono simili perché si riferiscono a diversi topic, oppure sono perfettamente simili, in quanto si riferiscono allo stesso topic. Come è mostrato in figura 2.6, TERA implementa una overlay a due livelli: il primo livello è costituito da una overlay generale a cui appartengono tutti i client del sistema Publish-Subscribe, ed è qui che viene effettuata la prima fase del processo di diffusione di un evento (in TERA anche le sottoscrizioni vengono diffuse in questa overlay), tramite un cammino random nel grafo costituito dai 24

29 Capitolo2: I sistemi Publish-Subscribe nodi della overlay; il secondo livello è costituito invece da una serie di overlay, una per ogni cluster di similarità, ed è qui che avviene la seconda fase del processo di diffusione di un evento, diffondendo l evento in tutti i client della cluster overlay che copre l evento. Figura 2.6: Architettura di TERA Elvin Elvin [15, 16] è un prototipo avanzato di sistema Publish-Subscribe contentbased. La sua caratteristica principale è un meccanismo, chiamato di quenching, usato dai publisher per ridurre il numero di notifiche generato; in base a questo meccanismo ciascun publisher può interrogare il sistema per ottenere una rappresentazione degli interessi espressi dai subscriber; sulla base di questa rappresentazione il publisher può quindi stabilire quali eventi devono essere notificati e quali invece possono essere scartati, in quanto non sarebbero di interesse per nessun subscriber. Il problema generato da questo metodo è dato dal fatto che, quando un publisher abilita il quenching su di un server, questi girerà su di lui l intero database delle sottoscrizioni per ogni singolo cambio di sottoscrizione, generando una notevole quantità di traffico Gryphon Gryphon [17] è un implementazione del modello Publish-Subscribe realizzata dalla IBM. Esso implementa sia un meccanismo di selezione delle notifiche basato su topic sia un più complesso content-based. Il sistema è composto da 25

30 Capitolo2: I sistemi Publish-Subscribe una serie di broker (architettura multi broker) suddivisi in cluster detti celle ; ciascuna cella copre una limitata area geografica ed, all interno di questa, offre un servizio scalabile e tollerante ai guasti; per ottenere una maggiore copertura geografica, più celle possono essere connesse tramite un numero arbitrario di link, in modo da garantire che la rete rimanga sempre connessa; eventuali cicli all interno della rete vengono gestiti dai protocolli interni a Gryphon. Oltre a queste caratteristiche Gryphon implementa anche diversi sistemi di sicurezza che ne permettono l uso anche su reti pubbliche SIENA Siena [10, 18] è un ENS distribuito con content-based routing. La grande novità introdotta da Siena consiste in un meccanismo, chiamato di covering delle sottoscrizioni che permette di ridurre la quantità di sottoscrizioni che il sistema deve inoltrare sulla rete per poi poter effettuare un corretto routing delle notifiche. Oltre a questo Siena introduce anche il concetto di Advertising delle pubblicazioni tramite cui i publisher possono annunciare in anticipo il tipo di eventi che intendono pubblicare sulla rete. Queste due caratteristiche permettono di tagliare parti della rete che costituisce l ENS (che deve avere obbligatoriamente una topologia aciclica) dalla propagazione di certi eventi in quanto, le informazioni ottenute dalle sottoscrizioni e dagli advertisement delle pubblicazioni, garantiscono che tali rami non contengono subscriber interessati. Il concetto di advertisement di una pubblicazione introdotto da questo sistema, sarà ripreso nel terzo capitolo, in quanto risulta un elemento fondamentale per il sistema sviluppato in questo lavoro di tesi JEDI JEDI [19] è un implementazione del modello Publish-Subscribe con contentbased routing sviluppata presso il Politecnico di Milano. 26

31 Capitolo2: I sistemi Publish-Subscribe L ENS fornito da JEDI è distribuito: esso è composto da un numero variabile di nodi connessi in modo da formare una gerarchia alla cui sommità risiede un nodo radice. Il funzionamento prevede una diffusione parziale delle sottoscrizioni dai nodi che le hanno ricevute fino alla radice. Queste informazioni vengono poi usate per evitare di dover distribuire le notifiche su tutta la rete Hermes Hermes offre un architettura molto simile a quella già vista con SCRIBE; si tratta quindi di un ENS distribuito sviluppato su un infrastruttura offerta da una overlay network [20, 21, 22] sottostante. Ciò che distingue Hermes da SCRIBE è l implementazione di una tipologia di routing misto basata sia sull utilizzo di un topic per gli eventi (chiamato in questo caso tipo ), sia sul contenuto degli eventi stessi. La parte di filtering degli eventi basato sul loro contenuto, trae forte ispirazione dal lavoro svolto con Siena REBECA REBECA [23] è un prototipo di sistema Publish-Subscribe realizzato nell ambito di un lavoro per una tesi di dottorato. Anche in questo caso il routing degli eventi è basato sul loro contenuto. La caratteristica più interessante di REBECA è quella di permettere l uso di diversi tipi di routing delle sottoscrizioni per poter analizzare le loro prestazioni; a seconda dell algoritmo scelto vengono sfruttati vari gradi di similarità tra le sottoscrizioni per ridurre il traffico dovuto alla loro diffusione all interno dell ENS. 27

32 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 3 Trasformare un sistema topic-based in content-based 3.1 Introduzione al problema L obiettivo di questo lavoro di tesi è realizzare, in modo efficiente, un sistema Publish-Subscribe basato su contenuti, che offra quindi la possibilità di esprimere, attraverso le sottoscrizioni, interessi verso particolari contenuti. Diversamente da quanto accade nei sistemi basati su topic quindi, in cui si possono esprimere solo interessi verso interi argomenti, indipendentemente dai contenuti di un singolo evento, e dove il modello dei dati è rappresentato da un insieme discreto di argomenti, i topic, in un sistema basato su contenuti, possiamo immaginare l insieme totale degli eventi come uno spazio continuo multidimensionale, in cui ogni dimensione rappresenta un attributo, mentre una sottoscrizione, definita attraverso un insieme di vincoli sui valori degli attributi, e cioè sui contenuti, individua un particolare sottospazio nel quale ricadono gli eventi di interesse. La figura 3.1 mostra la differenza tra i due Figura 3.1: a sinistra il modello content-based; a destra il modello topic-based 28

33 Capitolo 3: Trasformare un sistema topic-based in content-based modelli: un modello content-based tridimensionale di esempio con alcune sottoscrizioni, ed un insieme discreto di topic. In letteratura troviamo molte implementazioni di sistemi Publish-Subscribe content-based: da sistemi basati su algoritmi e tabelle di instradamento degli eventi di livello applicativo, come SIENA [1], a sistemi basati su reti P2P strutturate, usate per ottimizzare l instradamento degli eventi [2][3]. La soluzione innovativa che abbiamo deciso di sviluppare in questo lavoro di tesi, per l implementazione di un sistema content-based scalabile ed efficiente, è basata sull idea di non realizzare quest ultimo da zero, bensì di cercare di sfruttare l efficienza che riescono ad ottenere i sistemi topic-based nell instradare gli eventi: data la semplicità del modello dei dati, in tali sistemi in pratica si instaura un semplice canale, il topic, tra i pubblicatori ed i sottoscrittori nel quale viaggiano gli eventi. L idea, quindi, è quella di realizzare un sistema content-based costruito al di sopra di un generico sistema topic-based: in altre parole, l obiettivo è quello di realizzare un sistema content-based che utilizzi come livello di instradamento dei messaggi un sistema topic-based, in modo da sfruttare l efficienza di quest ultimo e, allo stesso tempo, fornire un interfaccia utente caratterizzata da una elevata potenza espressiva per la definizione delle sottoscrizioni, tipica dei sistemi basati su contenuti. Tale concetto è schematizzato nella figura 3.2: il sistema offre un interfaccia contentbased e, attraverso il Mapping Layer, cuore del sistema, riesce a capire, per ogni evento appartenente allo spazio multidimensionale, su quale topic inoltrarlo; dopodiché sarà compito del sistema topic-based sottostante inviare gli eventi. L MPL, punto fondamentale di questa tesi, sarà presentato in ogni dettaglio nel paragrafo 3.2. Figura 3.2: Architettura a livelli del sistema 29

34 Capitolo 3: Trasformare un sistema topic-based in content-based Da quanto appena detto, risulta evidente che l obiettivo principale di questa tesi è quello di sviluppare lo strato intermedio, l MPL, il cui scopo è quello di realizzare un mapping tra lo spazio continuo multidimensionale che caratterizza i sistemi content-based, e il mondo discreto su cui si basano i sistemi topic-based. La figura seguente (3.3) illustra quanto detto: il Mapping Module, contenuto nel Mapping Layer, dovrà riuscire a determinare, per ogni evento, ovvero per ogni punto dello spazio multidimensionale, qual è il topic responsabile dell instradamento del particolare evento, in modo da poter poi inoltrare il messaggio nel sistema topic-based sottostante. Figura 3.3: Mapping tra uno spazio continuo ed un insieme discreto di topic Adottando tale modulo, essendo in grado di mappare un qualsiasi spazio continuo multidimensionale in un generico insieme discreto e finito di elementi, saremo in grado, nello specifico, di trasformare un qualsiasi sistema Publish- Subscribe basato su topic in un sistema content-based o, in altre parole, saremo in grado di costruire un sistema Publish-Subscribe content-based partendo da un qualsiasi sistema topic-based. Concludendo, quindi, il sistema complessivo sarà caratterizzato, rispetto al sistema topic-based sottostante, da una maggiore potenza espressiva per la definizione delle sottoscrizioni, e dalla stessa efficienza per l instradamento degli eventi. 30

35 Capitolo 3: Trasformare un sistema topic-based in content-based Nel paragrafo successivo sarà mostrato in dettaglio il livello di mapping, descrivendo come viene realizzata l associazione biunivoca tra spazio continuo e topic e quali strutture ausiliare usa; viene inoltre introdotto il problema dei falsi positivi e come esso viene sfruttato nel modo migliore da un modulo di retroazione per migliorare le prestazioni. 3.2 Una corrispondenza dinamica tra spazi continui ed insiemi discreti Come abbiamo capito dal paragrafo precedente, per realizzare un sistema content-based che sfrutti come livello di instradamento dei messaggi un sistema topic-based è necessario realizzare una corrispondenza biunivoca tra i modelli dei dati dei due sistemi, e cioè tra uno spazio continuo multidimensionale ed un insieme discreto di topic. Tale corrispondenza, basata sulla discretizzazione dello spazio continuo, può essere principalmente di due tipi: statica o dinamica. Il primo tipo prevede una discretizzazione dell intero spazio degli eventi fatta a priori, indipendentemente dalla distribuzione delle sottoscrizioni e degli eventi, come possiamo vedere in figura 3.4. Un esempio in cui è stata adottata tale soluzione è presentato in [2]: in tale articolo gli autori sfruttano una overlay strutturata per assegnare staticamente ad ogni nodo della overlay un particolare sottospazio. Figura 3.4: Discretizzazione statica dello spazio degli eventi. 31

36 Capitolo 3: Trasformare un sistema topic-based in content-based Il secondo tipo, invece, prevede una discretizzazione che si adatta alla distribuzione delle sottoscrizioni e degli eventi, in modo da ridurre al minimo il problema dei falsi positivi (vedi paragrafo 3.2.3). Da questa prima e breve analisi possiamo intravedere vantaggi e svantaggi delle due soluzioni: con una discretizzazione statica, e quindi indipendente da una particolare distribuzione di eventi e sottoscrizioni, abbiamo che il numero di falsi positivi rimane costante; invece, nel caso di discretizzazione dinamica, abbiamo che il numero di falsi positivi diminuisce nel tempo, al costo però di introdurre overhead per la gestione della discretizzazione. Dato che un sistema a discretizzazione statica è già presente in letteratura e, volendo ridurre al minimo i falsi positivi che un utente riceve, in questo lavoro di tesi abbiamo scelto di realizzare un sistema a discretizzazione dinamica. Nel corso di questo paragrafo vedremo il Mapping Layer in tutti i suoi dettagli, responsabile della corrispondenza biunivoca dinamica tra lo spazio degli eventi del sistema content-based e l insieme discreto di topic del sistema topic-based. Nel capitolo 4, invece, sarà approfondita l analisi accennata precedentemente, e basandoci su risultati di simulazione, capiremo quando e quanto è conveniente utilizzare un sistema a discretizzazione dinamica piuttosto che un sistema a discretizzazione statica Discretizzare lo spazio continuo multidimensionale. Dunque, la strada che abbiamo deciso di percorrere è quella di realizzare un sistema a discretizzazione dinamica, che crei quindi, quando necessario, le dovute associazioni tra sottospazi e topic. L immagine precedente (figura 3.4) rimane valida in un sistema dinamico, solo che i vari sottospazi, e i relativi topic, anziché essere prestabiliti, vengono creati dinamicamente dal Mapping Layer, in base alle richieste dell utente, e soprattutto in base alla distribuzione degli eventi. Vedremo a breve infatti, che in base alle frequenze di ricezione degli eventi, il sistema reagirà in modo opportuno cambiando lo stato della discretizzazione, sia introducendo nuovi sottospazi di minor dimensione, sia unendo più sottospazi in uno equivalente. 32

37 Capitolo 3: Trasformare un sistema topic-based in content-based Nel nostro modello, la discretizzazione dello spazio degli eventi è rappresentata da un albero, il Discretization Tree (DT) in cui valgono le seguenti proprietà: Il nodo radice rappresenta l intero spazio degli eventi. Ogni nodo dell albero rappresenta un particolare sottospazio. I figli di un nodo p rappresentano un livello successivo di discretizzazione del sottospazio rappresentato da p. Gli unici sottospazi in cui si possono effettuare sottoscrizioni sono quelli rappresentati dai nodi foglia dell albero (se fosse possibile sottoscriversi anche a nodi di livello superiore, una pubblicazione in un nodo foglia dovrebbe essere ripetuta per tutti i nodi sul percorso dal nodo foglia fino alla radice). Per spiegare meglio il DT e la sua associazione allo spazio degli eventi, consideriamo un esempio in cui abbiamo uno spazio bidimensionale costituito dagli attributi x e y: in figura 3.5 possiamo vedere un esempio di discretizzazione effettuata sullo spazio S e il relativo Discretization Tree, dove, ad ogni discretizzazione, il sottospazio è diviso in due sottospazi utilizzando una dimensione come pivot della discretizzazione (quella indicata tra parentesi nei nodi del DT). Figura 3.5: un esempio di discretizzazione di uno spazio bidimensionale S ed il relativo albero DT 33

38 Capitolo 3: Trasformare un sistema topic-based in content-based Come si può immaginare dalla figura precedente (3.5), ogni passo di discretizzazione avviene su una sola dimensione, scelta in modo da ridurre il più possibile il numero di falsi positivi che ricadono nel sottospazio che si sta discretizzando (vedi paragrafo per ulteriori dettagli). Inoltre, un altro fattore importante che regola la discretizzazione di un sottospazio è la cardinalit{ di quest ultima, ovvero il numero di sottospazi figli da generare: più è alto questo numero, più è alta la probabilità di eliminare i falsi positivi con un unica discretizzazione, introducendo però maggiore complessit{ nel sistema. Come possiamo immaginare, il DT avrà una struttura che cambia nel tempo, regolata dal Mapping Module: in base alla distribuzione degli eventi e delle sottoscrizioni, il modulo decide se discretizzare o meno un sottospazio, e se eliminare o meno una discretizzazione presente, cioè un sottoalbero di altezza unitaria, perché non più necessaria (anche in questo caso si rimanda al paragrafo per ulteriori dettagli). Infine, lo stato iniziale può cambiare da contesto a contesto: così come possiamo avere un semplice stato iniziale costituito solo dal nodo radice, il che significa non avere discretizzazione, potremmo avere uno stato iniziale costituito da più livelli di discretizzazione. Ad esempio, possiamo considerare come stato iniziale il nodo radice ed i suoi figli: ciò significa che, appena avviato, il sistema ha già un primo livello di discretizzazione. In base ai principi di funzionamento del MPL (vedi paragrafo 3.3 per approfondimenti), questa configurazione può portare, in alcuni scenari, a miglioramenti delle prestazioni. A questo punto, per completare il mapping tra spazio continuo e topic, è sufficiente associare ad ogni nodo dell albero un topic. Tuttavia, questo non significa che il Discretization Tree rappresenta l insieme dei topic attualmente esistenti nel sistema, bensì esso rappresenta soltanto lo stato logico della discretizzazione dello spazio degli eventi. In altre parole, l insieme dei nodi del DT rappresenta l insieme dei possibili topic su cui è possibile effettuare operazioni di sottoscrizione, pubblicazione, ecc. Solo quando una sottoscrizione ad un topic viene richiesta per la prima volta, quest ultimo viene effettivamente 34

39 Capitolo 3: Trasformare un sistema topic-based in content-based creato ed associato ad un nodo dell albero. Più formalmente possiamo affermare che il Mapping Layer realizza una prima corrispondenza biunivoca tra lo spazio degli eventi e l insieme dei nodi dell albero, ed una seconda corrispondenza biunivoca tra un sottoinsieme dei nodi dell albero e l insieme dei topic (figura 3): solo quando un sottospazio diventa di interesse per qualche sottoscrittore, allora il nodo associato entra a far parte del dominio della seconda corrispondenza, e quindi associato ad un topic L albero di Sistema (ST) Una volta definita la corrispondenza tra spazio degli eventi e topic, si rende necessaria la definizione di una serie di protocolli indispensabili per il corretto funzionamento del sistema, uno fra tutti il protocollo per la gestione della discretizzazione. Essendo questo un sistema distribuito, tali protocolli si baseranno sullo scambio di messaggi e, volendo rimanere completamente disaccoppiati dal livello di rete sottostante, abbiamo deciso di utilizzare il sistema topic-based anche per le comunicazioni di sistema. Tuttavia, per non sovraccaricare i topic utente, e soprattutto, per rendere tali protocolli completamente trasparenti all utente, abbiamo deciso di separare i canali applicativi, in cui viaggeranno gli eventi dei pubblicatori, dai canali di sistema, in cui viaggeranno i messaggi dei protocolli. Per quanto riguarda i protocolli, oltre ad aver definito un protocollo di regolazione della discretizzazione, abbiamo definito una serie di protocolli che regolano il comportamento dell interfaccia Content-based offerta all utente per quanto riguarda l interfacciamento con il Mapping Layer. Pertanto, mentre il primo è il cuore del modulo di mapping, e quindi sarà trattato in questo paragrafo (sezione 3.2.4), gli altri saranno approfonditi nel paragrafo seguente (3.3). Concentriamoci adesso sul definire un canale alternativo per le comunicazioni di sistema. La soluzione adottata è quella di utilizzare un canale di sistema indipendente per ogni sottospazio: la scelta è giustificata dalla considerazione che ciò che riguarda un sottospazio è completamente indipendente da eventi esterni al 35

40 Capitolo 3: Trasformare un sistema topic-based in content-based sottospazio stesso. In questo modo siamo in grado di ridurre al minimo il numero di messaggi di servizio che circolano nel sistema, in quanto ogni nodo riceverà esclusivamente i messaggi di sistema associati ai sottospazi che coprono le sue sottoscrizioni. Questa soluzione si concretizza in un albero di sistema, il System Tree (ST), identico al Discretization Tree, con la differenza che i topic mappati con lo spazio degli eventi non serviranno per instradare messaggi applicativi, bensì messaggi di sistema. Una seconda e fondamentale differenza con il DT riguarda l insieme di topic a cui il sistema si sottoscrive: mentre nel caso del DT le sottoscrizioni riguardano solamente i nodi foglia dell albero, nel caso del ST, il sistema sottoscriverà tutti i topic associati ai nodi del ramo del ST che parte da un nodo foglia di interesse fino alla radice. Questo scelta, anche se può sembrare ridondante, è necessaria sia per poter costruire gli alberi DT e ST, sia per captare eventuali richieste di annullamento di qualche livello. In altre parole, quando un utente entra nel sistema, l unica parte dell albero che conosce è lo stato iniziale e, supponendo che questo sia composto solo dal nodo radice, l utente comincer{ ad inviare richieste di aggiornamento di stato dell albero utilizzando il topic associato alla radice del ST; secondo, tutte le comunicazioni relative alla eliminazione di un livello di discretizzazione dall albero non avvengono nei topic associati ai nodi foglia, bensì nel topic associato al nodo padre delle foglie che si ritiene non siano più necessarie. Quindi, risulta obbligatorio mantenere le sottoscrizioni a tutti quei topic associati ai nodi del ST del ramo che va da una foglia di interesse fino alla radice. Ulteriori dettagli sono descritti ed affrontati nei paragrafi successivi Il problema dei falsi positivi L ultimo problema da affrontare prima di passare alla definizione del livello più esterno del sistema, l interfaccia content-based, riguarda il fenomeno dei falsi positivi. Come ricordiamo, una sottoscrizione definisce un sottospazio nello spazio degli eventi (figura 3.1). In generale, la discretizzazione dello spazio degli eventi genera sottospazi che non coprono perfettamente le sottoscrizioni degli 36

41 Capitolo 3: Trasformare un sistema topic-based in content-based utenti, pertanto, accade frequentemente che un utente si sottoscriva ad uno o più topic, i quali includono regioni alle quali non è interessato. Di conseguenza, egli riceverà eventi esterni alle proprie sottoscrizioni: i falsi positivi. Formalmente, possiamo così definire l insieme dei falsi positivi relativi ad una sottoscrizione: Dato uno spazio degli eventi E ed una sottoscrizione S coperta dall insieme di sottospazi T, l insieme dei falsi positivi per una sottoscrizione S è: FP S = x E x T x S Come possiamo vedere nell esempio di figura 3.6, in cui abbiamo tre sottospazi associati a tre topic, la sottoscrizione SS1, essendo coperta da S1 e S2, si traduce in una sottoscrizione ai topic A e B. Perciò, tutti gli eventi che appartengono a S1 o S2, e non appartengono alla sottoscrizione SS1, sono dei potenziali falsi positivi per SS1. Figura 3.6: un esempio di sottoscrizione in una discretizzazione che genera elevati falsi positivi 37

42 Capitolo 3: Trasformare un sistema topic-based in content-based Data la natura del sistema, basata sulla discretizzazione di uno spazio continuo, tale problema non può essere eliminato, ma, gestendolo in maniera opportuna, lo si può sfruttare per migliorare le prestazioni complessive: nel nostro sistema, infatti, i falsi positivi sono il cardine della discretizzazione dinamica. Nel sottoparagrafo successivo viene descritto il protocollo di discretizzazione, il quale definisce il comportamento di un nodo del sistema, sia nello scenario in cui esso ritiene necessario un livello successivo di discretizzazione, perché riceve troppi falsi positivi, sia nello scenario duale, ovvero nel caso in cui il sistema, o meglio un sottoinsieme di nodi del sistema, ritiene necessario annullare un livello della discretizzazione I protocolli di discretizzazione dinamica Come anticipato nel sottoparagrafo precedente, i protocolli di discretizzazione regolano due scenari fondamentali di questo sistema: la creazione e l eliminazione di un livello di discretizzazione. Essi governano quindi la dinamicità del sistema. Quando creare un nuovo livello di discretizzazione? La risposta a questa domanda risulta immediata: dato che vogliamo ridurre il più possibile il numero di falsi positivi che un utente riceve, e dato che la probabilità di ricevere un falso positivo è direttamente proporzionale al rapporto tra le dimensioni di un sottospazio ed una sottoscrizione coperta da esso, un nodo decide di discretizzare il sottospazio, e cioè di ridurne le dimensioni, quando riceve troppi falsi positivi, o in altre parole, quando il sottospazio è così grande da generare un numero eccessivo di falsi positivi. Quindi, la creazione di un nuovo livello di discretizzazione si basa sul rapporto tra il numero di falsi positivi ed il numero totale di eventi ricevuti, cioè sulla percentuale di falsi positivi ricevuti: quando questa percentuale supera una determinata soglia stabilita dall utente, la quale rappresenta la percentuale massima di falsi positivi tollerati, il nodo decide di aggiungere un nuovo livello di discretizzazione agli alberi DT ed ST 38

43 Capitolo 3: Trasformare un sistema topic-based in content-based Formalmente possiamo così definire la condizione di discretizzazione: Dato un sottospazio T che contiene un insieme non vuoto di sottoscrizioni, e definiti i falsi positivi di un sottospazio come quegli eventi che risultano essere falsi positivi per tutte le sottoscrizioni contenute in esso: false positive T = x T subscription s in T, x FPs Quindi, data una soglia di discretizzazione, T deve essere discretizzato quando # T false positives > Discretization threshold # T true positives + # T false positives In particolare, ogni nodo utilizza una serie di contatori per memorizzare il numero di eventi ricevuti, sia falsi positivi che veri, in modo da poter controllare, ogni volta che arriva un nuovo evento, se la condizione precedente è soddisfatta, e quindi richiedere la discretizzazione. Entrando ancora di più nei dettagli, ogni nodo memorizza per ogni sottospazio a cui è sottoscritto, un contatore per i veri positivi ed una serie di contatori per i falsi positivi, uno globale al sottospazio e poi uno per ogni dimensione del modello dei dati, questo perché, come anticipato nel paragrafo 3.2.1, la discretizzazione viene effettuata su una sola dimensione, quella associata al contatore con il valore maggiore. Questo è ciò che deve implementare un attore del sistema di tipo subscriber, in quanto tali contatori sono necessari per controllare il superamento della soglia ed eventualmente scegliere la dimensione pivot per un nuovo livello. Per quanto riguarda un attore di tipo publisher invece, esso deve memorizzare gli eventi pubblicati in ogni nodo foglia, in quanto, come vedremo a breve, il protocollo inverso a quello di creazione di un nuovo livello, ovvero quello di controllo di necessit{ di un livello, si basa sull analisi della distribuzione passata degli eventi, distribuzione che viene appunto memorizzata dai publisher, per poi essere inviata ai subscriber ogni E secondi (E rappresenta la durata di un epoca, ovvero ogni quanti secondi viene avviato l algoritmo di controllo di 39

44 Capitolo 3: Trasformare un sistema topic-based in content-based necessità). Analizzeremo ora i due protocolli appena citati: il protocollo di creazione di un nuovo livello, costituito da due algoritmi, controllo soglia e creazione vera e propria di un nuovo livello, ed il protocollo per il controllo di necessità di un livello. Il protocollo che regola la creazione di un nuovo livello negli alberi DT e ST è basato sui due algoritmi seguenti: ALGORITMO 1 (controllo superamento soglia) ogni volta che un nodo riceve un evento e coperto dal sottospazio T: 1. a. Se e è un vero positivo, il nodo incrementa il singolo contatore associato al sottospazio T. b. Altrimenti, se e è un falso positivo di T, il nodo incrementa il contatore globale dei falsi positivi di T, e poi verifica, per ogni sottoscrizione contenuta in T, quali vincoli della sottoscrizione non sono soddisfatti, incrementando quindi solo i contatori associati alle dimensioni su cui non sono soddisfatti i vincoli. 2. Dopo aver aggiornato i contatori, il nodo verifica se la condizione di discretizzazione è soddisfatta. 3. In caso positivo, il nodo avvia il processo di discretizzazione del sottospazio in questione, inviando sul topic associato al nodo dell albero ST associato al sottospazio T un messaggio di richiesta di discretizzazione per il sottospazio T, indicando come dimensione pivot quella associata al contatore con valore maggiore. Analizzando l algoritmo appena descritto, ed in particolare focalizzandoci sul punto 1.b, possiamo notare che, per quanto riguarda i contatori di dimensione, un falso positivo viene contato tante volte quante sono le sottoscrizioni che non sono soddisfatte. In prima analisi, questo potrebbe sembrare un errore, in quanto un unico falso positivo potrebbe generare un incremento più che 40

45 Capitolo 3: Trasformare un sistema topic-based in content-based unitario dei contatori. In realtà questo incremento multiplo serve a tener traccia del fatto che, nonostante ci siano più sottoscrizioni in un sottospazio, e quindi una minore regione non coperta da sottoscrizioni, e quindi una minore probabilità di ricevere un falso positivo, il sistema ha comunque notificato un evento che è falso per più sottoscrizioni. Con questi incrementi multipli quindi, riusciamo a determinare con maggiore precisione su quale dimensione è necessario effettuare una discretizzazione in modo da ridurre il più possibile i falsi positivi del sottospazio. L algoritmo invece che viene attivato ogni volta che viene ricevuto un messaggio di richiesta di discretizzazione generato dall algoritmo precedente, e che crea un nuovo livello negli alberi DT ed ST è il seguente: ALGORITMO 2 (ricezione messaggio di richiesta di discretizzazione) ogni volta che un nodo riceve una richiesta di discretizzazione nel topic ST (topic di sistema associato al sottospazio T): 1. Si procede a realizzare il nuovo livello di discretizzazione creando negli alberi DT ed ST K nuovi figli (con K parametro di sistema) per i nodi del DT e del ST associati al sottospazio T. 2. Per ogni nuovo nodo di interesse, ovvero associato ad un sottospazio che copre almeno una sottoscrizione o un advertisement, si effettua la sottoscrizione al topic di sistema (quello associato all ST) e, se l attore che esegue l algoritmo è un subscriber, si effettua la sottoscrizione anche al topic dati (quello associato al DT) 3. Terminata l analisi sui nuovi figli, se l attore che esegue l algoritmo è un subscriber, si procede all annullamento della sottoscrizione al topic dati associato al nodo padre del DT appena discretizzato. 4. Una volta terminato il processo di discretizzazione, il sottospazio T è discretizzato in K sottospazi (dove K è un parametro di sistema), e se l attore che sta eseguendo l algoritmo è un publisher, allora esso trasferisce la 41

46 Capitolo 3: Trasformare un sistema topic-based in content-based distribuzione che aveva memorizzato per il nodo associato al sottospazio T ai nuovi figli, ovvero alle nuove foglie. Come possiamo vedere, la creazione di un nuovo livello risulta semplice da gestire: fondamentalmente è composta da due fasi distinte, l aggiornamento dei contatori, e la verifica della condizione di discretizzazione. Completamente differente, invece, è l eliminazione di un livello, che necessita di un analisi più complessa. Quando un livello di discretizzazione non è più necessario? Per rispondere a questa domanda possiamo percorrere a ritroso il processo che ha portato alla creazione di un nuovo livello e quindi chiederci: se annullassimo tale livello, qualche sottoscrittore chiederebbe nuovamente di discretizzare? Se la risposta è no, allora si può procedere all eliminazione. La soluzione adottata si basa quindi sull analisi della distribuzione degli eventi all interno del livello in questione, e su come essa sia percepita dai sottoscrittori interessati. In particolare, quando la distribuzione degli eventi è tale per cui il livello di discretizzazione non è più indispensabile per ogni singolo sottoscrittore coinvolto, allora si può procedere all eliminazione di questo livello di discretizzazione. In altre parole, un livello viene eliminato quando la nuova configurazione dell albero che si andrebbe a creare è tale per cui ogni sottoscrittore non riceverà un numero di falsi positivi tale da soddisfare la condizione di discretizzazione. L algoritmo di controllo, attivato ogni volta che scatta un timeout (parametro di configurazione del sistema), si basa su uno scambio di messaggi nei topic di sistema associati alle radici dei sottoalberi di altezza unitaria dell albero di sistema ST (ad esempio i nodi 1.2 e 2.2 in figura 5), il cui scopo è quello di far conoscere ai sottoscrittori la distribuzione degli eventi. 42

47 Capitolo 3: Trasformare un sistema topic-based in content-based Il protocollo di controllo della discretizzazione è il seguente: PROTOCOLLO 1 (CONTROLLO DI NECESSITA DI UN LIVELLO DI DISCRETIZZAZIONE) ogni E secondi (che rappresentano un epoca) 1. I pubblicatori inviano sui topic di sistema un messaggio contenente il numero di eventi pubblicati nei nodi foglia e attendono un tempo pari a 5t, dove t è un tempo stimato che indica il tempo massimo necessario per ricevere un messaggio. Scaduto questo tempo, i pubblicatori eseguono l ultimo passo dell algoritmo. 2. Se un nodo riceve un messaggio inviato da un pubblicatore al passo 1 contenente una distribuzione di eventi relativa ad un sottoalbero che per lui non è ad altezza unitaria, risponde immediatamente con un NOK e termina l algoritmo. 3. Quando un pubblicatore riceve un messaggio inviato al passo 1 da un altro pubblicatore e non ha ancora avviato l algoritmo, lo avvia immediatamente. Invece i sottoscrittori, alla ricezione del primo messaggio, attendono 2t prima di procedere al passo successivo, tempo sufficiente per ricevere da tutti gli altri pubblicatori coinvolti i messaggi contenenti le distribuzioni degli eventi. 4. Dopo il tempo 2t, i sottoscrittori, avendo a disposizione la distribuzione degli eventi corrente all interno dei sottospazi di altezza 1 (quelli con un solo livello di discretizzazione), controllano, per ogni sottospazio, se la soglia di discretizzazione è superata, considerando come veri positivi gli eventi pubblicati nelle foglie a cui sono sottoscritti, e come falsi positivi gli eventi nelle foglie rimanenti. Nel caso in cui la soglia non viene superata, il sottoscrittore invia un OK. 5. Dopo aver deciso, un sottoscrittore attende per altri 2t (tempo sufficiente per ricevere eventuali NOK del passo successivo). 43

48 Capitolo 3: Trasformare un sistema topic-based in content-based 6. Se un sottoscrittore che ha deciso per il no, perché la soglia è superata, riceve un OK, invia un NOK e termina l algoritmo. 7. Se un nodo riceve un NOK, termina l algoritmo. 8. Quando i pubblicatori ed i sottoscrittori superano rispettivamente i 5t del passo 1 ed i 2t del passo 4 senza ricevere NOK, questo può rappresentare due scenari differenti: a) Tutti i sottoscrittori che stanno eseguendo l algoritmo hanno deciso per il NO al passo 4 e quindi nessuno ha inviato un OK. In questo caso il livello non viene eliminato. b) Tutti i sottoscrittori hanno deciso per il SI al passo 4, quindi è stato inviato almeno un OK, il quale è stato ricevuto anche da tutti i pubblicatori coinvolti. In questo caso, tutti i nodi coinvolti procedono all eliminazione del livello in questione. Figura 3.7: un esempio di esecuzione dell algoritmo di controllo della discretizzazione Nell esempio di figura 3.7 abbiamo 5 nodi coinvolti: due pubblicatori, P1 e P2, e tre sottoscrittori, S1, S2 e S3. Nello scenario mostrato abbiamo che P1 invia il messaggio contenente gli eventi pubblicati, poi P2, non avendo ancora iniziato l algoritmo, quando riceve il messaggio da P1 inoltra anche la sua distribuzione. 44

49 Capitolo 3: Trasformare un sistema topic-based in content-based Dopo un periodo di tempo che va da 2t a 3t, a seconda di quando i sottoscrittori ricevono il primo messaggio, ogni sottoscrittore decide se per lui il livello può essere eliminato oppure no. A questo punto, il nodo S1 decide di si e quindi invia un OK. Quando S2, che ha deciso di no, riceve un OK, invia immediatamente un NOK e termina l esecuzione, così come terminano gli altri quattro nodi. Una precisazione importante da evidenziare, che riguarda l invio dei messaggi OK e NOK nell algoritmo precedente, e che influenza l overhead introdotto dal sistema, è la seguente: ogni nodo che deve inviare un OK o un NOK, programma l invio del messaggio posticipato di un ritardo random (tra 0 e 10), in modo tale che, se nell intervallo di tempo tra il momento della programmazione dell invio e l invio stesso, l esecutore dell algoritmo riceve un messaggio semanticamente uguale (un OK o un NOK per lo stesso nodo dell albero), allora annulla il suo invio, dato che qualcun altro ha già provveduto, inviando nello stesso topic lo stesso messaggio. Come si può capire da quanto detto fino ad ora, ogni nodo costituente il sistema Publish-Subscribe distribuito ha la necessità di conoscere lo stato degli alberi DT ed ST, almeno per quel che riguarda le porzioni di interesse, cioè quelle contenenti le foglie associate a sottospazi che coprono le proprie sottoscrizioni o advertisement. Data la completa distribuzione degli alberi DT ed ST che caratterizza il nostro sistema, il paragrafo successivo presenta le soluzioni adottate per garantire la consistenza tra le copie locali degli alberi che ogni nodo del sistema costruisce in base alle proprie necessità Garantire la consistenza degli alberi nel sistema distribuito Volendo realizzare un sistema totalmente distribuito, abbiamo deciso di non creare un unico nodo del sistema responsabile della gestione degli alberi, bensì di demandare tale responsabilità ad ogni nodo del sistema. Appare evidente quindi la necessità di creare un protocollo che garantisca che tutte le operazioni 45

50 Capitolo 3: Trasformare un sistema topic-based in content-based di modifica degli alberi vengano eseguite all unisono da tutti gli attori del sistema coinvolti. Le soluzioni che abbiamo realizzato si basano fondamentalmente sui principi di base del protocollo di commit a due fasi: prima di fare una modifica, l attore chiede a tutti gli altri interessati se anche loro possono procedere con la stessa modifica; nel caso affermativo, tutti procedono alla modifica (commit), altrimenti nessuno la effettua (abort). Trasportando questo concetto nel nostro sistema, ogni attore, quando vuole modificare il suo albero, lo notifica a tutti gli attori coinvolti; dopodiché o tutti effettuano questa modifica oppure nessuno. La prima cosa da fare per realizzare tale protocollo è capire quali sono le operazioni che vanno a modificare gli alberi: da quanto detto finora, appare evidente che le uniche operazioni sono quelle definite dai protocolli di discretizzazione, ovvero il protocollo di creazione di un nuovo livello (ALGORITMI 1 e 2) e quello di controllo di necessità di un livello (PROTOCOLLO 1). Il passo successivo è creare un meccanismo che abiliti ogni attore del sistema a decidere se può procedere o meno all esecuzione di una particolare operazione sull albero. Riprendendo quanto gi{ detto precedentemente nel paragrafo 3.2.2, ovvero che ogni sottospazio è indipendente da ogni altro, a meno che non ci sia una relazione padre-figlio, abbiamo deciso di creare un meccanismo di locking dell albero con una granularit{ del singolo nodo, ovvero del singolo sottospazio. Ogni volta che un algoritmo può portare alla modifica di un sottospazio, l algoritmo deve bloccare il nodo associato prima di procedere acquisendo il lock del nodo; se l algoritmo riesce ad acquisire il lock, allora procede, altrimenti termina. Creato il meccanismo di locking dell albero, vediamo come esso debba essere utilizzato dalle operazioni di modifica precedentemente individuate per garantire una continua consistenza tra gli alberi di ogni attore del sistema Publish-Subscribe distribuito. 46

51 Capitolo 3: Trasformare un sistema topic-based in content-based Per quanto riguarda la creazione di un nuovo livello, quando un attore riceve un evento, e conseguentemente decide di discretizzare (passo 3 dell algoritmo 1), prima di inviare il messaggio di discretizzazione al resto del sistema, deve acquisire il lock associato al nodo che vuole discretizzare. Se non riesce ad acquisire il lock, e questo significa che il nodo è bloccato da un altra operazione di modifica, l algoritmo 1 termina, altrimenti prosegue normalmente. Quando un attore invece riceve un messaggio di richiesta discretizzazione, prima di procedere (passo 1 dell algoritmo 2), prova ad acquisire il lock per il nodo associato alla richiesta. Se non riesce ad acquisire il lock, allora l attore invia un messaggio di abort sullo stesso topic dal quale ha ricevuto la richiesta. In questo modo tutti i nodi coinvolti in questa richiesta annullano il processo di discretizzazione, terminando l esecuzione dell algoritmo 2. Se invece l attore riesce ad acquisire il lock, prima di proseguire eseguendo il passo 1 dell algoritmo 2, attende un tempo pari a 2t, tempo necessario per ricevere eventuali abort da altri attori coinvolti. Apportando queste modifiche agli algoritmi 1 e 2, siamo sicuri che un operazione di discretizzazione o viene eseguita da tutti i nodi interessati oppure, se qualche nodo non è in grado di eseguire l operazione perché sta eseguendo altre operazioni sullo stesso nodo, non viene eseguita da nessuno. Per quanto riguarda invece il protocollo di controllo di necessità di un livello, sia i publisher, prima di eseguire il passo 1 dell algoritmo 3, sia i subscriber, quando ricevono il primo messaggio contenente la distribuzione degli eventi (passo 3 dell algoritmo 3), provano ad acquisire il lock su tutti i nodi del livello da controllare, sia tutte le foglie che il padre di queste ultime. Se un attore non riesce ad acquisire i lock su tutto il livello, invia un NOK per tale livello, facendo quindi abortire il controllo anche a tutti gli altri attori coinvolti. Se invece un attore riesce ad acquisire i lock su tutto il livello, allora il protocollo di controllo prosegue normalmente. In questo modo il controllo di un livello, o viene eseguito da tutti gli attori coinvolti, oppure, se qualche attore non può controllare il livello perché sta eseguendo altre operazioni sulle foglie, come ad 47

52 Capitolo 3: Trasformare un sistema topic-based in content-based esempio la creazione di un nuovo livello, il controllo non viene eseguito da nessun attore. Con l introduzione di un meccanismo di locking dei nodi e la modifica degli algoritmi precedentemente presentati, siamo quindi riusciti a realizzare un sistema completamente distribuito che mantiene nel tempo la consistenza tra le sue strutture dati, regolando i metodi di accesso ad esse. Con questo abbiamo terminato la presentazione del livello di mapping. Nel paragrafo successivo sarà presentato il livello più esterno dell architettura, responsabile della definizione dell interfaccia basata su contenuti. Vedremo inoltre come anche questo livello dovrà necessariamente interfacciarsi con il meccanismo appena presentato per continuare a garantire la consistenza tra gli alberi. 3.3 L interfaccia Content-Based L obiettivo del livello CBI è quello di implementare un interfaccia utente che sia conforme all interfaccia offerta dai sistemi Publish-Subscribe di tipo content-based. Data la natura di tali sistemi, le loro interfacce sono molto semplici: esse prevedono funzionalità per pubblicare eventi, effettuare e annullare sottoscrizioni e, in alcuni sistemi, come il nostro, annunciare la volontà di pubblicazione, cioè gli advertisement. Vedremo quindi, nel corso di questo paragrafo, come tali funzionalità siano implementate dal nostro sistema in modo da garantire la corretta interazione con il livello inferiore, l MPL. L intero livello si basa su una conoscenza parziale e distribuita dell albero di discretizzazione, e quindi dei topic su cui pubblicare o a cui sottoscriversi: vedremo infatti, che grazie alle sottoscrizioni e agli advertisements, sia i pubblicatori che i sottoscrittori riescono a ricostruire la porzione del DT di interesse, quella porzione che rappresenta il sottospazio degli eventi a cui sono interessati, sia perché vogliono ricevere eventi da quel sottospazio, sia perché pubblicheranno eventi in quel sottospazio. 48

53 Capitolo 3: Trasformare un sistema topic-based in content-based La pubblicazione di un evento La pubblicazione di un evento nel sistema è uno scenario molto semplice che viene anche velocizzato utilizzando gli advertisements: grazie a quest ultimi, un nodo pubblicatore conosce a priori quali sono i topic associati ai sottospazi che coprono gli eventi che pubblicherà. Quindi, ogni volta che un attore deve pubblicare un evento, basterà semplicemente cercare il nodo coprente nel DT e, se il nodo non è bloccato da qualche altra operazione (vedi paragrafo e 3.3.2), pubblicare l evento nel relativo topic Sottoscrizioni ed Advertisements Questi due scenari sono di fondamentale importanza per il sistema poiché costituiscono la base per la distribuzione degli alberi DT ed ST. I due scenari, molto simili, sono utilizzati, il primo dai sottoscrittori e il secondo dai pubblicatori, per conoscere quali sono i topic che coprono i sottospazi di interesse, per poi, nel caso dei sottoscrittori, effettuare la sottoscrizione a livello Topic. Siccome i due scenari sono molto simili, definiremo solo il protocollo che regola un nuovo advertisement; quello per una nuova sottoscrizione è identico, in più alla fine prevede la sottoscrizione ad i topic di interesse mappati dal DT. Dunque, il protocollo per una nuova sottoscrizione/advertisement è il seguente: PROTOCOLLO 2 (NUOVA SOTTOSCRIZIONE/ADVERTISEMENT) 1) Si prova ad acquisire il lock di tutti i nodi associati ai sottospazi che coprono la sottoscrizione/advertisement. a. Se vengono acquisiti tutti i lock, si procede con il passo 2. b. Altrimenti l operazione viene rimandata finché non si sbloccano tutti i nodi interessati. 2) Sottoscrizione a tutti i topic di sistema associati ai nodi di interesse controllati e bloccati al passo precedente. 3) Invio di una richiesta sui topic sottoscritti al punto 2 per conoscere eventuali livelli successivi di discretizzazione e sospensione per un tempo pari a 2t, tempo massimo per ricevere eventuali risposte. 49

54 Capitolo 3: Trasformare un sistema topic-based in content-based 4) Per ogni nodo coinvolto nei punti precedenti: a. Se almeno un nodo ha risposto, vuol dire che il sottospazio associato è discretizzato; quindi il nodo aggiorna la propria conoscenza degli alberi DT e ST aggiungendo un nuovo livello di discretizzazione ed usando come dimensione pivot quella indicata nella risposta; quindi ritorna al punto 2 usando i topic associati ai nodi di interesse appena costruiti. b. Altrimenti, se non è stata ricevuta alcuna risposta, vuol dire che il sottospazio non è ulteriormente discretizzato; quindi, per questo nodo, solo se l attore è un sottoscrittore, si procede alla sottoscrizione al topic dati associato, in modo da poter iniziare a riceve eventi. c. Se invece viene ricevuto un messaggio di wait, il processo di richiesta per il singolo nodo viene momentaneamente interrotto e ripreso solo quando viene ricevuta una risposta indicante lo stato attuale del nodo, sia se discretizzato sia se esso è un nodo foglia. d. Se invece viene ricevuto un messaggio di richiesta di discretizzazione, il processo interpreta questo messaggio come una risposta indicante che il nodo non è discretizzato e ora si richiede la sua discretizzazione; quindi viene terminato il processo di richiesta stato per il singolo nodo e viene immediatamente attivato il protocollo di richiesta discretizzazione per il nodo in questione, senza rilasciare il lock. In questo modo anche l attore corrente, appena diventato interessato al particolare sottospazio, entra a far parte del protocollo di discretizzazione per quest ultimo. Come possiamo vedere, questo algoritmo invia dei messaggi di richiesta stato per un nodo e attende eventuali risposte o riceve eventuali messaggi di wait, 50

55 Capitolo 3: Trasformare un sistema topic-based in content-based sempre relativi a singoli nodi. Vediamo come si comporta un nodo del sistema quando riceve un messaggio di richiesta stato per un nodo: ALGORITMO 4 (RICEZIONE DI UN MESSAGGIO RICHIESTA STATO PER UN NODO X) ogni volta che un attore del sistema riceve un messaggio di richiesta stato per un nodo X 1) Se il nodo è bloccato da un altra operazione, l attore invia un messaggio di wait, indicando che non può rispondere ora perché sta eseguendo altre operazioni sul nodo che potrebbero modificare lo stato del nodo. 2) Se il nodo non è bloccato e non è un nodo foglia, l attore invia un messaggio di risposta contenente un numero intero che indica la dimensione pivot della discretizzazione per quel nodo. 3) Altrimenti, se il nodo non è bloccato ma è un nodo foglia, l attore non fa nulla. Al termine del protocollo, il sottoscrittore o il pubblicatore, conosce la parte di albero che gli interessa e, nel caso di sottoscrittore, sarà sottoscritto ai topic di interesse; mentre nel caso di pubblicatore, conosce i nodi foglia del DT, ovvero i topic sui quali dovrà pubblicare. Un osservazione importante che garantisce il corretto funzionamento del protocollo appena descritto è che, mentre ogni sottoscrittore sarà sottoscritto solo a quei topic applicativi associati ai sottospazi foglia del DT, ogni nodo, sia i pubblicatori che i sottoscrittori, dovrà essere sottoscritto a tutti quei topic di sistema associati ai nodi dell albero ST che vanno dalla radice fino alle foglie di interesse. Altrimenti, se ogni nodo fosse sottoscritto solo ai topic di sistema associati ai nodi foglia del ST, come nel caso del DT per i sottoscrittori, alla prima esecuzione del punto 2 del protocollo, se fosse presente anche solo un livello di discretizzazione, non risponderebbe nessuno. 51

56 Capitolo 3: Trasformare un sistema topic-based in content-based Annullamento di sottoscrizioni ed advertisements Questi due scenari risultano estremamente semplici. Essi si basano sull idea di eliminare le sottoscrizioni ai topic associati ai nodi foglia dell albero DT, per quanto riguarda una unsubscribe, e tutte le sottoscrizioni ai topic associati all albero ST che non servono più, partendo dalle foglie coprenti fino ad arrivare a controllare anche la radice del ST, se necessario. In particolare vediamo ora i due algoritmi nei loro dettagli. Per quanto riguarda una sottoscrizione, l algoritmo di unsubscribe è il seguente: 1. Ricerca dei nodi del DT che coprono la sottoscrizione. 2. Per ogni nodo coprente, se esso non copre altre sottoscrizioni registrate precedentemente, allora: 2.1. Si effettua la unsubscribe al topic associato all albero DT Se il nodo non copre anche degli advertisements (se non fosse così significherebbe che chi esegue l algoritmo è sia un publisher che un subscriber): Si effettua la unsubscribe al topic associato all albero ST Per ogni livello dell albero, dal livello del nodo corrente, fino al livello 0, se i topic associati ai fratelli del nodo corrente del ST non sono sottoscritti: Si effettua la unsubscribe al topic associato al padre del nodo corrente dell albero ST e si ritorna al passo considerando come nodo corrente, il padre appena desottoscritto. Per quanto riguarda invece l annullamento di un advertisement, l algoritmo è molto simile: in pratica, dato che un publisher si sottoscrive solo ai topic associati ai nodi del ST, l algoritmo è identico al precedente tranne che per la 52

57 Capitolo 3: Trasformare un sistema topic-based in content-based prima parte, e cioè i punti 2 e 2.1, che sono inutili. Dunque, l algoritmo di annullamento di un advertisement è il seguente: 1. Ricerca dei nodi del ST che coprono gli advertisement. 2. Per ogni nodo coprente, se esso non copre altri advertisements registrati precedentemente, allora: 2.1. Si effettua la unsubscribe al topic associato all albero ST Per ogni livello dell albero, dal livello del nodo corrente, fino al livello 0, se i topic associati ai fratelli del nodo corrente del ST non sono sottoscritti: Si effettua la unsubscribe al topic associato al padre del nodo corrente dell albero ST e si ritorna al passo considerando come nodo corrente, il padre appena de-sottoscritto. Con questo abbiamo concluso la presentazione del Mapping Layer, il quale realizza una corrispondenze biunivoca dinamica tra un modello dei dati di un sistema content-based ed un insieme discreto di topic di un sistema topic-based. Nel capitolo successivo, sarà presentato l ambiente di simulazione utilizzato per testare il sistema appena descritto, ed infine saranno presentati e discussi i risultati ottenuti da una serie di simulazioni, il cui scopo è capire quando e quanto un sistema a discretizzazione dinamica convenga rispetto ad uno a discretizzazione statica. 53

58 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Capitolo 4 Test e risultati sperimentali 4.1 L ambiente di simulazione Dopo aver implementato un prototipo del sistema descritto nel capitolo precedente (per i dettagli implementativi si rimanda all appendice A), abbiamo dovuto scegliere un ambiente di simulazione che mettesse a disposizione un sistema Publish-Subscribe topic-based, in modo da poter testare le prestazioni del sistema sviluppato. La scelta è caduta su un simulatore del sistema TERA, realizzato da un altro tesista del nostro laboratorio (vedi paragrafo per i dettagli sul sistema TERA). Il simulatore è del tipo cycle-based, ciò significa che ogni passo di simulazione, cioè ogni round, è rappresentato da un ciclo effettuato su tutti i nodi costituenti lo scenario, durante il quale viene eseguito, nodo dopo nodo, il codice da simulare. Quando viene schedulato dal simulatore, ogni nodo esegue principalmente le tre attività dell elenco seguente, in questo ordine: 1) Gestione dei messaggi ricevuti. 2) Esecuzione di eventuale codice di scenario (publish, subscribe,...). 3) Esecuzione di eventuali thread virtuali in attesa di essere schedulati. Per quanto riguarda la terza attività, è bene chiarire che il flusso di esecuzione è sempre lo stesso, ed è unico: quello associato allo scheduler del simulatore. Per thread virtuale si intende invece un insieme di istruzioni che deve essere eseguito solo al verificarsi di una precisa condizione, ad esempio in risposta a determinati eventi, o dopo un certo numero di cicli. In altre parole, i thread virtuali consentono di creare un meccanismo event-based all interno di un simulatore cycle-based. 54

59 Capitolo 4: Test e risultati sperimentali A questo punto, scelto il simulatore, abbiamo integrato in esso il codice del prototipo implementato, trasformando quindi il sistema topic-based simulato, TERA, in un sistema content-based. Per quanto riguarda lo scenario di simulazione, esso è definito dalle seguenti proprietà: Lo spazio degli eventi è costituito da un solo attributo di tipo reale, definito nell intervallo [-500,500]. Il sistema Publish-Subscribe è costituito da 20 nodi, di cui 3 publisher e 7 subscriber. Il timeout di ricezione di un messaggio è impostato a 15 (numero massimo di cicli necessari al simulatore per consegnare un messaggio). Un epoca dura 400 cicli di simulazione (vedi paragrafo 3.2.4). Quindi, dopo aver configurato lo scenario con le proprietà suddette, per generare le sottoscrizioni, gli advertisement e gli eventi da pubblicare, sono state utilizzate le seguenti distribuzioni di probabilità: Quattro distribuzioni gaussiane, con varianza 0.5 e valore atteso scelto in modo uniforme sull intero spazio degli eventi, per scegliere i centri degli intervalli di sottoscrizione ed advertisement. Una distribuzione esponenziale negativa, con lambda=0.03, per determinare l ampiezza degli intervalli di sottoscrizione ed advertisement. Una distribuzione uniforme per ogni advertisement, in modo da scegliere con probabilità uniforme sull intero intervallo creato gli eventi da pubblicare. 55

60 Capitolo 4: Test e risultati sperimentali 4.2 I test effettuati Di seguito saranno mostrati i risultati ottenuti da una serie di simulazioni effettuate per misurare diverse grandezze del sistema. Un primo insieme di test è stato ideato e realizzato per analizzare i tempi di risposta del sistema, in modo da capire dopo quanto tempo il sistema va a regime, e come reagisce ad eventuali cambiamenti di sottoscrizioni e/o advertisement una volta raggiunto il regime. Un secondo insieme di test è stato ideato e realizzato per misurare l efficienza del sistema, confrontandolo con un sistema a discretizzazione statica. Infine, un terzo insieme di test è stato eseguito per analizzare il costo della discretizzazione dinamica, ovvero l overhead generato dalla gestione degli alberi di discretizzazione Analisi dei tempi di risposta del sistema In questo insieme di test si è studiato l andamento nel tempo del sistema, monitorando la grandezza falsi positivi/notifiche totali, ovvero la percentuale media di falsi positivi ricevuti da tutti i sottoscrittori. In particolare, si voleva capire quanto tempo fosse necessario al sistema per andare a regime, dove per regime intendiamo una fase in cui il valore monitorato rimane al di sotto di un valore di soglia scelto dall utente (la soglia di discretizzazione, cfr ), rappresentante la percentuale massima di falsi positivi tollerati. Secondo le caratteristiche del sistema, ci si aspetta che all aumentare della cardinalità della discretizzazione (da ora è il parametro K), il transitorio duri sempre meno, dato che un K maggiore produce sottospazi più piccoli, e quindi riduce la probabilità di ricevere falsi positivi. Per questo motivo, è stato eseguito un insieme di test per monitorare l andamento nel tempo del sistema (monitorando sempre la grandezza falsi positivi/notifiche totali) al variare di K, in modo da verificare se realmente esiste una relazione inversa tra questo parametro e la durata del transitorio. Nell eseguire questa serie di test, la soglia di discretizzazione (da ora r) è stata fissata ad un valore abbastanza basso,

61 Capitolo 4: Test e risultati sperimentali (10% di falsi positivi tollerati), in modo da testare il sistema in uno scenario non troppo favorevole. Sono ora riportati solo due dei grafici ottenuti, uno per K=2 e uno per K=9, in modo da mostrare l andamento del sistema nei due casi limite (nel prototipo realizzato il valore K [2,9] ). Analizzando i due grafici, vediamo che nel primo, ovvero con K=2, il sistema va a regime intorno al round 1000 quindi, considerando che il sistema parte al round 57

62 Capitolo 4: Test e risultati sperimentali 150, possiamo affermare che il sistema è andato a regime, in questo scenario, dopo 850 round; nel secondo grafico invece, ovvero con K=9, il sistema è andato a regime intorno al round 600, ovvero dopo 450 round. Quindi, da questi primi grafici, sembra effettivamente che esista una relazione inversa tra le due grandezze. Dopo aver eseguito altri test con altri valori di K, si è in effetti ottenuto il risultato atteso, come si può vedere dal grafico seguente. Come si può vedere dal grafico precedente, la relazione che lega le due grandezze sembra essere un esponenziale negativo con un asintoto orizzontale intorno al valore 400. Purtroppo non ci siamo potuti spingere oltre il valore 9 per analizzare meglio la relazione, date le limitazioni del prototipo implementato. Un ultimo test, sempre centrato sull analisi del sistema nel tempo, è stato effettuato per capire cosa accade quando, una volta che il sistema è a regime, cambia l insieme di sottoscrizioni e/o advertisement. Per eseguire questo test, al round 1300, sono state cambiate tutte le sottoscrizioni e gli advertisement, annullando le precedenti ed effettuandone delle nuove. 58

63 Capitolo 4: Test e risultati sperimentali Come si può vedere, il sistema reagisce e durante il nuovo transitorio, più breve rispetto al precedente (perché una parte degli alberi è già configurata), gli alberi vengono riconfigurati in modo da adattarsi ai nuovi intervalli di sottoscrizione ed advertisement, fino a raggiungere nuovamente il regime. Analizzando quindi i risultati ottenuti, si potrebbe immaginare di usare il valore massimo consentito per il parametro K in modo da minimizzare i tempi del transitorio. Vedremo con i prossimi test che un valore eccessivamente alto di K riduce l efficienza del sistema a discretizzazione dinamica, fino a renderlo meno performante di un sistema a discretizzazione statica Efficienza della discretizzazione dinamica Dopo l analisi del comportamento del sistema nel tempo, si è passati ad un insieme di test realizzati per confrontare la soluzione a discretizzazione dinamica, sviluppata in questo lavoro di tesi, con soluzioni a discretizzazione statica, già presenti in letteratura. Per poter confrontare i due tipi di soluzione, si è dovuto prima di tutto capire quali grandezze li accomunano: a differenza del nostro sistema, basato su discretizzazione dinamica dello spazio degli eventi, in un sistema a discretizzazione statica si ha semplicemente che lo spazio degli 59

64 Capitolo 4: Test e risultati sperimentali eventi è interamente discretizzato, che tale discretizzazione non cambia nel tempo, e che ogni sottospazio è responsabilità di un nodo del sistema. Appare evidente quindi, che un buon indicatore per un test comparativo tra i due sistemi è il numero medio di sottospazi sottoscritti da ogni sottoscrittore, dato che esso corrisponde, nei sistemi statici, ad una misura delle risorse utilizzate. Inoltre, tale grandezza fornisce anche una misura del carico che il nostro sistema introduce nel sistema topic-based sottostante. Una volta scelta la grandezza da monitorare, si è deciso di utilizzare come sistema statico il nostro stesso prototipo, settando come soglia di discretizzazione il valore 1 (cioè 100% di falsi positivi tollerati): in questo modo non si richiede mai la discretizzazione di un sottospazio, e viene disattivato il modulo che controlla la necessità di un livello di discretizzazione. Per quanto riguarda il sistema dinamico, esso è stato testato al variare della percentuale di falsi positivi tollerati (r), utilizzando due cardinalità di discretizzazione diverse (K=4 e K=6), monitorando sempre il numero medio di sottospazi sottoscritti da ogni sottoscrittore Invece, per il sistema statico, in cui non ha senso specificare la percentuale di falsi positivi tollerati dato che la discretizzazione non cambia, esso è stato testato mettendolo nelle condizioni di operare agli stessi livelli di qualità del sistema dinamico. In altre parole, per ogni valore v per il quale si è effettuato il test con il sistema dinamico (la percentuale di falsi tollerati), il sistema statico è stato testato creando manualmente una discretizzazione uniforme dell intero spazio degli eventi (dato che a priori non si conoscono le distribuzioni delle sottoscrizioni e degli eventi è necessariamente uniforme), tale da consentire al sistema di mantenere la percentuale di falsi positivi notificati al di sotto di v. Riassumendo, in questo test si è misurato quindi il numero medio di sottospazi sottoscritti da ogni sottoscrittore al variare della percentuale di falsi positivi tollerati, il che significa, per il sistema statico, effettuare la misurazione dopo aver creato, per ogni valore del test, una discretizzazione uniforme dello spazio 60

65 Capitolo 4: Test e risultati sperimentali degli eventi che garantisce tale valore. Il risultato dei test è mostrato nel grafico seguente: Come si può notare dal grafico, per valori bassi della percentuale (cioè per qualità richieste elevate), il sistema statico utilizza molti più sottospazi del sistema dinamico. Questo risultato si spiega considerando che per raggiungere gli stessi livelli di qualità del sistema dinamico, quello statico ha bisogno di una discretizzazione molto fitta e, a differenza del dinamico che crea granularità fine solo quando e dove è necessaria (vicino alle sottoscrizioni), il sistema statico è caratterizzato da una discretizzazione uniforme, cioè con granularità uguale sull intero spazio degli eventi. Questo implica, per il sistema statico, un elevato numero di sottospazi ed un alta probabilit{ che una sottoscrizione sia coperta da più sottospazi. Un secondo risultato interessante che si legge dal grafico precedente è l inversione delle prestazioni che si ottiene per percentuali alte (qualit{ richieste basse): dato che il sistema dinamico è legato al parametro K, esso comunque crea un numero minimo di sottospazi, mentre il sistema statico riesce a garantire gli stessi livelli di qualità utilizzando una discretizzazione uniforme meno granulare. 61

66 Capitolo 4: Test e risultati sperimentali Un ultimo interessante risultato da analizzare riguarda la relazione tra il valore misurato in questo test, e la cardinalit{ della discretizzazione K. All aumentare di K, chiaramente aumenta il numero di sottospazi generati dal sistema dinamico, e questo implica tempi di transitorio più brevi, come visto con i test precedenti, ma anche un incremento della probabilità che una sottoscrizione sia coperta da più sottospazi. Quindi, come possiamo vedere dall ultimo grafico, all aumentare di K, diminuisce l efficienza del sistema dinamico, in quanto aumenta il numero medio di topic sottoscritti. Infine, si può concludere questa importante analisi affermando quindi che valori bassi di K massimizzano l efficienza del sistema ma rendono il transitorio più lento, il che implica un numero maggiore di falsi positivi ricevuti; al contrario, valori alti di K rendono veloce il transitorio, quindi un numero minore di falsi positivi ricevuti, ma riducono l efficienza del sistema dinamico. Ne segue che, scelta la percentuale di falsi positivi tollerati, questa analisi aiuta a determinare il valore ottimale di K: se si vuole un valore basso della percentuale (cioè qualità elevata), come è più probabile che sia, il valore di K può anche essere scelto grande in modo da minimizzare i transitori, anche se questo implica utilizzare un numero maggiore di topic (numero che comunque rimane inferiore rispetto al sistema statico). Se invece ci si accontenta di percentuali maggiori (qualità inferiore), allora per continuare ad avere senso il sistema dinamico, il valore di K deve rimanere basso, in modo da non arrivare al punto di inversione di prestazioni tra statico e dinamico. 62

67 Capitolo 4: Test e risultati sperimentali Costo della discretizzazione dinamica Un ultima analisi è stata effettuata per capire quanto costa gestire la dinamicit{ della discretizzazione. In tale test è stata misurata la percentuale di messaggi di controllo inviati, rispetto al totale dei messaggi inviati. Anche in questo caso il test è stato eseguito al variare della percentuale di falsi positivi tollerati. Come era facile intuire, all aumentare della percentuale, siccome diminuisce la necessità di discretizzare, il numero di messaggi di controllo, ovvero quei messaggi inviati per gestire la discretizzazione, diminuisce. E interessante notare come anche nei casi critici, ovvero a percentuali basse, l overhead non supera il 5% del totale dei messaggi inviati. 63

68 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Conclusioni 5.1 I risultati ottenuti Abbiamo iniziato questo lavoro di tesi con un introduzione ai sistemi Publish-Subscribe (cfr. capitolo 2), in cui abbiamo evidenziato le differenze fra i meccanismi topic-based e content-based (cfr. 2.5); quindi abbiamo creato, nel capitolo 3, un meccanismo efficiente per l implementazione del modello content-based partendo da un generico meccanismo topic-based, trasformandolo in uno content-based. Nel quarto capitolo, infine, abbiamo presentato i risultati di una serie di test effettuati utilizzando un prototipo da me sviluppato (cfr. Appendice A) ed un simulatore del sistema TERA opportunamente modificato. Tali risultati dimostrano principalmente come un sistema a discretizzazione dinamica, grazie ad una granularità della discretizzazione non uniforme, ma che segue le distribuzioni delle sottoscrizioni e degli eventi, riesca ad essere quasi sempre più efficiente di un sistema a discretizzazione statica, riducendo il numero di sottospazi necessari a garantire un determinato livello di qualità. Inoltre, i test mostrano come l overhead introdotto per la gestione della discretizzazione dinamica sia relativamente contenuto, rimanendo sempre al di sotto del 5%. Possiamo concludere, quindi, affermando che il sistema Publish-Subscribe da noi sviluppato riesce ad essere più performante di sistemi statici, ad un costo decisamente accettabile. 64

69 Conclusioni 5.2 Sviluppi futuri Il prossimo passo da eseguire per continuare lo sviluppo ed il test di questo sistema, consiste nel cercare di eliminare i limiti introdotti dal prototipo utilizzato, purtroppo sviluppato rapidamente per motivi di tempo legati alla tesi. Una caratteristica che limita molto il sistema, infatti, è legata ad una proprietà del simulatore utilizzato: i nominativi dei topic sono dei numeri interi piuttosto che stringhe di caratteri. Questa caratteristica influenza due elementi fondamentali del nostro sistema, il quale deve necessariamente creare una corrispondenza biunivoca tra i nomi dei sottospazi, di tipo stringa, ed i nomi dei topic, di tipo intero: nel prototipo sviluppato la cardinalità della discretizzazione non può essere superiore a 9, e l altezza degli alberi di discretizzazione non può essere maggiore di 9, altrimenti l intero associato ai sottospazi foglia rischia di superare i valori massimi consentiti per il tipo intero. Superato questo limite, sarebbe interessante testare il sistema con valori alti di K. In un tale scenario, ci aspettiamo comunque, che aumentando K, la durata del transitorio si assesti su un valore minimo, che l efficienza continui a diminuire, e che i costi diminuiscano, anch essi assestandosi su un valore minimo. Inoltre, un altro test interessante da eseguire, sarebbe quello di analizzare la relazione tra il valore di K ed il valore di percentuale di falsi positivi tollerati dopo il quale si ha l inversione di prestazioni tra sistema statico e dinamico. Come si intravede dall analisi gi{ effettuata (cfr ), ci aspettiamo una relazione inversa tra le due grandezze, ovvero all aumentare della cardinalit{ di discretizzazione, l inversione di prestazioni dovrebbe avvenire dopo valori sempre più piccoli della percentuale di falsi positivi tollerati, fino ad assestarsi nell intorno di un asintoto orizzontale. Infine, uno sviluppo interessante sarebbe quello di modificare il prototipo sviluppato, in modo da disaccoppiarlo dal simulatore, per poi testarlo su un sistema topic-based reale, non simulato. 65

70 Un meccanismo efficiente per l implementazione del modello content-based Publish-Subscribe su sistemi topic-based Appendice A Implementazione del sistema In questa appendice sono mostrati i diagrammi dello schema XSD (XML Schema Definition) che definisce i parametri di input del sistema, ed i diagrammi delle classi del prototipo sviluppato per testare il meccanismo sviluppato in questo lavoro di tesi. In particolare, per ogni package sviluppato, è contenuta una breve descrizione delle funzionalità del package ed il diagramma delle classi contenute in esso. XML Schema Definition per i parametri di input del sistema Questo file XSD definisce le regole da rispettare per inserire i parametri di input del sistema. Gli elementi contenuti in DESMAType sono i parametri di input del sistema. Seguendo poi il diagramma, si capisce ogni singolo parametro di che tipo è. 66

71 Appendice A: Implementazione del sistema Package datamodel Questo package contiene tutte le classi che definiscono il modello dei dati di un sistema Publish-Subscribe. Si può infatti vedere la classe EventSpace, che rappresenta lo spazio degli eventi multidimensionale, e le classi che rappresentano attributi e sottoscrizioni (AttributeDef, Attribute, Subspace e Constraint). 67

72 Appendice A: Implementazione del sistema Package events Questo package contiene tutta la gerarchia di classi che definisce gli eventi che possono essere pubblicati. Possiamo vedere come da un interfaccia generale che rappresenta un evento, viene creato un tipo AppEvent che rappresenta gli eventi pubblicati dai publisher, e una gerarchia di SysEvent, che rappresenta i messaggi di controllo pubblicati dal sistema. 68

73 Appendice A: Implementazione del sistema Package exceptions Questo package contiene tutta la gerarchia di classi che definisce le eccezioni che possono essere lanciate dal sistema. In particolare, queste eccezioni servono a garantire che gli eventi che si vogliono pubblicare, e i sottospazi a cui ci si vuole sottoscrivere o fare advertisements, siano effettivamente contenuti nello spazio degli eventi del sistema. 69

74 Appendice A: Implementazione del sistema Package mapping Questo package rappresenta il cuore del sistema. In esso troviamo infatti implementato il livello CBI, ovvero l interfaccia content-based, ed il livello MPL, ovvero il livello che realizza il mapping dinamico tra spazi continui multidimensionali e insiemi discreti. 70

75 Appendice A: Implementazione del sistema Package threads Questo package contiene tutte quelle classi necessarie per implementare un meccanismo di esecuzione di codice basato su eventi. In altre parole, ogni classe di questo package rappresenta un insieme di istruzioni da eseguire solo in risposta ad un determinato evento, come la ricezione di un messaggio, o lo scadere di un timeout. Come si può vedere, le classi sono strutturate in una gerarchia in cui la classe padre, SimulatedThread, rappresenta la classe di interfacciamento con il simulatore; in questa classe infatti troviamo metodi come start(), run() e sleep(), i quali ovviamente rappresentano implementazioni simulate dei relativi metodi della classe Thread reale, la quale ribadisco, non viene mai usata, in quanto bisognava avere, per le simulazioni, un unico flusso di esecuzione. 71

76 Appendice A: Implementazione del sistema Package topicinterfacing Questo package contiene la gerarchia di classi necessaria per realizzare, nel modo più disaccoppiato possibile, l interfacciamento con il sistema topic-based sottostante. Possiamo notare infatti la classe TopicAPI, la quale rappresenta per il nostro sistema, la classe di interfacciamento con il sistema topic: essa infatti è una classe astratta che non implementa i metodi chiave di un sistema Publish- Subscribe, ovvero publish(), subscribe() e unsubscribe(), i quali poi devono essere implementati da una classe che estende TopicAPI. Dato che i nostri test sono stati effettuati utilizzando solo TERA come sistema topic-based, abbiamo implementato solo una classe di interfacciamento, TeraInterfacing, la quale sa come comunicare con il sistema topic-based. 72

Valutazione sperimentale di middleware pub/sub per reti wireless!

Valutazione sperimentale di middleware pub/sub per reti wireless! tesi di laurea! Valutazione sperimentale di middleware pub/sub per reti wireless! Anno Accademico 2009/2010! relatore! Ch.mo prof. Domenico Cotroneo! correlatore! Ing. Christiancarmine Esposito! candidato!

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D Introduzione Versioni al tratto Versione 3D Sistemi La versione negativa Distribuiti 3D prevede l utilizzo dell ombra esclusivamente sul fondo colore Rosso Sapienza. Laurea magistrale in ingegneria informatica

Dettagli

Architetture dei Sistemi Distribuiti

Architetture dei Sistemi Distribuiti Università degli tudi di Roma Tor Vergata Facoltà di Ingegneria Architetture dei istemi Distribuiti Corso di istemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Architettura sw di sistemi distribuito

Dettagli

Architetture software

Architetture software Corso di Laurea Magistrale in Ingegneria Informatica Corso di Ingegneria del A. A. 2013-2014 Architettura software 1 Architetture software Sommario Definizioni 2 Architettura Definizione. L architettura

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

Messaging (stile architetturale) e integrazione di applicazioni

Messaging (stile architetturale) e integrazione di applicazioni Luca Cabibbo Architetture Software Messaging (stile architetturale) e integrazione di applicazioni Dispensa ASW 430 ottobre 2014 Una specifica d interfaccia di buona qualità deve essere semplice, non ambigua,

Dettagli

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi C1_2 V3.3. Connettori

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi C1_2 V3.3. Connettori Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi C1_2 V3.3 Connettori Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per

Dettagli

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo tesi di laurea Analisi e sperimentazione della piattaforma Web Service Notification Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo Correlatore Ing. Christiancarmine Esposito candidato

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing

Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Un approccio innovativo per il delivery di servizi in infrastrutture di nomadic computing Relatore Prof. Ing. Stefano Russo Correlatore Ing. Domenico Cotroneo Candidato Armando Migliaccio matr. 41/2784

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

Analisi della dependability di un middleware per la

Analisi della dependability di un middleware per la tesi di laurea Analisi della dependability di un middleware per la distribuzione ib i dei dati conforme allo standard d OMG Anno Accademico 2005-2006 relatori Ch.mo prof. Stefano Russo Ch.mo prof. Domenico

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

Modelli di comunicazione

Modelli di comunicazione omunicazione End-to-end o Relayed UNIVERSIT DEGLI STUDI DI PRM Dipartimento di Ingegneria dell Informazione Luca Veltri (mail.to: luca.veltri@unipr.it) orso di Reti di Telecomunicazione, a.a. 0/0 http://www.tlc.unipr.it/veltri

Dettagli

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo La progettazione dell architettura si concentra sulla scelta dell hardware, dell infrastruttura di rete, e dei componenti software che andranno a costituire il sistema. Gli obbiettivi tecnologici che il

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico con Garanzie di Tempo ed Affidabilità

Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico con Garanzie di Tempo ed Affidabilità tesi di laurea Un Sistema per la Disseminazione Multipunto di Dati in Ambito Geografico Anno Accademico 2008/2009 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Christiancarmine Esposito candidato

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti:

Internet, così come ogni altra rete di calcolatori possiamo vederla suddivisa nei seguenti componenti: Pagina 1 di 8 Struttura di Internet ed il livello rete Indice Struttura delle reti Estremità della rete Il nucleo della rete Reti a commutazione di pacchetto e reti a commutazione di circuito Funzionalità

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine 1999 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright

Dettagli

Algoritmi per protocolli peer-to-peer

Algoritmi per protocolli peer-to-peer Algoritmi per protocolli peer-to-peer Introduzione Livio Torrero (livio.torrero@polito.it) 09/2009 Approccio client-server (1/2) Client 1 Client 3 Server Client 2 Client 4 Paradigma molto comune Un client

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Reti di Calcolatori IL LIVELLO RETE

Reti di Calcolatori IL LIVELLO RETE Reti di Calcolatori IL LIVELLO RETE D. Talia RETI DI CALCOLATORI - UNICAL 3-1 Il Livello RETE Servizi del livello Rete Organizzazione interna Livello Rete basato su Circuito Virtuale Livello Rete basato

Dettagli

CdLM Informatica (DM 270/2004) Sistemi Distribuiti. Publish Subscribe. Angelastro Sergio Diomede Antonio Viterbo Tommaso

CdLM Informatica (DM 270/2004) Sistemi Distribuiti. Publish Subscribe. Angelastro Sergio Diomede Antonio Viterbo Tommaso CdLM Informatica (DM 270/2004) Sistemi Distribuiti Publish Subscribe Angelastro Sergio Diomede Antonio Viterbo Tommaso Outline Messaging System Messaging Benefits Synchronous and Asynchronous Call Semantics

Dettagli

RETI DI CALCOLATORI Lucidi delle Lezioni Capitolo VIII

RETI DI CALCOLATORI Lucidi delle Lezioni Capitolo VIII Prof. Giuseppe F. Rossi E-mail: giuseppe.rossi@unipv.it Homepage: http://www.unipv.it/retical/home.html UNIVERSITA' DEGLI STUDI DI PAVIA A.A. 2011/12 - II Semestre RETI DI CALCOLATORI Lucidi delle Lezioni

Dettagli

Capitolo 16 I servizi Internet

Capitolo 16 I servizi Internet Capitolo 16 I servizi Internet Storia di Internet Il protocollo TCP/IP Indirizzi IP Intranet e indirizzi privati Nomi di dominio World Wide Web Ipertesti URL e HTTP Motori di ricerca Posta elettronica

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

Ingegneria del Software 13b. Viste. Dipartimento di Informatica Università di Pisa A.A. 2014/15

Ingegneria del Software 13b. Viste. Dipartimento di Informatica Università di Pisa A.A. 2014/15 Ingegneria del Software 13b. Viste Dipartimento di Informatica Università di Pisa A.A. 2014/15 viste in AS Una vista è la rappresentazione di un insieme di elementi del sistema e delle loro proprietà e

Dettagli

Publish/Subscribe Communication Infrastructures. Esercizi M I D L A B. Sistemi Distribuiti Leonardo Querzoni - 20/3/2007

Publish/Subscribe Communication Infrastructures. Esercizi M I D L A B. Sistemi Distribuiti Leonardo Querzoni - 20/3/2007 M I D L A B M i d d l ew a re L a b o r a t o r y Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica Publish/Subscribe Communication Infrastructures Esercizi Sistemi Distribuiti

Dettagli

Implementazione di tecniche di tolleranza ai guasti in un middleware per la Data Distribution Service

Implementazione di tecniche di tolleranza ai guasti in un middleware per la Data Distribution Service tesi di laurea Implementazione di tecniche di tolleranza ai guasti in un middleware per la Data Distribution Service Anno Accademico 2005/2006 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Ganna

Dettagli

Un framework per simulazione massiva distribuita basata su Agenti D-MASON: Architettura. Carmine Spagnuolo

Un framework per simulazione massiva distribuita basata su Agenti D-MASON: Architettura. Carmine Spagnuolo Un framework per simulazione massiva distribuita basata su Agenti D-MASON: Architettura Carmine Spagnuolo 1 Simulazione Multi-Agente Una simulazione multi-agente è un sistema in cui entità (agenti) intelligenti

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

Il funzionamento delle reti

Il funzionamento delle reti Il funzionamento delle reti La rete ci cambia la vita L Età dell Informazione ha prodotto profondi cambiamenti nessun luogo è remoto le persone sono interconnesse le relazioni sociali stanno mutando l

Dettagli

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

CORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci

CORSO DI RETI SSIS. Lezione n.2. 2 Novembre 2005 Laura Ricci CORSO DI RETI SSIS Lezione n.2. 2 Novembre 2005 Laura Ricci IL DOMAIN NAME SYSTEM (DNS) Indirizzi IP poco adatti per essere memorizzati da utenti umani è prevista la possibiltà di associare nomi simbolici

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Reti di calcolatori. Lezione del 10 giugno 2004

Reti di calcolatori. Lezione del 10 giugno 2004 Reti di calcolatori Lezione del 10 giugno 2004 Internetworking I livelli 1 fisico e 2 data link si occupano della connessione di due host direttamente connessi su di una rete omogenea Non è possibile estendere

Dettagli

Corso di Applicazioni Telematiche

Corso di Applicazioni Telematiche Corso di Applicazioni Telematiche Lezione n.1 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Obiettivi del corso Supporti didattici Modalità d esame Panoramica

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Il firewall Packet filtering statico in architetture avanzate

Il firewall Packet filtering statico in architetture avanzate protezione delle reti Il firewall Packet filtering statico in architetture avanzate FABIO GARZIA DOCENTE ESPERTO DI SECURITY UN FIREWALL PERIMETRALE È IL PUNTO CENTRALE DI DIFESA NEL PERIMETRO DI UNA RETE

Dettagli

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna Progetto RE.VE.N.GE. DDS con Fault-tolerance del Sistema di Consegna Progetto di: Marco Livini, Luca Nardelli, Christian Pinto Reti di Calcolatori LS 08-09 Prof. Antonio Corradi, Ing. Luca Foschini Relazione

Dettagli

Modelli di comunicazione. Modelli di comunicazione. o Relayed. Comunicazione End-to. Comunicazione Unicast,, Multicast, Broadcast.

Modelli di comunicazione. Modelli di comunicazione. o Relayed. Comunicazione End-to. Comunicazione Unicast,, Multicast, Broadcast. omunicazione End-to to-end o Relayed Luca Veltri (mail.to: luca.veltri@.veltri@unipr.it) orso di Reti di Telecomunicazione, a.a. 0/0 http:// ://www.tlc.unipr unipr.it/veltri omunicazione end-to-end quando

Dettagli

Programmazione modulare 2014-2015

Programmazione modulare 2014-2015 Programmazione modulare 2014-2015 Indirizzo: Informatica Disciplina: SISTEMI E RETI Classe: 5 A e 5 B Docente: Buscemi Letizia Ore settimanali previste: 4 ore (2 teoria + 2 laboratorio) Totale ore previste:

Dettagli

Organizzazione del testo

Organizzazione del testo Questo testo è un introduzione allo standard CORBA (Common Object Request Broker Architecture) e all architettura di riferimento OMA (Object Management Architecture), per lo sviluppo di sistemi software

Dettagli

Sistemi Distribuiti Introduzione al corso

Sistemi Distribuiti Introduzione al corso Altri testi di consultazione Sistemi Distribuiti Introduzione al corso Testo di riferimento G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE Definizione di un'architettura client/server basata su SNMP per il monitoraggio del traffico che passa attraverso n router utilizzati per connettere un'azienda ad Internet. Negro Giulio Del Mutolo Nicola

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

CdL MAGISTRALE in INFORMATICA

CdL MAGISTRALE in INFORMATICA 05/11/14 CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di SISTEMI DISTRIBUITI 7. I processi : il naming Prof. S.Pizzutilo Il naming dei processi Nome = stringa di bit o di caratteri utilizzata per

Dettagli

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: Reti di computer ed Internet nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

Reti di computer ed Internet

Reti di computer ed Internet Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

Distributed P2P Data Mining. Autore: Elia Gaglio (matricola n 809477) Corso di Sistemi Distribuiti Prof.ssa Simonetta Balsamo

Distributed P2P Data Mining. Autore: Elia Gaglio (matricola n 809477) Corso di Sistemi Distribuiti Prof.ssa Simonetta Balsamo Distributed P2P Data Mining Autore: (matricola n 809477) Corso di Sistemi Distribuiti Prof.ssa Simonetta Balsamo A.A. 2005/2006 Il settore del Data Mining Distribuito (DDM): Data Mining: cuore del processo

Dettagli

5. Internetworking L2/L3

5. Internetworking L2/L3 Università di Genova Facoltà di Ingegneria Reti di Telecomunicazioni e Telemedicina 1 5. Internetworking L2/L3 Prof. Raffaele Bolla dist! Sia l esistenza (almeno nella fase iniziale) di tecnologie diverse,

Dettagli

Fondamenti di routing (pag.34)

Fondamenti di routing (pag.34) Fondamenti di routing (pag.34) UdA2L1 Il livello di rete (Network layer) è il livello 3 della pila ISO/OSI. Questo livello riceve datagrammi (pacchetti) dal livello di trasporto e forma pacchetti che vengono

Dettagli

Modulo 8 Ethernet Switching

Modulo 8 Ethernet Switching Modulo 8 Ethernet Switching 8.1 Ethernet Switching 8.1.1 Bridging a livello 2 Aumentando il numero di nodi su un singolo segmento aumenta la probabilità di avere collisioni e quindi ritrasmissioni. Una

Dettagli

Elementi di Reti per Telecomunicazioni

Elementi di Reti per Telecomunicazioni Elementi di Reti per Telecomunicazioni (Parte II) Topologie ed Interfacciamento di Reti Corso di Telecomunicazioni Anno Accademico 2004/2005 Contenuti Introduzione alle reti di TLC. Topologie di Reti per

Dettagli

Corso Web programming

Corso Web programming Corso Web programming Modulo T3 A1 Modelli di programmazione 1 Prerequisiti Concetto di rete Processi e thread Concetti generali sui database 2 1 Introduzione Un particolare ambito della programmazione

Dettagli

Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema. Dal livello A al livello B

Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema. Dal livello A al livello B Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema contenuto della comunicazione sistema per la gestione della comunicazione sottosistema C sottosistema B sottosistema A

Dettagli

Laboratorio di Informatica. Le reti telematiche e Internet

Laboratorio di Informatica. Le reti telematiche e Internet Le reti telematiche e Internet Lezione 6 1 Insieme di cavi, protocolli, apparati di rete che collegano tra loro computer distinti i cavi trasportano fisicamente le informazioni opportunamente codificate

Dettagli

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete IP Analizziamo con sufficiente dettaglio il sistema denominato IP, usato per consentire a due computer mobili di spostarsi liberamente in altre reti pur mantenendo lo stesso indirizzo IP. In particolare,

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli