Test di RTI Data Distribution Service utilizzando PlanetLab
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`a limitato a 3. Per le altre due sca-le, invece, vi sar`a maggiore flessibilit`a 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 midd-leware sia scalabile, in special modo su un ambiente di vaste dimensioni geografiche. Aumentare la velocit`a di pubblicazione degli eventi mostrer`a, 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`a 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
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 `e 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 inviate1. La latenza sar`a dunque la met`a del tempo impiegato dalla sonda a muoversi dal publisher fino a tornarci2. Ovviamente bisogna minimizzare quanto pi`u 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, `e 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 `e sia un publisher che subscriber. Per brevit`a si chiamer`a Publisher o Sender il lato che invia dati e Subscriber o Receiver il lato che li riceve e ne fa
echo
30
CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB
1. Il canale `e simmetrico, ovvero la probabilit`a di perdita da Sender a Receiver `e la stessa da Receiver a Sender;
2. I pacchetti di echo sono della stessa dimensione delle sonde, altrimenti la latenza non `e pi`u pari alla met`a 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 qua-li pacchetti sono arrivati, quaqua-li 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`a il suo ID (un numero intero scelto al momento di avviare il processo) in questo campo. Il Sender smister`a le risposte tramite questo ID e metter`a in un file tutti i Round-Trip Time degli eventi provenienti dallo stesso ID, bisogna quindi porre attenzione che non vi siano pi`u 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
5.4. SCRITTURA DEL PROGRAMMA DI TEST 31 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 `e l’applicazione a doverle scartare. D’altro canto sarebbe possibile effettuare questo a lato Middleware con l’aggiunta di istanze identificate da chiavi. Poich`e per`o i nostri test non richiedono un elevato numero di Publisher, `e 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)−
32
CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB
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.
5.4. SCRITTURA DEL PROGRAMMA DI TEST 33
5.4.3 Implementazioni e scelte architetturali
Il programma di test utilizza alcuni semafori per la sincronizzazione e la mutua esclu-sione 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 `e 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`o 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`a una signal(). Quando tutti saranno stati scoperti, il test si avvier`a.
L’aspetto che risulta essere maggiormente critico `e la concorrenzialit`a di gestione dei dati in invio e ricezione. Mentre per l’invio `e sufficiente passare il dato al midd-leware che provveder`a a consegnarlo a destinazione, per la ricezione bisogna preoccu-parsi 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()3 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`a 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`a al sender. Questo instanzier`a a sua volta un thread per ogni dato che riceve, calcoler`a il Round-Trip Time e lo scriver`a 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 caratteristi-che: 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
34
CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB
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.
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
Publisher4 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 SSH5
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 opzioni6:
• 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 `e sia un publisher che subscriber. Per brevit`a si chiamer`a 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
36
CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB
-fragSize {size} Permette di impostare a {size} Bytes la dimensione dei fram-menti in caso di pacchetti troppo grandi;
-stepSize {size} Permette di impostare di {size} Bytes la dimensione dei cam-pioni ad ogni passo;
-rs , --reliableSend Indica al programma se il canale di invio debba essere affidabile;
-rr , --reliableReply Indica al programma se il canale di echo debba essere affidabile;
-reliable Indica che entrambi i canali devono essere affidabili; -noStrict Usa affidabilit`a con parametri di default;
-subscribers {count} Attende che siano presenti in comunicazione {count} Receiver;
-debug Attiva output aggiuntivo per rilevare eventuali problemi;
-noOutput Disattiva l’output a video (se -debug attivo i messaggi di debug appaiono comunque);
-d , --domain {domainid} Imposta il dominio RTI DDS dell’applicazione; -i , --index {id} Specifica un indice che distingue fra i Sender attivi;
-sendPeriod {milliseconds} Attende {milliseconds} millisecondi tra l’invio di un campione ed il successivo;
-hearbeatPeriod {milliseconds} Invia un heartbeat ogni {milliseconds} mil-lisecondi (usato solo in reliable);
-lifespan {seconds} Elimina dalle code un campione dopo {seconds} secondi; -deadline {seconds} Indica il massimo tempo accettabile tra l’invio di un
cam-pione ed il successivo;
-writerQueue {samples} Imposta la lunghezza della coda del DataWriter a
{samples} campioni;
-readerQueue {samples} Imposta la lunghezza della coda del DataReader a
{samples} campioni;
-roundWait {seconds} Imposta {seconds} secondi di attesa tra un round di campioni di una certa taglia e il round successivo di taglia maggiore;
• Lato Receiver (ndds testing subscriber)
-h , --help , -help Mostra a video come utilizzare il programma con tutte le opzioni disponibili;
-n , --numIter {count} Permette di impostare quanti campioni attendere pri-ma di terminare il programpri-ma;
-fragSize {size} Permette di impostare a {size} Bytes la dimensione dei fram-menti in caso di pacchetti troppo grandi;
5.5. COME UTILIZZARE IL PROGRAMMA 37 -rc , --reliableReceive Indica al programma se il canale di ricezione debba
essere affidabile;
-rr , --reliableReply Indica al programma se il canale di echo debba essere affidabile;
-reliable Indica che entrambi i canali devono essere affidabili; -noStrict Usa affidabilit`a con parametri di default;
-publishers {count} Attende che siano presenti in comunicazione {count} Sen-der;
-debug Attiva output aggiuntivo per rilevare eventuali problemi;
-noOutput Disattiva l’output a video (se -debug attivo i messaggi di debug appaiono comunque);
-d , --domain {domainid} Imposta il dominio RTI DDS dell’applicazione; -i , --index {id} Specifica un indice che distingue fra i Receiver attivi;
-sendPeriod {milliseconds} Attende {milliseconds} millisecondi tra l’invio di un campione ed il successivo;
-hearbeatPeriod {milliseconds} Invia un heartbeat ogni {milliseconds} mil-lisecondi (usato solo in reliable);
-lifespan {seconds} Elimina dalle code un campione dopo {seconds} secondi; -deadline {seconds} Indica il massimo tempo accettabile tra la ricezione di un
campione ed il successivo;
-writerQueue {samples} Imposta la lunghezza della coda del DataWriter a
{samples} campioni;
-readerQueue {samples} Imposta la lunghezza della coda del DataReader a
{samples} campioni;
-minWait {milliseconds} Imposta l’attesa minima prima di rispondere al Sen-der;
-maxWait {milliseconds} Imposta l’attesa massima prima di rispondere al Sender;
38
CAPITOLO 5. TEST DI RTI DATA DISTRIBUTION SERVICE UTILIZZANDO PLANETLAB