Universit`a degli Studi di Roma “La Sapienza”

(1)

Universit` a degli Studi di Roma

“La Sapienza”

Facolt` a di Ingegneria

Tesi di Laurea in Ingegneria Informatica

sessione invernale - Maggio 2007

Studio di prestazioni di un sistema di diffusione delle

informazioni su larga scala

Fabio Falcinelli

Relatore: Prof. Roberto Baldoni Revisore: Prof. Silvio Salza

Co-relatore: Sirio Scipioni

(2)

ii

(3)

Indice

Introduzione 1

1 Middleware e sistemi distribuiti 3

1.1 Introduzione al Middleware . . . 3

1.2 Funzionalit`a offerte dal Middleware . . . 4

1.3 Sistemi distribuiti . . . 5

1.3.1 Vantaggi dei sistemi distribuiti . . . 5

2 Modello Publish/Subscribe 7 2.1 Modelli di sottoscrizione . . . 7

2.2 Modello architetturale . . . 8

2.2.1 Protocolli di rete (Network Protocols) . . . 9

2.2.2 Infrastruttura di overlay (Overlay Infrastructure) . . . 10

2.2.3 Indirizzamento degli eventi (Event Routing) . . . 12

2.2.4 Controllo degli eventi (Matching Algorithm) . . . 12

3 Real Time Innovations Data Distribution Service 13 3.1 QoS supportate . . . 15

3.2 Discovery . . . 18

3.3 Note sugli ambienti supportati . . . 18

4 PlanetLab 21 4.1 Architettura dei nodi PlanetLab . . . 23

4.2 Utilizzo di PlanetLab . . . 24

4.2.1 Installare RTI DDS su nodi PlanetLab . . . 25

5 Test di RTI Data Distribution Service utilizzando PlanetLab 27 5.1 Ambiente del test . . . 28

5.2 Parametri del test . . . 28

5.3 Prodotti del test . . . 28

5.4 Scrittura del programma di test . . . 29

5.4.1 Sviluppo del programma . . . 30

5.4.2 Logica del programma . . . 31 iii

(4)

iv INDICE

5.4.3 Implementazioni e scelte architetturali . . . 33

5.5 Come utilizzare il programma . . . 34

5.5.1 Opzioni configurabili da riga di comando . . . 35

6 Risultati dei test 39 6.1 Scala nazionale . . . 42

6.2 Scala europea . . . 47

6.3 Scala mondiale . . . 51

6.4 Frammentazione . . . 57

6.5 In dettaglio . . . 57

7 Conclusioni 59

(5)

Elenco delle figure

1.1 Struttura a livelli per applicazioni di rete distribuite . . . 4

2.1 Architettura a livelli di un sistema Publish/Subscribe . . . 9

3.1 Architettura di un’applicazione sviluppata su RTI DDS . . . 14

3.2 Schema concettuale di un sistema DCPS . . . 15

4.1 Distribuzione geografica dei nodi PlanetLab . . . 21

4.2 Architettura di un nodo . . . 23

5.1 Logica del programma di test NDDS testing . . . 32

5.2 Sequenza dei timestamp . . . 32

5.3 Architettura del programma di test . . . 34

6.1 Round-Trip Time medio su scala Italiana . . . 43

6.2 Perdite su scala Italiana . . . 43

6.3 Devianza standard su scala Italiana . . . 44

6.4 Round-Trip Time medio su scala Italiana, fino a 8192 byte . . . 45

6.5 Perdite su scala Italiana, fino a 8192 byte . . . 46

6.6 Devianza standard su scala Italiana, fino a 8192 byte . . . 46

6.7 Round-Trip Time medio su scala Europea . . . 48

6.8 Perdite su scala Europea . . . 49

6.9 Devianza standard su scala Europea . . . 49

6.10 Round-Trip Time medio su scala Europea, fino a 8192 bytes . . . 50

6.11 Perdite su scala Europea, fino a 8192 bytes . . . 51

6.12 Devianza standard su scala Europea, fino a 8192 bytes . . . 52

6.13 Round-Trip Time medio su scala planetaria . . . 53

6.14 Perdite di eventi su scala planetaria . . . 54

6.15 Devianza standard su scala planetaria . . . 55

6.16 Round-Trip Time medio su scala planetaria, fino a 8192 byte . . . 55

6.17 Perdite di eventi su scala planetaria, fino a 8192 byte . . . 56

6.18 Devianza standard su scala planetaria, fino a 8192 byte . . . 56

6.19 Perdita di eventi al variare del parametro fragSize . . . 57 v

(6)

vi ELENCO DELLE FIGURE

6.20 Perdite in best-effort con incrementi di 1024 byte . . . 58 6.21 Perdite in best-effort con incrementi di 512 byte . . . 58 7.1 Vista di un nodo sul quale girano contemporaneamente due applicazioni

RTI DDS . . . 61

(7)

Introduzione

A partire dai primi anni 90, l’interesse per la diffusione delle informazioni è cresciuto grazie agli sviluppi di applicazioni distribuite che rendessero disponibili nuovi tipologie di servizi su un ambiente di larga scala quale la rete Internet. La disseminazione delle informazioni in forma anonima ed in maniera asincrona è tra gli aspetti che più hanno tratto interesse in questo campo, il quale trova ormai impiego in numerosi ambiti, dallo scambio di quotazioni finanziarie al controllo del traffico aereo e navale, alla sottoscrizione di servizi di news. A seconda del campo di applicazione, la diffusione delle informazioni deve seguire regole e rispettare vincoli più o meno restrittivi: si pensi per esempio a quanto ritardo sia accettabile tra l’invio del comando “Fuoco” alla ricezione dello stesso da parte di un dispositivo remoto in una missione militare, o a quanto sia tollerabile la perdita di una transazione finanziaria. Per cui le problematiche che un sistema di diffusione delle informazioni si trova ad affrontare sono molteplici:

l’ormai crescente mole di dati che si vuole trasmettere ad un numero sempre maggiore di partecipanti interessati, i quali possono essere dislocati su una rete geograficamente vasta, è un altro aspetto da tenere bene in considerazione, come pure la diversità delle architetture usate per i singoli partecipanti. Senza contare aspetti dinamici delle reti, guasti, il churn¹dei partecipanti, inaffidabilità dei canali, aspetti che appaiono evidenti, e maggiormente critici, se si pensa ad una rete di dispositivi mobili.

Poich´e tali problematiche sono comuni a molti e diversi campi d’applicazione, si `e pensato di creare uno strato software che si occupasse di esse. Uno strato che forma una

“terra di mezzo” tra applicazione e sistema sottostante e per questo chiamato midd- leware. L’idea è dunque di demandare al middleware la gestione delle problematiche, mentre l’applicazione dovrà occuparsi solo della propria logica: inviare un dato per l’applicazione si tradurrà in un’istruzione al middleware sottostante, inviarlo affidabil- mente potrà essere la stessa istruzione con parametri di affidabilità. Il resto del gioco

è intrapreso dal middleware, il cui apporto migliorerà sia l’interoperabilità con i vari sistemi che l’efficienza delle applicazioni.

Contributo

Oggetto di questa tesi `e lo studio di una particolare implementazione di middleware orientata alla diffusione delle informazioni: NDDS della Real Time Innovations Inc.

1Per churn si intende il continuo entrare ed uscire di partecipanti dalla comunicazione

1

(8)

2 INTRODUZIONE

Lo scopo `e analizzare il comportamento del software in condizioni di stress dovute ad alte velocit`a d’invio dati, alla dimensione degli stessi, al numero di partecipanti alla comunicazione ed infine alla distanza geografica tra di essi.

Organizzazione

In questa tesi, dopo una descrizione delle tecnologie utilizzate durante lo stage (Capitoli da 1 a 4), illustrer`o il software che ho prodotto per effettuare i test (Capitolo 5), nonch`e i risultati ottenuti (Capitolo 6), cercando di mostrare se il middleware RTI DDS sia valido o meno per applicazioni di larga scala.

(9)

Capitolo 1

Middleware e sistemi distribuiti

1.1 Introduzione al Middleware

Middleware è uno strato di software che si interpone tra applicazioni e sistema opera- tivo, isolandole dall’architettura usata. Se si tratta di un Network Middleware (Figura 1.1) le si isola anche dalla particolare pila protocollare usata per la rete: l’applicazione semplicemente non necessita di sapere che stack usare (TCP/IP, IPX . . . ) altres`ı non ha bisogno di creare strutture apposite (per esempio socket), bens`ı si rivolge a questo strato per ottenere tali funzionalità. L’utilizzo di uno strato software aggiuntivo, il middleware appunto, consente di ottenere un elevato livello di servizio per gli utenti, ed un elevato livello di astrazione per i programmatori. Inoltre, consente di facilitare la manutenzione, la stesura e l’integrazione di applicazioni. Tale ruolo è, per certi versi, un’evoluzione del ruolo del middleware, che in partenza era limitato a ricercare l’efficienza e l’interoperabilità nel sistema.

Pi`u precisamente un Middleware si pu`o definire come

un software di connessione che consiste in un insieme di servizi e/o di ambienti di sviluppo di applicazioni distribuite che permettono a più entità (processi, oggetti, ecc), residenti su uno o più elaboratori, di interagire at- traverso una rete di interconnessione a dispetto di differenze nei protocolli di comunicazione, architetture dei sistemi locali, sistemi operativi, ecc.

Il suo principale obiettivo è fornire la “visione” di un’applicazione distribuita come un insieme di entità cooperanti al di sopra di OS¹ eterogenei. A tale scopo devono essere forniti servizi per la localizzazione di una entità, servizi per la scoperta delle operazioni eseguibili da una entità, servizi per la sincronizzazione temporale, per la sicurezza. . .

.

1Operating System - sistema operativo

3

(10)

4 CAPITOLO 1. MIDDLEWARE E SISTEMI DISTRIBUITI

Figura 1.1: Struttura a livelli per applicazioni di rete distribuite

1.2 Funzionalit` a offerte dal Middleware

Un Middleware ha la caratteristica di fornire un ben preciso modello di programmazione per lo sviluppo di applicazioni distribuite, sollevando il programmatore dalla necessit`a di occuparsi di tutti i dettagli di basso livello della comunicazione e lo scambio di messaggi tra processi distribuiti. Le principali specifiche e propriet`a che un generico middleware deve fornire sono:

Marshalling e Unmarshalling : i dati prodotti dalle applicazioni devono essere for- mattati per garantire l’indipendenza hardware/software dell’host di provenienza, il Marshalling (letteralmente “impastamento”), effettuato in fase di trasmissione, prevede la suddivisione dei dati in pi`u messaggi, la codifica in caratteri universali ASCII, la conversione little-endian big-endian ecc.; l’Unmarshalling, effettuato in fase di ricezione, opera esattamente al contrario riportando i dati in uno stato comprensibile a quel particolare host;

Data Representation and Codification : per poter operare marshalling e unmarshalling, il protocollo di middleware deve definire tutti i tipi di dato che le applicazioni possono utilizzare per comunicare (es. string, float, enumerated ecc.);

in tal modo il programmatore potr`a “dimenticarsi” dei dettagli dei processi di comunicazione, a patto di lavorare, in fase di programmazione, coi tipi messi a disposizione dal protocollo che sta impiegando;

Invocazioni Remote : i moderni middleware, con la nascita della programmazione a oggetti distribuiti, devono permettere l’invocazione remota di processi e metodi per garantire un’interazione efficiente tra le applicazioni;

Garanzia della Location Transparency : gli applicativi che costituiscono il sistema distribuito devono poter comunicare senza preoccuparsi della loro posizione

(11)

1.3. SISTEMI DISTRIBUITI 5

fisica n´e dei loro indirizzi logici, sar`a il Middleware Layer a occuparsi dei dettagli di basso livello;

Totale trasparenza di utilizzo per l’utente finale : l’utente dell’applicazione pro- grammata col supporto middleware non deve “accorgersi” della presenza dello stesso e quindi non deve occuparsi di coordinarne il funzionamento, in quanto sar`a del tutto integrato nel codice dell’applicazione.

1.3 Sistemi distribuiti

Un sistema distribuito è un insieme di unità d’elaborazione debolmente connesse² tra- mite una rete di comunicazione. Ciascuna unità considera remote le altre e le rispettive risorse, mentre considera locali le proprie. Le unità di elaborazione variano da ambi- to ad ambito, in generale sono riferite con i nomi di siti, nodi, calcolatori, macchine secondo il contesto in cui sono citate. Lo scopo di un sistema distribuito è fornire un ambiente efficiente e conveniente per la condivisione delle risorse tra tali unità. Un sistema di questo tipo deve affrontare la problematica di gestire una notevole quantità di dati prodotti in tempi molto brevi, smistandoli verso la giusta strada che li porta da chi li ha prodotti verso chi effettivamente li richiede.

Il middleware svolge un ruolo fondamentale nello sviluppo di sistemi e applicazioni distribuite: amalgama l’ambiente ed evita di dover sviluppare numerose versioni dello stesso software per le diverse architetture.

1.3.1 Vantaggi dei sistemi distribuiti

Quattro sono i motivi principali che spingono ad usare un sistema distribuito come soluzione: condivisione delle risorse, accelerazione dei calcoli, affidabilità e comunica- zione. Quest’ultimo è l’aspetto che pi`u caratterizza l’oggetto di questa tesi: se più nodi sono collegati per mezzo di una rete di comunicazione, gli utenti hanno la possibilità di scambiarsi informazioni, rendendo possibili numerosi servizi, per esempio la colla- borazione degli utenti allo sviluppo di progetti anche se geograficamente distanti tra loro. Inoltre avere più sistemi che comunicano favorisce la migrazione da sistemi ba- sati su mainframe a sistemi composti da elaboratori più piccoli che si scambiano dati.

I vantaggi che ne seguono sono in termini di flessibilità, manutenibilità, affidabilità, prestazioni. Da notare come sempre più spesso i sistemi di automazione siano control- lati da sistemi distribuiti, in grado di coordinarsi autonomamente proprio grazie alla possibilità di comunicare ed interoperare delle varie parti in gioco.

2Per connessione debole si intende che non necessariamente esiste una connessione diretta tra ogni coppia di unità, ma che esiste almeno un cammino che le collega che può attraversare anche altre entità

(12)

6 CAPITOLO 1. MIDDLEWARE E SISTEMI DISTRIBUITI

(13)

Capitolo 2

Modello Publish/Subscribe

Il modello Publish/Subscribe rappresenta una tecnolgia chiave per lo sviluppo di ap- plicazioni distribuite. In sostanza ogni partecipante alla comunicazione può scegliere il ruolo di Publisher o di subscriber delle informazioni. I primi producono i dati sotto forma di “eventi” che sono consumati dai secondi qualora essi abbiano interesse nel riceverli. Ciò che caratterizza un sistema Publish/Subscribe è, per l’appunto, come i dati fluiscono dai Publishers ai Subscribers: i destinatari, non sono reperiti tramite un indirizzo, ma in maniera semantica tramite il contenuto degli eventi. Per esempio in un sistema Publish/Subscribe topic-based il publisher produrrà eventi appartenenti ad un certo topic¹, senza curarsi di sapere l’indirizzo di chi sia interessato a questi eventi. Dall’altro lato i subscribers interessati a quel tipo di evento comunicheranno la propria volontà di ricevere dati da quel topic, senza necessità di sapere l’indirizzo di chi sta emettendo gli eventi. Grazie a questo anonimato, i partecipanti si scambiano informazioni senza doversi conoscere l’un l’altro direttamente, rendendo quindi possibile e relativamente semplice l’espansione della comunicazione a reti di larga scala.

L’interazione tra i Publishers ed i Subscribers è mediata dal Pub/Sub System, che in generale è costituito da un insieme di nodi che si coordinano tra loro per fars`ı che le informazioni arrivino a tutti (e possibilmente solo a) i partecipanti interessati. A tale proposito esistono diversi modelli di sottoscrizione che influenzano il modo in cui un subscriber specifica quali eventi è interessato a ricevere, i più popolari:

- Topic-based;

- Content-based;

2.1 Modelli di sottoscrizione

Esistono diversi modi di specificare quali eventi siano di interesse, ad ognuno di essi corrisponde una variante del paradigma Publish/Subscribe. Ciò che fondamentalmente caratterizza tali modelli è la loro “potenza espressiva”, maggiore espressività implica la

1Letteralmente “argomento”

7

(14)

8 CAPITOLO 2. MODELLO PUBLISH/SUBSCRIBE

possibilità per un subscriber di selezionare con maggiore precisione gli eventi ai quali è interessato. I seguenti sono i modelli di sottoscrizione più popolari:

Topic-based Model - Gli eventi sono raggruppati in base al Topic a cui appartengo- no. Un subscriber dichiara il proprio interesse in un determinato topic e ricever`a tutti gli eventi ad esso correlati. Il topic pu`o essere visto come un canale logico che connette ogni possibile publisher di quel topic ad ogni subscriber interessato.

Il principale svantaggio di questo modello risiede nella poca espressività offerta ai subscribers. Infatti un subscriber interessato solo ad un sottoinsieme di eventi correlati ad uno specifico topic riceverà anche tutti gli altri che fanno parte di esso. Nelle varie implementazioni questo problema è stato risolto usando un sistema a gerarchie di topic, ovvero creando topic che sono sottosezioni di altri.

Content-based Model - I subscribers esprimono il proprio interesse specificando condizioni sul contenuto degli eventi che si vogliono ricevere. In altre parole si filtra il contenuto dei messaggi e si accettano solo quelli che soddisfano i criteri imposti su determinati attributi. A seconda del tipo degli attributi e del linguaggio usato (alcuni linguaggi permettono l’uso delle espressioni regolari e di operatori logici) si possono creare filtri più o meno espressivi: Il topic-based model può essere emulato con il Content-based Model con un vincolo di uguaglianza preso su un attributo che gioca il ruolo del topic. Non esiste più l’idea di un canale logico tra i publishers ed i subscribers mentre la corrispondenza tra di essi è del tutto orientata all’evento stesso. Lo svantaggio di questo approccio risiede nella com- plessità di calcolare l’insieme di subscribers interessati analizzando il contenuto di ogni evento, il che richiede un grande dispendio di risorse.

2.2 Modello architetturale

Un sistema Publish/Subscribe distribuito, per la diffusione scalabile delle informazioni, pu`o essere decomposto in tre livelli funzionali, vale a dire l’infrastruttura di overlay, l’event routing (indirizzamento degli eventi) e l’algoritmo per il matching fra eventi e sottoscrizioni. La “Overlay Infrastructure” rappresenta l’organizzazione delle diverse entit`a che compongono il sistema (per esempio una rete di server dedicati o una overlay peer-to-peer strutturata), mentre per “Event Routing” si intende il meccanismo per la disseminazione delle informazioni dai publishers ai subscribers. Esso sfrutta l’infrastruttura di overlay e vi integra le proprie informazioni di routing per ottenere una spedizione degli eventi scalabile. Spesso, nelle implementazioni, questi due livelli si confondono l’un l’altro, non distinguendo chiaramente le loro dipendenze e rendendo difficile il confronto con le altre implementazioni. Infine l’ “Algoritmo di Matching”

filtra gli eventi prodotti dai publisher e fa in modo che al subscriber giungano solo quelli che soddisfano determinati criteri previsti dal modello di sottoscrizione.

Segue una breve panoramica sui livelli, le loro funzioni e implementazioni.

(15)

2.2. MODELLO ARCHITETTURALE 9

Figura 2.1: Architettura a livelli di un sistema Publish/Subscribe

2.2.1 Protocolli di rete (Network Protocols)

Formano lo strato che ancòra il sistema Pub/Sub alla rete sottostante, consentendo la comunicazione e la trasmissione dati fra i vari componenti del Pub/Sub System. Poiché un sistema Pub/Sub può sorgere su reti eterogenee (LANs², WANs³, mobile networks . . . ) esso può impiegare più di un singolo protocollo di rete per far fronte a differenti condizioni hardware/software che si possono presentare su parte della rete o per rendere massime le performance.

E possibile differenziare i sistemi Pub/Sub in base al tipo di protocollo che adottano:` Transport level - I sistemi Pub/Sub di questo tipo sfruttano le funzionalit`a offerte dai protocolli di livello transport, ad esempio comunicando direttamente attraverso TCP o UDP oppure interfacciandosi ad essi usando dei protocolli specifici di middleware (quali IIOP⁴ e SOAP⁵). Questa scelta rende il sistema molto flessibile e facile da estendere anche a sistemi in cui sono presenti degli impedimenti

2LAN - Local Area Network, una rete di dimensioni geografiche limitate ad un edificio o campus

3WAN - Wide Area Network, una rete geografica molto estesa, anche planetaria

4IIOP - Internet Inter-Orb Protocol in sostanza CORBA orientato al web

5SOAP - Simple Object Access Protocol, una specifica XML per le transazioni sincrone e asincrone sul web

(16)

dovuti alla presenza di firewall o reti private, casi in cui serve l’intervento di un amministratore per la configurazione.

Network level Multicast - Utilizzando direttamente le primitive di broadcast e multicast della rete si ottiene un modo più efficiente per diffondere i dati tra molti nodi partecipanti. In questo modo le latenze sono minori e il throughput aumenta, in quanto l’onere di implementare il protocollo di routing è svolto dagli apparati di rete. Ad esempio IP Multicast può essere usato direttamente in un ambiente Topic-based, in quanto ad ogni topic si può far corrispondere esattamente un gruppo multicast. Non è invece cos`ı immediato per un Content-based dove non

`e possibile mappare i subscribers in gruppi multicast. Tuttavia IP Multicast non

è una soluzione sufficientemente flessibile per una WAN, inoltre orienta l’espres- sività dalla conoscenza del topic (e della sua semantica), alla conoscenza di un indirizzo di Multicast IP (che di per sé non è espressivo).

Mobile Networks - Esistono due varianti, una che considera tutti i dispositivi come mobili, l’altra che considera parte dei nodi ferma e costituente l’infrastruttura nella quale i client si muovono e rimangono sempre ad un hop⁶ di distanza da almeno un nodo fisso. In entrambi i casi si può usare un Transport e/o un Network protocol che utilizzi il protocollo di livello data link della rete mobile (per esempio 802.11g) oppure direttamente il protocollo di livello data link stesso, senza trascurare che la mobilità dei dispositivi introduce vincoli sulle risorse, consumo di batteria, larghezza di banda limitata oltre a temporanee disconnessioni e in- disponibilità dei nodi. Tutte caratteristiche che il middleware deve considerare insieme alla location-awareness⁷, che deve essere tipicamente supportata.

2.2.2 Infrastruttura di overlay (Overlay Infrastructure)

Generalmente un sistema Publish/Subscribe si basa su una overlay network di livello application. Diverse possibilit`a si presentano nel come i nodi della rete sono organizzati e nel ruolo che ricoprono.

Broker Overlay - Per coprire una rete quale l’intera internet, le applicazioni distribuite che si avvalgono del Pub/Sub system richiedono che questi sia implementato come un insieme di server indipendenti e comunicanti. In questo contesto, ogni singolo server `e chiamato broker. I broker server formano quindi una rete di over- lay comunicante con i protocolli di network citati prima. Un client che intende connettersi e partecipare alla comunicazione pu`o accedere al sistema tramite un qualsiasi broker, che in genere memorizza solo un sottoinsieme delle sottoscrizioni.

le connessioni sono puramente logiche e astratte, non rispecchiano gli effettivi link internet che sfruttano, il che implica che una broker network sia inerentemente statica, ossia varia solo raramente in caso di aggiunta di un nuovo broker o di

6Letteralmente “salto”, indica quanti nodi deve attraversare il dato prima di giungere al client

7In poche parole si tratta di sottoscrizione di servizi in base alla distanza tra publisher e subscriber

(17)

2.2. MODELLO ARCHITETTURALE 11

guasto su uno esistente. Per questo si assume che la topologia sia gestita da un amministratore ed i nodi connessi a formare il “vicinato” (neighborhood) siano determinati in base a relazioni di conoscenza (staticamente). Le topologie usate sono per lo pi`u di due tipi: gerarchica e flat. Nel primo caso i punti d’accesso dei publisher risiedono alla radice e quelli dei subscriber alle foglie (o viceversa) e gli eventi viaggiano solo attraverso i livelli interessati, nel secondo caso invece non ci sono limitazioni alla connessione il che ha il vantaggio di non sovraccaricare nodi radice.

Peer-to-peer Structured Overlay - Una overlay network peer-to-peer structured è una rete di livello applicazione composta da un insieme di nodi che si autogesti- scono, formanti un grafo strutturato su uno spazio di chiavi virtuale dove ad ogni chiave è associato un nodo. La presenza di questa struttura delle chiavi imposta al grafo, permette l’efficiente rilevazione dei partecipanti e dei dati da trasmettere, nonché la comunicazione attraverso i nodi. Il fatto che la overlay sia strutturata garantisce quindi che vi sia sempre corrispondenza tra un qualsiasi indirizzo ed un nodo attivo anche in presenza di nodi che entrano ed escono dalla rete (churn) e di guasti sui nodi. A differenza della broker overlay inerentemente statica, una p2p⁸ Structured Overlay gestisce bene gli aspetti dinamici della comunicazione, per cui è più adatta ad ambienti decentralizzati e di larga scala, dove l’intervento umano non può essere considerato una soluzione fattibile.

Peer-to-peer Unstructured Overlay - La rete si sforza di organizzare i nodi in una struttura gerarchica o flat in un piccolo raggio di copertura di rete contro guasti dei nodi e frequenza di churn (ingresso/uscita di nodi). Differentemente da una broker overlay, non si suppone che i nodi siano server dedicati, ma possono inclu- dere anche workstations, portatili, dispositivi mobili e cos`ı via, ed essi possono agire sia come client che come parte del pub/sub system. Inoltre, ovviamente, la topologia non deve essere gestita da un amministratore umano, i nodi sono in grado di autogestirsi. Poiché non vi è una struttura, per reperire i nodi ed i dati esse sfruttano tecniche di flooding, gossiping o cammini casuali attraverso il grafo per diffondere e ricevere informazioni associate ai nodi. Il vantaggio risiede nella facilità con cui vengono gestiti i “join” e “leave” (unione e rilascio) dei nodi. In ogni caso, a differenza delle reti strutturate, non v’è garanzia che ad ogni indirizzo sia associato un nodo attivo.

Unstructured Overlays over Mobile Networks - In un ambiente formato da dispositivi mobili, il cambiamento di topologia è una caratteristica imprescindibile, dovuta al churn, allo spostamento dei dispositivi nonché ai guasti. È impossibile in questo caso, agire creando strutture gerarchiche o flat a piccoli raggi in quanto i nodi sono mobili e questo ne rende difficile l’ottimizzazione. Inoltre sono necessari algoritmi che mantengano connettività e consistenza delle strutture dati per il

8E il diffusissomo acronimo per i sistemi peer-to-peer`

(18)

routing, altrimenti il routing degli eventi stesso non pu`o avvenire correttamente.

Creare alberi ricoprenti richiede algoritmi che devono bloccare la computazione fintanto che un albero non `e stato costruito, questo `e il motivo per cui spesso si agisce direttamente con i protocolli di livello MAC (Medium Access Control per esempio 802.11b/g/n) sfruttandone le caratteristiche di broadcast.

2.2.3 Indirizzamento degli eventi (Event Routing)

Il cuore di un sistema Pub/Sub distribuito risiede nel meccanismo di Event Routing.

In poche parole è il processo di consegna degli eventi a tutti i subscribers che abbiano manifestato la volontà di sottoscrivere una pubblicazione. Questo implica una visita dei nodi da parte del Notification Service⁹ al fine di trovare, per ogni evento pubblicato, tutti i client la cui sottoscrizione registrata è presente nel sistema al momento della pubblicazione. Tuttavia, l’impossibilità di definire un ordine temporale globale tra una sottoscrizione ed una pubblicazione accadute su due nodi diversi (e quindi con clock generalmente diverso) rende ambigua questa definizione di event routing. Il problema principale dell’event routing è la scalabilità. Le performance dovrebbero degradarsi il meno possibile all’aumentare dei nodi, delle sottoscrizioni e delle pubblicazioni. A tal fine occorre regolare le pubblicazioni in modo che la propagazione degli eventi coinvolga quanto più possibile solo i brokers che contengono delle sottoscrizioni per essi. D’altro canto, ridurre la quantità di informazioni di routing da mantenere sui brokers al fine di permettere flessibili cambiamenti delle sottoscrizioni. Questi due aspetti sono in evidente contrapposizione, bilanciarli è uno dei primi compiti del progettista di un sistema Pub/Sub.

2.2.4 Controllo degli eventi (Matching Algorithm)

Con Matching si indica il processo di controllo di un evento che sia adatto ad una sottoscrizione. Il matching è eseguito dal sistema Pub/Sub al fine di determinare se un evento debba essere consegnato ad un subscriber o meno. Esso si interlaccia anche con l’agoritmo di routing, in quanto spesso decisioni di routing sono prese in base al matching degli eventi e sottoscrizioni. Nel contesto di sistemi di larga scala è desidera- bile da un lato avere un un numero di sottoscrizioni veramente alto e dall’altro avere alte velocità di elaborazione di eventi. Ne segue che in generale il processo di matching viene eseguito spesso e su grandi quantità di dati. Questo non è un gran problema in un sistema Topic-based, dove il matching si riduce ad un semplice lookup in tabelle, ma in un sistema Content-based è un grande scoglio per le performance generali, per cui l’efficienza dell’algoritmo di matching gioca un ruolo fondamentale.

9E un servizio offerto dal Middleware`

(19)

Capitolo 3

Real Time Innovations Data

Distribution Service

RTI Data Distribution Service¹ `e un Network Middleware per applicazioni real-time distribuite. Fornisce i servizi che sono necessari per sviluppare applicazioni time-critical distribuite che diffondano dati, fra i vari dispositivi che li richiedono, con il minimo ritardo possibile. RTI Data Distribution Service utilizza il modello Publish/Subscribe per la comunicazione, infatti implementa le DCPS API (Data Centric Publish-Subscribe Application Programming Interfaces) fornite dall’OMG (Object Management Group) nella specifica DDS (Data Distribution Service) per le applicazioni Real-time.

Questo Network Middleware ha riscosso successo in diversi campi di applicazione time-critical e data-critical, quali

- National railways - Air traffic control - Traffic monitoring

- Mission-critical combat systems - Financial transaction processing - Industrial automation

RTI Data Distribution Service `e agnostico del sistema operativo e del linguaggio di programmazione permettendo a sistemi eterogenei di comunicare tra loro in maniera piuttosto semplice:

Le applicazioni saranno completamente disaccoppiate (figura 3.1), useranno dal lato mittente oggetti di tipo Publisher e DataWriter, in ricezione invece saranno di tipo Subscriber e DataReader. Ogni partecipante alla comunicazione pu`o agire nel ruolo di Publisher, Subscriber o entrambi. Il singolo partecipante alla comunicazione `e un oggetto di tipo DomainParticipant ovvero proprio un partecipante del dominio. I

1Precedentemente noto come NDDS

13

(20)

14 CAPITOLO 3. REAL TIME INNOVATIONS DATA DISTRIBUTION SERVICE

Figura 3.1: Architettura di un’applicazione sviluppata su RTI DDS

domini servono a discriminare fra diverse applicazioni che si avvalgono di RTI DDS in modo che non interferiscano l’un l’altra. Per cui un Domain rappresenta una rete di comunicazione logica ed isolata che fa in modo che entit`a di domini diversi (anche se presenti sulla stessa macchina) non si scambino mai dati.

La figura 3.2 illustra come interagiscono le varie entità al fine di comunicare: un’ap- plicazione utilizzerà dunque un DataWriter per inviare i dati. Un DataWriter è as- sociato ad un singolo Topic mentre ad uno stesso Topic possono essere associati pi`u oggetti di tipo DataWriter anche all’interno della stessa applicazione. Un Publisher

è l’oggetto della specifica DCPS responsabile dell’effettivo invio dei dati. L’oggetto Publisher “possiede” e gestisce gli oggetti DataWriter. Un oggetto Datawriter può appartenere solo ad un Publisher mentre il viceversa non vale, ovvero ad un Publisher possono appartenere pi`u oggetti di tipo DataWriter. In questo modo un oggetto di tipo Publisher può inviare dati su più Topic distinti. L’associazione tra un DataWriter ed

(21)

3.1. QOS SUPPORTATE 15

Figura 3.2: Schema concettuale di un sistema DCPS

un Publisher `e spesso identificata come una Publication altres`ı non esiste alcun oggetto di questo tipo nella specifica, ma esso `e solo un modo di denominarla.

Quanto detto lato mittente `e del tutto speculare a lato destinatario e l’associazione tra un oggetto DataReader ed uno di tipo Subscriber prende il nome di Subscription, bench´e non esista alcun oggetto con questo nome.

La comunicazione pu`o quindi essere regolata e messa a punto tramite gli opportuni valori di QoS² che si passano alle varie entit`a. Di seguito vengono riportate quelle prese in esame in questa sede.

3.1 QoS supportate

RTI DDS implementa lo standard della OMG, in ogni caso sussistono delle scelte ar- chietturali che apportano delle estensioni alla specifica, nonch´e l’esistenza di QoS non supportate. Di seguito sono riportate le QoS di maggior interesse nell’ambito dello studio che questa tesi svolge, sono riportate come previste dallo standard DDS e se

2Quality of Service

(22)

implementate o meno da NDDS.

QoS Policy Valore Specifica DDS RTI

DURABILITY un tipo:

VOLATI-

LE, TRAN-

SIENT - LOCAL, TRANSIENT, PERSISTENT

Indica se i dati debbano essere disponibili anche dopo che sono stati inviati al DataWriter per per- mettere che dei Da- taReader che si uni- scono in ritardo alla comunicazione li ricevano

Implementa VO- LATILE e TRAN- SIENT LOCAL

DEADLINE Una durata

temporale

Un DataReader si aspetta di ricevere dati almeno con periodo di deadline.

Nel DataWriter invece, indica che l’applicazione mira a inviare dati almeno con periodo di deadline

Implementato

OWNERSHIP un tipo:

SHARED, EXCLUSIVE

Specifica se sia per- messo che pi`u Data- Writer possano scri- vere la stessa istanza di dato e in caso come ci`o debba essere arbitrato

Implementato

RELIABILITY un tipo: BE- ST EFFORT, RELIABLE ed una durata di max blocking - time

Indica il livello di affidabilità ri- chiesta/offerta dal servizio ed il tempo massimo che il Data- Writer può rimanere bloccato se non ha più spazio per ulteriori campioni

Implementato

(23)

3.1. QOS SUPPORTATE 17

QoS Policy Valore Specifica DDS RTI

LIFESPAN Una durata

temporale

Specifica la massima durata di validit`a di un dato scritto dal DataWriter

Implementato

HISTORY Un tipo:

KEEP LAST, KEEP ALL ed un numero intero di depth

Questa QoS specifica i campioni che debbano essere mantenuti in memoria, nel caso di KEEP LAST solo gli ultimi dep- th campioni saranno mantenuti

Implementato

RESOURCE - LIMITS

Tre nume-

ri interi:

max samples, max instances, max samples - per instance

Specifica le risorse che il servizio pu`o consumare per offrire le QoS desiderate

Implementato

Le seguenti sono QoS non previste dalla specifica, bens`ı estese da RTI DDS, sono solo alcune che sono state utilizzate nell’ambito di questa tesi:

TRANSPORT UNICAST - Specifica le interfacce unicast transport network da usare per la ricezione dei messaggi da parte dell’entit`a;

DISCOVERY - Specifica gli attributi necessari a trovare i partecipanti nel dominio;

WIRE PROTOCOL - Specifica gli attributi del wire protocol per il DDSDomain- Participant;

DATA READER RESOURCE LIMITS - Specifica l’ammontare delle risorse spe- cifiche che RTI Data Distribution Service pu`o usare per il DataReader;

DATA WRITER RESOURCE LIMITS - Specifica l’ammontare delle risorse spe- cifiche che RTI Data Distribution Service pu`o usare per il DataWriter ;

DATA READER PROTOCOL - Configura i parametri di QoS specifici del Data- Reader ;

DATA WRITER PROTOCOL - Configura i parametri di QoS specifici del Data- Writer ;

ASYNCHRONOUS PUBLISHER - Specifica la configurazione del Publishing asin- crono per le istanze di DDSPublisher ;

(24)

3.2 Discovery

Il modello DCPS fornisce una comunicazione molti-a-molti, trasparente e anonima.

Ogni volta che l’applicazione invia dei dati di un Topic il middleware li replica a tutti i Subscriber che hanno sottoscritto quel Topic. L’applicazione lato Publisher non deve curarsi di quanti siano tanto meno dove siano, lo stesso discorso vale per il lato Subscri- ber. Per ottenere ci`o, su ogni nodo, RTI DDS deve mantenere una lista di applicazioni interessate al Topic ed alcune informazioni sulla QoS per l’invio dei dati. La propa- gazione di queste informazioni fra i vari partecipanti interessati `e chiamata Discovery process.

La specifica DDS (DCPS) non indica come tale processo debba avvenire ed RTI DDS lo implementa tramite un protocollo di RTPS (Real Time Publish Subscribe) opportuno:

Quando un DomainParticipant viene creato, il middleware lancia dei pacchetti sulla rete per annunciarne l’esistenza. Quando un’applicazione trova che un’altra applica- zione appartiene allo stesso dominio (Domain) scambier`a con essa informazioni sullo stato di pubblicazioni e sottoscrizioni e relative QoS. Quando nuovi DataWriter e Da- taReader sono creati, tale informazione sar`a notificata a tutta la lista di applicazioni conosciute.

Una veloce, ma più dettagliata, descrizione di come funzioni è la seguente: quando un DomainParticipant viene avviato, per default invia 3 messaggi ad ogni nodo nella sua PEER LIST³. Il numero di tali messaggi può essere configurato nella QoS del Domain- Participant nel campo discovery config.new remote participant announcements.

Questi messaggi vengono inviati ad intervalli casuali tra zero ed un secondo per de- fault. Anche questo tempo `e configurabile nella QoS del DomainParticipant nel cam- po discovery config.new remote participant announcement period. Esso serve ad inviare messaggi a ritardi casuali compresi tra zero ed il valore impostato, in modo da evitare il flooding⁴ del nuovo DomainParticipant remoto con tanti messaggi di di- scovery assieme. Se tutti i messaggi vengono persi, il DomainParticipant attender`a 30 secondi⁵, e tale valore viene preso anche come periodo di liveliness, configurabile nel campo discovery config.participant liveliness assert period.

3.3 Note sugli ambienti supportati

• Architetture supportate:

– AMD 64/EM64T – ARM

3La PEER LIST pu`o essere un file, una variabile d’ambiente (entrambi chiamati NDDS DISCOVERY PEERS) o un array di indirizzi che viene passato al DomainParticipant.

Non `e necessario che su tali indirizzi risiedano effettivamente delle applicazioni in funzione

4Letteralmente “inondazione”

5Questo valore `e stato confermato dai test

(25)

3.3. NOTE SUGLI AMBIENTI SUPPORTATI 19

– PowerPC

– SPARC (32 & 64 bit) – X86

• I protocolli supportati sono:

– IPv4 – IPv6

– Pluggable Interface

• Linguaggi di programmazione:

– ANSI C (C89) and ISO C (C99) with GNU extensions – ANSI C++

– Java 1.3 or later

Le API rispettano il DCPS layer della specifica OMG DDS. I tipi di dati sono definibili tramite la OMG Interface Definition Language (IDL). Il formato dei pacchetti dati rispetta le specifiche, disponibili pubblicamente, dell’International Engineering Consortium (IEC) per il RTPS wire protocol.

(26)

(27)

Capitolo 4

PlanetLab

E una rete applicativa (overlay) sperimentale atta al supporto alla ricerca su applica-` zioni e servizi di rete. La distribuzione dei nodi e delle loro risorse `e su una vasta area geografica (planetaria) e fornisce un valido strumento per testare software e protocolli nonch´e al dispiegamento di servizi su un sistema distribuito.

Del consorzio PlanetLab fanno parte realtà accademiche, industriali e governative ed è gestito dalle Università di Princeton, Berkeley e dall’Università di Washington. Al momento Princeton è la sede del consorzio PlanetLab che offre 753 nodi dislocati in 363 siti diversi distribuiti come mostrato in figura 4.1.

Figura 4.1: Distribuzione geografica dei nodi PlanetLab

Il progetto è senza fini di lucro, i risultati degli esperimenti non possono essere usati a scopo commerciale, ma diventano patrimonio della comunità scientifica. Gli enti non-profit possono farne parte gratuitamente, mentre gli enti profit devono pagare una tassa di iscrizione. In ogni caso per gli enti è fatto obbligo di offrire almeno due nodi sui quali installare la VM (Virtual Machine) di PlanetLab al fine di diventare

21

(28)

22 CAPITOLO 4. PLANETLAB

membri. La membership ha vari livelli, classificati come: Sponsor, Associate, Full, Charter, Academic.

Con PlanetLab `e possibile:

• Testare applicazioni in ambienti separati accessibili tramite una connessione si- cura (tramite ssh – Secure SHell per esempio);

• Controllare il comportamento delle applicazioni in un ambiente realistico (utilizza infatti collegamenti internet standard rendendo le applicazioni soggette a tutti i problemi di latenza, congestione ecc. che si verificano nella realt`a), eliminando quindi le approssimazioni necessarie in ambienti simulati;

• Eseguire servizi sui nodi PlanetLab che siano accessibili anche ad applicazioni esterne (site su nodi che non fanno parte di PlanetLab)

Oltre alla possibilit`a di usarlo come testbed, PlanetLab offre anche altri servizi, utilizzabili dagli utenti e dagli sviluppatori:

Content Distribution Networks :

• CoralCDN

• CoDeeN

• Cobweb

Distributed Hash Tables :

• OpenDHT Email :

• ePOST Mobile Access :

• DHARMA Multicast :

• ESM

• TMesh Publish-Subscribe :

• CorONA

Scalable Large-File Transfer :

• CoBlitz

(29)

4.1. ARCHITETTURA DEI NODI PLANETLAB 23

• LoCI

Robust DNS Resolution :

• CoDNS

• CoDoNS Routing Overlays :

• Internet Indirection Infrastructure (I3)

4.1 Architettura dei nodi PlanetLab

Su PlanetLab, gruppi di nodi possono essere associati a formare una Slice tramite vir- tualizzazione distribuita. Ci`o implica la necessit`a di un controllo delle risorse distribuito tra le varie VM (Macchine Virtuali) sui nodi. L’utilizzo di macchine virtuali garantisce notevoli vantaggi in termini di:

Sicurezza - impedisce accessi non autorizzati al sistema;

API familiari - evita agli utenti di imparare nuove API;

Isolamento - contiene il consumo di risorse;

Prestazioni - il carico pu`o essere bilanciato ottimizzandole;

Figura 4.2: Architettura di un nodo

Ogni servizio gira su una slice di PlanetLab usando un insieme distribuito di risorse (rete di macchine virtuali). Tali servizi hanno la possibilit`a di rimanere permanente- mente in esecuzione. Un VM monitor su ogni nodo `e responsabile della creazione e

(30)

gestione delle slice, in particolare ha il compito di limitare la frazione di risorse di nodo consumate e limitare la porzione di namespace consumati.

In sostanza ogni servizio che viene istanziato su un nodo PlanetLab utilizza una propria VM (Virtual Machine) che offre la possibilit`a di lavorare come su un normale ambiente Unix. Le macchine sono equipaggiate con distribuzione Linux Fedora Core 4 (kernel 2.6).

4.2 Utilizzo di PlanetLab

In questa sezione si darà una panoramica di come gestire le Slice ed effettuare il de- ployment di applicazioni distribuite. Tutti i dettagli inerenti lo stato della Slice e dell’account utente sono reperibili e alterabili (laddove possibile) attraverso l’interfac- cia web accessibile all’indirizzo http://www.planet-lab.org. Per cui un utente accedendo al sito, può rinnovare il periodo di validità della Slice¹ e aggiungere o rimuovere nodi ad essa.

il primo passo per accedere ai nodi PlanetLab `e creare una propria coppia di chiavi (pubblica e privata) RSA². Prendendo come riferimento un ambiente UNIX, il comando da eseguire `e il seguente:

ssh-keygen -t rsa -f ∼/.ssh/identity

una volta ottenuta la coppia, la chiave pubblica (identity.pub nell’esempio) deve essere caricata sulle informazioni dell’account utente tramite l’interfaccia web di Pla- netlab. Dopo un’attesa più o meno variabile, che occorre ai server per essere informati della chiave, si può accedere ai nodi. Come prima accennato si può usare ssh per ac- cedere ai nodi, e l’accesso avviene come utente che non ha i privilegi di amministrazione.

ssh -i ∼/.ssh/identity nome slice@host planetlab

I privilegi di amministrazione seguono la filosofia sudoer ovvero un utente `e abilita- to ad eseguire comandi con i privilegi di amministratore se prima del comando digita sudo³, per esempio per installare librerie standard C++ versione 3.4 si digita la stringa

sudo yum install libstdc++34

Il che ordina a yum, il package manager delle distribuzioni Fedora, di installare il pacchetto richiesto: solo gli amministratori possono aggiungere pacchetti al sistema.

Una volta ottenuto l’accesso, si possono eseguire comandi come su una qualsiasi

1La Slice `e abilitata per un certo tempo, rinnovabile

2RSA `e un algoritmo di crittografia asimmetrica ideato da Ron Rivest e Adi Shamir dalle cui iniziali prende il nome

3SuperUser DO

(31)

4.2. UTILIZZO DI PLANETLAB 25

macchina Fedora Core 4. In genere quello che si fa è copiare il codice su di esse, precedentemente compilato su un altro nodo, o su un elaboratore qualsiasi, a patto che le versioni di librerie e compilatore corrispondano. Per copiare dati tra nodi remoti si usa scp o rsync, anche se con entrambi i comandi è necessario eseguire manualmente la copia su tutti i nodi. Il tool vxargs scritto in python può essere una valida alternativa nel parallelizzare le copie ed inviare comandi a tutti i nodi in maniera meno manuale,

`e possibile scaricarlo dal sito di PlanetLab.

4.2.1 Installare RTI DDS su nodi PlanetLab

L’installazione di RTI è una procedura necessaria al fine di compilare il codice del- l’applicazione su un nodo PlanetLab ed evitare eventuali problemi di compatibilità di librerie. Una volta ottenuto il binario, esso può semplicemente essere copiato sugli altri nodi, senza dover eseguire un’altra installazione di RTI DDS. Per installare RTI DDS i passi sono i seguenti:

Copiare l’archivio contenente le librerie sul nodo desiderato tramite rsync;

rsync -v -u -a --stats ∼/ndds41d-i86Linux2.6gcc3.4.3.tar.gz nome slice-

@host planetlab:∼/

Collegarsi tramite ssh al nodo;

ssh -i ∼/.ssh/identity nome slice@host planetlab Estrarre l’archivio nella directory desiderata del nodo;

tar -xvzf ndds41d-i86Linux2.6gcc3.4.3.tar.gz

Aggiungere le seguenti righe alla variabile d’ambiente PATH (ad esempio modifi- cando il file ∼/.bash profile):

export NDDSHOME; NDDSHOME=∼/ndds.4.1d export PATH;

PATH=∼/ndds.4.1d/scripts/:${PATH}

export LD LIBRARY PATH;

LD LIBRARY PATH=∼/ndds.4.1d/lib/i86Linux2.6gcc3.4.3:${LD LIBRARY PATH}

export LD LIBRARY PATH;

A questo punto il nodo `e pronto per compilare codice utilizzando le librerie di NDDS. Ulteriori librerie mancanti possono essere installate tramite il package manager yum.

(32)

(33)

Capitolo 5

Test di RTI Data Distribution

Service utilizzando PlanetLab

L’obiettivo `e mettere sotto stress il middleware RTI DDS e studiarne il comportamento, in termini di latenza, in base alle condizioni di carico, al numero di nodi coinvolti, alle distanze geografiche in gioco.

Insieme al middleware RTI DDS vengono forniti due programmi di esempio che misurano le performance in termini di latenza e throughput. Sono disponibili in tre linguaggi di programmazione (C, C++, Java) e devono essere compilati in base all’architettura utilizzata. Utilizzando PlanetLab si `e scelto di usare il linguaggio C++ per non risentire del peso di un’ulteriore virtualizzazione. Infatti, come illustrato al Capi- tolo 4, PlanetLab virtualizza gi`a le risorse dei nodi e scrivere il software in Java rischia di distorcere troppo le misure raccolte a causa dell’ulteriore astrazione della JVM. Es- sendo i nodi PlanetLab macchine Linux la compilazione avviene usando l’architettura Linux x86 e gcc 3.3 (Gnu C Compiler).

Malgrado il software per la misura della latenza sia fornito insieme alle librerie del middleware, è stato necessario scriverne uno ex-novo: il programma presente, infatti, non è in grado di fornire misure di latenza fra ogni coppia publisher/subscriber, limita invece tale misura ad una sola coppia, un publisher ed un subscriber designato come echoer. Altres`ı il programma prevedeva una dimensione massima di 8KBytes ed è stato necessario modificarlo per raggiungere i 64KBytes di dati alla volta, non potendo comunque superare tale dimensione (di fatto era limitato alla massima dimensione del pacchetto UDP). Aveva, inoltre, delle esigenze in termini di latenza troppo basse, troppo lontane da un ambiente WAN: spesso infatti i test si bloccavano a causa di messaggi di echo che non facevano ritorno in tempo ragionevole. Per tutti questi motivi

`e stato necessario scrivere da zero un programma che effettuasse misure di latenza, e questo `e l’oggetto di questa tesi. Infatti nella stesura del codice del programma di test sono emerse molte caratteristiche del middleware, confermate dai successivi test eseguiti.

27

(34)

28

CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB

5.1 Ambiente del test

Il programma deve essere quindi in grado di testare le performance di RTI su tre scale geografiche distinte:

1. Nazionale (1 Publisher 2 Subscribers);

2. Europeo (1 Publisher 19 Subscribers);

3. Mondiale (1-10 Publisher 19-90 Subscribers);

Su scala nazionale, dato lo scarso numero di nodi disponibili, non si potranno con- durre test intensivi sul numero di partecipanti, che sarà limitato a 3. Per le altre due scale, invece, vi sarà maggiore flessibilità nel numero di nodi, ma allo stesso tempo bisogna scegliere oculatamente le Quality of Service per ottenere risultati rappresentativi.

I collegamenti saranno di tipo IPv4 punto-punto con dimensione dei dati trasmessi variabile tra 16 Bytes e 128 KBytes (tenendo a mente che la massima quantit`a di dati inviabile tramite singolo pacchetto UDP `e di 64 Kbytes).

5.2 Parametri del test

Ogni test deve analizzare il comportamento nelle modalit`a supportate dal middleware:

1. Best Effort (come per UDP, nessuna garanzia di affidabilit`a sui dati);

2. Reliable (affidabilit`a garantita);

In regime di crescente stress dovuto all’aumento 1. Del numero di partecipanti;

2. Della velocit`a d’invio (eventi/secondo);

Aumentare il numero di partecipanti metter`a in evidenza proprio quanto il middleware sia scalabile, in special modo su un ambiente di vaste dimensioni geografiche.

Aumentare la velocità di pubblicazione degli eventi mostrerà, invece, la tolleranza dello stesso a condizioni di stress e saturazione dei canali (limitazioni in termini di larghezza di banda, pacchetti persi, pacchetti rifiutati). In definitiva il numero di partecipanti varierà da 3 a 100 nodi, mentre il rate d’invio tra 1 evento/secondo fino a 1 evento/10 millisecondi.

5.3 Prodotti del test

Al variare quindi delle condizioni sopracitate il programma di test deve produrre una stima di

1. Latenza minima, massima, media per ogni coppia Publisher/Subscriber

(35)

5.4. SCRITTURA DEL PROGRAMMA DI TEST 29

2. Deviazione standard della Latenza 3. Andamento della latenza

4. Perdite di eventi

Dopo un’introduzione sul programma realizzato, una discussione sulle scelte prese, si analizzeranno anche i risultati dei test svolti sulla piattaforma PlanetLab. Si procede ora ad illustrare la realizzazione del programma di test.

5.4 Scrittura del programma di test

L’idea è creare un publisher che invii delle “sonde” ai subscribers i quali dopo aver preso i dovuti timestamps non faranno altro che rigirare tali sonde al publisher che le ha inviate¹. La latenza sarà dunque la metà del tempo impiegato dalla sonda a muoversi dal publisher fino a tornarci². Ovviamente bisogna minimizzare quanto più possibile i ritardi dovuti alla computazione. L’unico modo per vedere effettivamente come si comporta il Middleware, ovvero da quando l’applicazione lato Publisher genera l’evento a quando questo fa ritorno, è stato tramite il seguente protocollo:

1. Il Sender prende il timestamp d’invio, lo copia nel pacchetto dati e passa il pacchetto al middleware;

2. Il Receiver prende il timestamp di arrivo del pacchetto, lo copia nello stesso e attende un tempo casuale;

3. Il Receiver prende il timestamp di risposta, lo inserisce nel pacchetto e lo rimanda al Sender passandolo al middleware;

4. Il Sender riceve il pacchetto, controlla se effettivamente `e destinato a lui, prende il timestamp di arrivo e calcola il Round-Trip Time dell’evento mediante la formula seguente

RTT Evento = (Timestamp Arrivo – Timestamp Invio) – (Timestamp Risposta – Timestamp Ricezione)

Ovviamente il tempo di attesa casuale non influenza il Round-Trip Time dell’evento in quanto viene eliminato nel calcolo (Timestamp Risposta – Timestamp Ricezione). Il tempo casuale di attesa `e indispensabile nel caso che nella comunicazione siano coinvolti molti nodi o che la frequenza d’invio d’eventi sia elevata: esso evita che il Sender sia

“tempestato” (flooding) dalle risposte dei receiver, d’altro canto per`o se il rate d’invio

`e molto alto si rischia di consumare troppe risorse per i thread che rimangono in attesa in memoria. Inoltre tale protocollo `e efficace se sono vere le seguenti precondizioni:

1In questo contesto ogni lato del programma è sia un publisher che subscriber. Per brevità si chiamerà Publisher o Sender il lato che invia dati e Subscriber o Receiver il lato che li riceve e ne fa echo

2RTT - Round-Trip Time

(36)

30

CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB 1. Il canale è simmetrico, ovvero la probabilità di perdita da Sender a Receiver è la

stessa da Receiver a Sender;

2. I pacchetti di echo sono della stessa dimensione delle sonde, altrimenti la latenza non è più pari alla metà del Round-Trip Time;

5.4.1 Sviluppo del programma

Lo sviluppo del programma ha preso piede dalla scrittura del file IDL (Interface Descrip- tion Language), ovvero un file che descriva in un linguaggio standard, le caratteristiche dei dati che si vogliono trasmettere. Per implementare il protocollo illustrato pocanzi, l’IDL dovr`a contenere, almeno i seguenti campi:

Sequence Number - Numero di sequenza del campione, `e necessario per capire quali pacchetti sono arrivati, quali no, permettendo di misurare le perdite che si verificano;

Subscriber ID - Un numero identificativo per il Receiver. Quando questi riceve un pacchetto dal Sender, apporrà il suo ID (un numero intero scelto al momento di avviare il processo) in questo campo. Il Sender smisterà le risposte tramite questo ID e metterà in un file tutti i Round-Trip Time degli eventi provenienti dallo stesso ID, bisogna quindi porre attenzione che non vi siano più receiver con lo stesso ID;

Publisher ID - Un numero identificativo per il Sender. Il Sender deve essere in grado di distinguere quali pacchetti sono risposte alle sonde da esso lanciate. Prima di inviare una sonda copia il suo ID all’interno della stessa, se riceve una risposta che contiene il suo ID allora la prende in considerazione e procede alla computazione, altrimenti la scarta.

Timestamp Send - Il momento in cui il Sender passa l’evento al Middleware. Si noti che non corrisponde al momento in cui il Middleware invia effettivamente il dato, ma al momento in cui lo invia l’applicazione.

Timestamp Receive - Il momento in cui il Middleware restituisce l’evento al Recei- ver. Anche in questo caso non `e esattamente il momento in cui il Middleware riceve il dato, bens`ı l’applicazione.

Timestamp Reply - Il momento in cui il Receiver rispedisce l’evento al Sender. Come sopra anche qui si tratta di evento notificato dall’applicazione..

Payload - Dati fittizi usati per accrescere la taglia del pacchetto fino alle dimensioni richieste.

Una volta scritto il file IDL, RTI DDS fornisce l’utility rtiddsgen che passando tra le opzioni l’architettura e “-example” compila il file IDL e fornisce il codice di un

(37)

rudimentale sistema Pub/Sub che scambia pacchetti del tipo specificato nell’idl stesso.

Per cui il comando eseguito `e:

rtiddsgen -language C++ -example i86Linux2.6gcc3.4.3 NDDS testing.idl dove:

-language C++ specifica il linguaggio di programmazione in cui si vogliono i sorgenti;

-example indica ad rtiddsgen di generare codice di esempio;

i86Linux2.6gcc3.4.3 indica l’architettura del sistema, set di istruzioni intel x86, OS Linux Kernel 2.6, Gnu C Compiler 3.4.3;

NDDS testing.idl file IDL dal quale prendere la struttura dei dati, NDDS testing sar`a, inoltre, il nome del programma;

A questo punto si passa a modificare il codice ottenuto, implementandoci la logica del programma di test.

5.4.2 Logica del programma

Il programma deve implementare due topic: uno per l’invio delle “sonde” dai Sender (ndds testing publisher) verso i Receiver (ndds testing subscriber), l’altro per l’invio dei messaggi di “echo” dai Receiver verso i Sender.

Si vuole ottemperare a numerose topologie di comunicazione, in cui si possono trovare numerosi Sender e Receiver, volendone sapere per ogni coppia Sender/Receiver la latenza presente. La situazione pu`o quindi essere schematizzata come in figura 5.1.

Ogni Sender deve essere identificato dagli altri da un numero, come pure ogni Re- ceiver. In questo modo `e possibile stabilire chi debba ricevere cosa. Soluzioni per cui si istanzia un canale logico (ovvero un Topic) per ogni coppia di Sender/Receiver impedi- rebbero di vedere il comportamento di tanti partecipanti che insistono sullo stesso Topic.

Il problema di questo approccio risiede nel fatto che i processi ndds testing publisher ri- cevono anche le risposte sonda degli altri ed è l’applicazione a doverle scartare. D’altro canto sarebbe possibile effettuare questo a lato Middleware con l’aggiunta di istanze identificate da chiavi. Poichè però i nostri test non richiedono un elevato numero di Publisher, è accettabile la ricezione dei dati da parte di tutti.

Considerando il caso di soli tre nodi (per maggiore semplicit`a) il protocollo di comunicazione pu`o essere schematizzato come in figura 5.2:

Il Round-Trip Time per la coppia (A, B) sar`a dunque:

RT T_(A,B) = (T imestampArrive_(B)− T imestampSend) − (T imestampReply_(B)− T imestampReceive_(B))

Per la coppia (A, C) `e del tutto identico:

RT T_(A,C)= (T imestampArrive_(C)− T imestampSend) − (T imestampReply_(C)− T imestampReceive_(C))

(38)

32

Figura 5.1: Logica del programma di test NDDS testing

Figura 5.2: Sequenza dei timestamp

Facilemente generalizzabile ad un numero qualsiasi di partecipanti. Notare che L’invio del pacchetto marcato dal Timestamp Send non `e contemporaneo per ogni Receiver in gioco: esso `e deciso dal Middleware e fa parte delle sue performance.

(39)

5.4.3 Implementazioni e scelte architetturali

Il programma di test utilizza alcuni semafori per la sincronizzazione e la mutua esclusione su intervalli di codice critico, inoltre, la gestione dei segnali per lo shutdown delle entit`a istanziate dal middleware e la pulizia dei semafori utilizzati. La sincronizzazione

è intesa come l’attesa da parte dei partecipanti che tutti siano pronti alla comunica- zione: il publisher deve pubblicare dati solo dopo che ha trovato (Discovery) tutti i subscriber che si vuole partecipino alla comunicazione e viceversa. Per fare ciò si mette in wait() del numero di subscriber (rispettivamente publisher) il programma che invia (rispettivamente riceve) dati. Ogni volta che il middleware notifica una nuova sotto- scrizione (metodo on subscription found) si lancerà una signal(). Quando tutti saranno stati scoperti, il test si avvierà.

L’aspetto che risulta essere maggiormente critico è la concorrenzialità di gestione dei dati in invio e ricezione. Mentre per l’invio è sufficiente passare il dato al middleware che provvederà a consegnarlo a destinazione, per la ricezione bisogna preoccuparsi di togliere i dati ricevuti dalla coda del middleware nel minor tempo possibile.

Poich´e RTI Data Distribution Service notifica la ricezione di un dato con il metodo on data available() del DataReaderListener, ma non istanzia un nuovo thread per ogni dato, eseguire la take()³ all’interno del metodo implica che i dati successivi debbano aspettare il tempo di gestione dei dati precedenti. Spetta all’applicazione invocare la creazione di un nuovo thread e solo questo, nel codice del metodo on data available. In questo modo ogni volta che un dato viene ricevuto dal middleware si attiva un nuovo thread per cui il tempo di gestione si riduce al ritardo necessario all’istanziazione del nuovo thread, mentre il metodo di gestione specifico del programma di test (output dei tempi su file lato sender e echo lato receiver) pu`o essere eseguito concorrenzialmente.

La figura 5.3 illustra l’architettura del programma di test: il lato sender passa i dati al middleware che provvede ad inviarli sulla rete, essi raggiungeranno il receiver che istanzierà un thread di gestione per ogni dato che giunge. il thread viene posto in attesa di un tempo casuale (in un intervallo configurabile) dopo di che passa i dati con le opportune modifiche al middleware che li riporterà al sender. Questo instanzierà a sua volta un thread per ogni dato che riceve, calcolerà il Round-Trip Time e lo scriverà su un file. Al termine del test il sender avvia una procedura che prende i file e ne tira fuori un ultimo contenente i parametri richiesti: media, devianza standard, minimo, massimo del Round-Trip Time e perdite di eventi.

Utilizzando un modello multithread si deve porre attenzione a diverse caratteristiche: la scrittura sui file deve avvenire in mutua esclusione, per cui occorre un semaforo mutex, inoltre tanto maggiore `e l’intervallo di attesa per l’invio di una risposta da parte del receiver, tanti pi`u thread si troveranno contemporaneamente attivi e “dormienti”

in memoria. Su questo secondo punto si rischia di incappare in un fallimento nella creazione di un nuovo thread, eventualit`a che dipende fortemente dal sistema.

3La take() `e una chiamata che prende i dati dal middleware, li passa all’applicazione e li elimina dalle code di ricezione

(40)

34

Publish/Subscribe API

Publish/Subscribe Middleware RTI Data Distribution Service

Applicazione lato sender

Publish

Thread di gestione

Thread di gestione ...

Subscribe

Network

Publish/Subscribe API

Publish/Subscribe Middleware RTI Data Distribution Service

Subscribe

Thread di gestione

Thread di gestione ...

Publish Applicazione lato receiver

Figura 5.3: Architettura del programma di test

5.5 Come utilizzare il programma

Per eseguire i test `e sufficiente copiare gli eseguibili sui nodi interessati, a patto che le librerie con cui `e stato compilato siano compatibili con quelle presenti sul nodo.

E importante che il file NDDS DISCOVERY PEERS sia presente e contenga alcuni` indirizzi IP dei nodi destinatari. Il processo di discovery del middleware sar`a in grado di trovare gli altri, come confermato dai test eseguiti.

Queste di seguito sono le linee usate per effettuare l’upload, la connessione e il test sui nodi. Sono da considerarsi a scopo d’esempio:

rsync -v -u -a --stats ∼NDDS testing/objs/i86Linux2.6gcc3.4.3/ uniroma - orte@planetlab-1.dis.uniroma1.it:∼/NDDS testing

Utilizzando rsync solo i file aggiornati vengono caricati sul nodo, richiede che esista una chiave ssh nella directory ∼/.ssh per autenticarsi.

ssh -i ∼/.ssh/identity uniroma orte@planetlab-1.dis.uniroma1.it

(41)

5.5. COME UTILIZZARE IL PROGRAMMA 35

Si usa ssh per accedere al nodo sul quale `e stato caricato il programma e si entra nella directory, precedentemente creata da rsync con

cd NDDS testing

A questo punto si pu`o lanciare il test. Se il nodo designato gioca il ruolo di un Publisher⁴ allora la linea di comando sar`a sulla falsa riga della seguente:

./ndds testing publisher -d 77 -n 100 -i 1 -subscribers 4 -lifespan 15 -sendPeriod 1000 -fragSize 4096 -minSize 16 -maxSize 131072 -roundWait 120 -reliable

Per un Subscriber invece

./ndds testing subscriber -d 77 -n 0 -lifespan 15 -fragSize 4096 -minWait 50 -maxWait 15000 -noOutput -i 1 -reliable

Nel prossimo paragrafo si illustrer`a come agire sui parametri per ottenere l’ambiente di test deisderato.

5.5.1 Opzioni configurabili da riga di comando

Poich´e il programma deve essere eseguito sui nodi PlanetLab tramite una sessione SSH⁵ esso deve essere configurabile il pi`u possibile tramite argomenti da riga di comando. Le funzioni implementate possono essere scelte e configurate tramite le seguenti opzioni⁶:

• Lato Sender (ndds testing publisher)

-h , --help , -help Mostra a video come utilizzare il programma con tutte le opzioni disponibili;

-n , --numIter {count} Permette di impostare quanti campioni, quante itera- zioni eseguire per ogni taglia;

-minSize {size} Permette di impostare a {size} Bytes la minima taglia del campione;

-maxSize {size} Permette di impostare a {size} Bytes la massima taglia a cui il test deve portare i campioni;

4In questo contesto ogni lato del programma è sia un publisher che subscriber. Per brevità si chiamerà Publisher o Sender il lato che invia dati e Subscriber o Receiver il lato che li riceve

5Secure shell

6Tra parentesi graffe {} verranno indicati parametri da poter impostare, separati da virgola quando in OR logico, ovvero `e possibile usare indistintamente le opzioni separate da una virgola