Modellazione dello standard OMG RTPS mediante OMNeT++

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica

Modellazione dello standard OMG RTPS con il simulatore OMNeT++ Anno Accademico 2006/2007 relatore Ch.mo prof. Stefano Russo correlatore ing. Christiancarmine Esposito candidato Francesco Melillo matr. 885/54

a mio fratello Gianni per il

sostegno nei momenti di difficoltà,

ai miei genitori ed

a chi merita i miei ringraziamenti

III

Indice Introduzione 5 Capitolo 1. Standard OMG RTPS 7 1.1 Modello Publish-Subscribe ed OMG DDS (Data Distribution Service) 8 1.2 OMG RTPS (Real-Time Publish-Subscribe) 12 1.2.1 Il modulo Structure 15 1.2.2 Il modulo Message 16 1.2.3 Il modulo Behaviour 19 1.2.4 Il modulo Discovery 24 1.3 Platform Specific Model (PSM): UDP/IP 27 1.4 Quality of Service 28 Capitolo 2. I simulatori e la simulazione 31 2.1 Caratteristiche di modellizzazione 32 2.2 Classificazione dei simulatori 34 2.3 Simulatori analizzati 35 2.3.1 Shawn 35 2.3.2 Algosensim 36 2.3.3 Opnet 37 2.3.4 Smurph 38 2.3.5 NS-2 39 2.3.6 Glomosim 39 2.3.7 J-Sim 40 2.3.8 OMNeT++ 41 2.3.9 Mobius 42 2.4 Scelta del simulatore da usare 42 2.5 Il simulatore OMNeT++ 45 2.5.1 Il linguaggio NED 48 2.5.2 Il sistema di simulazione ad eventi discreti 49 2.5.3 La macchina a stati finiti 52 2.5.4 I messaggi 52 2.5.5 L’architettura 53 2.6 INET framework 55

IV

Capitolo 3. Descrizione del modello 61 3.1 Descrizione delle entità 62 3.2 Moduli OMNeT++ 69 3.3 Funzionamento del modello 72 Capitolo 4. Risultati sperimentali 90 4.1 Valutazioni sulla scalabilità 90 4.2 Validazione del modello 98 4.3 Confronto con il funzionamento multicast 101 Conclusioni 109 Sviluppi futuri 110 Appendice A. Utilizzare OMNeT++ 111 Appendice B. Tabelle relative ai risultati sperimentali 113 Bibliografia e Webgrafia 133

5

Introduzione

Il presente lavoro di tesi si è svolto nell’ambito del progetto COSMIC, laboratorio

pubblico-privato dei partner CINI ITEM, CRIAI, DIS-UNINA, SELEX-SI e SESM.

Lo studio di soluzioni per sistemi Near Real-Time e Mission Critical, oggigiorno sta

assumendo un forte interesse in ambito industriale ed accademico. Queste soluzioni si

prevede che saranno adottate nell’ambito del controllo e della gestione del traffico aereo.

Questo lavoro di tesi affronta una modellazione dello standard OMG RTPS (Real-Time

Publish-Subscribe protocollo per l’interoperabilità per il DDS) mediante il simulatore

OMNeT++.

L’esigenza della realizzazione di un modello simulativo per OMG RTPS, nasce dalla

necessità di valutare il comportamento del protocollo in differenti scenari operativi (LAN

e WAN). Si è scelto un modello simulativo come strumento di analisi, dal momento che

spesso è difficile e costoso operare una tale valutazione su reti reali. L’obiettivo dei test

condotti è stato quello di analizzare le seguenti proprietà:

l’entità dei ritardi di trasmissione, nel caso di reti ideali e soggette a perdite di pacchetti;

perdita di pacchetti in caso di trasmissione best-effort e reliable;

l’andamento del carico generato sulla rete all’aumentare del numero di nodi in termini

di messaggi generati.

Il primo capitolo della tesi introduce il contesto in cui si svolge l’attività svolta ed offre

Modellazione dello standard OMG RTPS con il simulatore OMNeT++

6

una breve descrizione del modello Publish-Subscribe e dello standard OMG DDS, per poi

soffermare maggiormente l’attenzione sullo standard OMG RTPS.

Il secondo capitolo introduce al problema della simulazione ed aiuta a comprendere le

esigenze che hanno spinto a realizzare questo modello, in base alle quali si effettua un

confronto dei diversi simulatori presenti sul mercato, motivando la scelta di OMNeT++.

Il terzo capitolo offre una breve descrizione del modello e del suo funzionamento, la

descrizione di alcune soluzioni implementate.

Il quarto capitolo descrive come si è valutata la scalabilità ed effettuata la validazione del

modello implementato. Il modello realizzato è stato validato mediante un'implementazione

commerciale di OMG RTPS (ORTE): è stata calcolata la mediana della latenza di

trasmissione, e determinata l'entità dell'errore di simulazione. Inoltre, si è operato uno

studio della scalabilità del protocollo, calcolando l'incremento del numero di messaggi

inviati, il tempo di latenza e l’occupazione di memoria.

Alla luce dei risultati ottenuti sono state effettuate delle considerazioni finali, mostrando

sia i vantaggi sia i limiti del modello, nonché del protocollo OMG RTPS stesso fornendo

una panoramica su possibili studi futuri.

E’ fornita una breve appendice per l’istallazione e l’utilizzo di OMNeT++ e della

successiva integrazione di INET su macchine Linux. Un’altra appendice contiene i dati

numerici dei test effettuati.

7

Capitolo 1 Standard OMG RTPS

I sistemi distribuiti mission and safety critical sono diventati un obiettivo centrale della

ricerca, data la loro crescente richiesta in contesti quali sistemi di controllo, sistemi di

allarme o gestione del traffico aereo (Air Traffic Management, ATM ).

I requisiti principali sono i seguenti [10]:

real-time: i dati devono essere trasmessi garantendo una latenza minima possibile che

sia predicibile e non superi un certo limite temporale;

fault-tolerance: garantire la trasmissione dei dati anche in presenza di guasti nei

componenti;

flessibilità: aggiunta di nuove applicazioni e funzionalità senza dover interrompere il

funzionamento del sistema;

scalabilità: caratteristica di un sistema di non peggiorare le proprie prestazioni

all’aumentare delle dimensioni del sistema stesso.

I primi due requisiti sono tra loro contrastanti: le operazioni in tempo reale richiedono un

comportamento predicibile, OMG RTPS introduce ridondanza delle trasmissioni che

possono introdurre elementi di impredicibilità. Per questo motivo le applicazioni

progettate tendono a focalizzare l’attenzione sugli aspetti funzionali del sistema,

prescindendo dai dettagli legati alla comunicazione.

Nell’esempio del controllo del traffico aereo, i dati necessitano di essere ricevuti e

distribuiti in tempo reale in ogni istante di tempo, altrimenti il sistema rischierebbe di non


8

essere in grado di fronteggiare una situazione di pericolo.

Le soluzioni attualmente adottate per questo tipo di applicazioni hanno la caratteristica di

essere estremamente verticali, ma poco estendibili, ecco perchè l’utilizzo di tecnologie

middleware è la soluzione più consona per rispondere a caratteristiche di interoperabilità

ed apertura, anche se i requisiti di qualità del servizio richiesti non sempre sono garantiti

contemporaneamente. Ad esempio, gli standard FT-CORBA e RT-CORBA (estensione

della piattaforma CORBA) offrono isolatamente una soluzione ai problemi di tolleranza ai

guasti e di tempo reale, ma essi non sono integrabili fra loro, quindi non è possibile

garantire contemporaneamente entrambe le caratteristiche [26]. Attualmente la soluzione

che offre le migliori risposte a queste esigenze è quella basata sul paradigma Publish-

Subscribe.

1.1 Modello Publish-Subscribe e OMG DDS (Data Distribution Service)

Le principali architetture di comunicazione sono due: client-server e publish-subscribe.

L’architettura client-server mette in comunicazione due o più nodi, il nodo client inizia la

comunicazione, il nodo server attende che uno o più nodi client richiedano un servizio.

Essa funziona bene quando i dati sono tutti localizzati su un server centrale, ma nel caso

di nostro interesse sarebbe inefficiente, perché i dati sono prodotti da molti nodi e sono

consumati da molti nodi.

Il modello Publish-Subscribe [7] mette in relazione i produttori di informazioni

(Publisher) con i rispettivi consumatori (Subscriber). Tutte le applicazioni distribuite del

modello si compongono di processi, ognuno dei quali è eseguito in un differente spazio di

indirizzamento (possibilmente su macchine differenti). Ognuno di questi processi è

chiamato Participant, esso può sia pubblicare che sottoscrivere informazioni [2]. Un

aspetto fondamentale del modello è il disaccoppiamento nello spazio, nel tempo e nella

sincronizzazione tra publisher e subscriber.


9

Figura 1 - Modello Publish-Subscribe

Il meccanismo di comunicazione, evolve in tre stadi [7]:

il Publisher dichiara l’intenzione di pubblicare un dato;

il Subscriber dichiara l’interesse ad utilizzare un dato pubblicato;

il Publisher invia la pubblicazione.

I servizi utilizzati sono resi disponibili alle applicazioni attraverso il middleware, situato

sull’interfaccia di rete del sistema operativo, utilizzando un Application Programming

Figura 2 - Interazioni del middleware e delle API


10

Interface (API), per consentire alle applicazioni di inviare e ricevere pubblicazioni con

poche semplici chiamate, mascherando la complessità dell’operazione.

Le informazioni trasferite si classificano in Signal, Stream e State [2]. Signal rappresenta

informazioni di segnalazione che mutano in continuazione (tipicamente best-effort),

Stream rappresenta il valore ad un dato istante di tempo di un data-object (talvolta

reliable), State rappresenta lo stato di un insieme di oggetti (o sistemi) in un dato istante di

tempo.

Il paradigma publish-subscribe si propone come una possibile soluzione per sistemi

distribuiti mission and safety critical, poichè riduce le dipendenze software dalle

piattaforme e dai contesti operativi ed è la soluzione migliore per soddisfare esigenze di

scalabilità, poiché consente una comunicazione del tipo molti a molti [2].

Lo standard OMG Data Distribution Service (DDS), rilasciato nel 2001 dall’OMG [2],

rappresenta la descrizione di un middleware basato sul modello publish-subscribe, esso

facilita la distribuzione efficiente dei dati in un sistema distribuito.

Le proprietà che lo standard OMG DDS si propone di garantire sono le seguenti [24]:

efficienza: mantenere al minimo l'overhead introdotto dai meccanismi di

comunicazione;

determinismo: il tempo di inoltro dei dati deve essere predicibile;

flessibilità nell'uso della banda: garantire un'allocazione ottima della banda

disponibile;

fault-tolerance: ridondanza dell'hardware e garantire il superamento dei faults anche

via software;

flussi di dati: supporto alla comunicazione multi punto.

Le specifiche adottate inerenti il Data-Distribution Service definiscono due livelli di

interfacce [2]:

un livello più basso, Data-Centric Publish-Subscribe (DCPS), che provvede alla

consegna in maniera efficiente delle informazioni, instradando i messaggi, usando una

comunicazione basata su di uno spazio globale dei dati anche in relazione agli attributi

di qualità del servizio;


11

un livello più alto opzionale, Data-Local Reconstruction Layer (DLRL), per consentire

un'integrazione più agevole a livello applicativo, consentendo di accedere ai dati come

se fossero locali.

Lo standard OMG DDS definisce una Model Driven Architecture (MDA) per descrivere i

modelli di comunicazione Data-Centric. Esso specifica un’infrastruttura indipendente dalla

piattaforma (PIM), mediante la quale si costruisce un modello che risponde alle specifiche

della propria applicazione e della propria piattaforma (Platform Specific Model, PSM).

Questa infrastruttura, mediante il DDS, introduce nel sistema la nozione di qualità del

servizio offerta. Ogni entità del sistema può specificare i requisiti per un funzionamento

ottimale, consentendo al servizio di definire un’allocazione efficiente delle risorse [24].

Il DDS consente all’applicazione di usare un modello di programmazione molto semplice,

infatti i dati da scambiare sono identificati usando i topic (identificativo che individua una

dato in maniera univoca, all’interno di uno spazio dei dati globale), accedendo ai dati

mediante semplici operazioni di lettura e scrittura. I dati all’utente appaiono disposti in

uno spazio globale, ma di fatto sono presenti nelle cache locali ad ogni utente [7]. In figura

è mostrato il meccanismo Publish-Subscribe con l’uso di differenti topic (Alarm, Temp,

Pressure) mediante i quali è possibile identificare univocamente ogni data-object nello

spazio globale dei dati.

In particolare lo standard OMG DDS per descrivere i modelli Data-Centric specifica [1]:

come l'applicazione modella i dati che deve inviare e ricevere, definendo e

descrivendo il dato in un formato standard (ad esempio XML o IDL) ed attribuendo un

Figura 3 - Meccanismo Publish/Subscribe


12

topic, mediante il quale è possibile sottoscrivere un dato,. Questo caratteristiche

conferiscono la proprietà di apertura al sistema;

come l'applicazione interagisce con il DCPS middleware e specifica i dati da inviare e

ricevere, rispettando determinate specifiche di QoS;

come i dati sono inviati e ricevuti;

come l'applicazione accede ai dati ed il tipo di feedback, relativamente allo stato del

middleware.

La specifica DDS include anche una piattaforma specifica per IDL, inoltre un'applicazione

che usa DDS è abilitata a passare da un'implementazione DDS ad un'altra, mediante una

semplice ricompilazione, supportando quindi la portabilità dell'applicazione [1].

1.2 OMG RTPS (Real-Time Publish-Subscribe)

La specifica OMG DDS non prevede lo scambio di messaggi sui protocolli di livello

trasporto (come TCP o UDP), per cui tra implementazioni DDS diverse non è possibile

cooperazione, eccetto che non siano realizzate applicazioni proprietarie che offrano questo

tipo di servizio. L'uso di DDS è orientato ai sistemi distribuiti, per questo è necessaria la

definizione di uno standard “wire protocol” che permette ad implementazioni DDS di

molteplici venditori di interoperare. In particolare, il DDS wire protocol deve supportare

comunicazioni sia unicast che multicast, sia best-effort che reliable e funzionare in

modalità connectionless [1].

Con l’utilizzo del DDS in sistemi distribuiti di grosse dimensioni, è maturata l’esigenza di

uno standard che consenta alle implementazioni DDS di venditori diversi di interoperare.

Questo protocollo deve essere capace di utilizzare le QoS del livello DDS [1].

La nascita del protocollo di comunicazione OMG RTPS (Real Time Publish Subscribe) è

legata all’automazione industriale, esso è stato standardizzato per supportare i requisiti di

un DDS (Data Distribution System). Attualmente RTPS è realizzato per numerose

applicazioni di tipo industriale (come applicazioni di visione industriale), rappresenta lo

standard OMG per l'interoperabilità tra differenti implementazioni DDS ed è stato adottato


13

dalle due principali implementazioni commerciali del DDS, DDS della Real-Time

Innovations (RTI) ed OPEN SPLICE DDS della Prismtech [8].

RTPS rispetta i principi fondamentali su cui si basa lo standard DDS [1]:

garantire performance e caratteristiche di QoS. Lo scopo è quello di consentire una

comunicazione sia best-effort che reliable, basata sul paradigma publish-subscribe,

conferendo caratteristiche di tipo real-time al modello, ovvero ponendo dei vincoli sui

tempi di inoltro delle informazioni, utilizzando comunque reti IP;

la flessibilità, possibilità di incrementare i servizi offerti, senza degradare le

prestazioni;

la fault tolerance, per permettere la creazione di reti affidabili e senza single point of

failure;

plug and play connectivity, ovvero la capacità di aggiungere ed eliminare nuovi nodi,

nonchè applicazioni e servizi senza effettuare una riconfigurazione, garantendo una

comunicazione trasparente;

l'estensibilità, per consentire l'estensione di servizi preesistenti, mantenendo la

compatibilità all'indietro e l'interoperabilità;

la configurabilità per consentire di settare i requisiti di reliability e di timeliness;

la modularità, per consentire a diverse tipologie di dispositivi di poter implementare un

sottoinsieme delle funzionalità, garantendo comunque l'interoperabilità;

la scalabilità, per consentire un eventuale aumento dei nodi senza degradare le

prestazioni in maniera significativa;

type-safety, per prevenire che errori a livello di programmazione compromettano le

funzionalità dei nodi remoti.

RTPS introduce funzionalità aggiuntive alle tradizionali architetture Publish-Subscribe,

mediante parametri e proprietà sul tempo, per consentire un controllo su differenti tipi di

flussi di dati, garantendo prestazioni ed affidabilità.

Il protocollo RTPS è descritto mediante due modelli:

un modello indipendente dalla piattaforma (PIM) che descrive il protocollo nei termini

di una macchina virtuale;


14

un insieme di modelli specifici per la piattaforma (PSM), mappando molti concetti

dello standard OMG DDS.

L'RTPS PIM si compone di quattro moduli: Structure, Message, Behaviour e Discovery

[1]. La struttura modulare conferisce maggiore flessibilità ed interoperabilità al protocollo,

facilità nell’effettuare estensioni future, consentendo una chiara distinzione dei ruoli ai

diversi moduli. I moduli Structure e Message sono moduli che definiscono le entità della

comunicazione ed i contenuti scambiati, il modulo Structure consente il naturale

interfacciamento di RTPS con le entità DDS, poiché effettua una mappatura diretta delle

stesse con le entità RTPS. Il modulo di Behaviour definisce la dinamica del protocollo. In

questo modulo è garantita l’interoperabilità mediante requisiti minimi che possono anche

essere estesi dall’implementatore. Il modulo di Discovery definisce le politiche secondo le

quali le entità sono automaticamente scoperte e configurate. Quest’ultimo è il modulo che

concede un maggiore grado di libertà a coloro che vogliano implementare il protocollo

RTPS, poiché lascia spazio all’introduzione di soluzioni alternative per effettuare il

discovery.

Figura 4 - Moduli RTPS

DDS Discovery

Behaviour

Structure Message


15

1.2.1 Il modulo Structure

Il modulo Structure definisce gli endpoint della comunicazione. Esso mappa molte

strutture ed entità definite nella specifica OMG DDS [1]. Ogni entità RTPS si trova

all’interno di un Dominio RTPS, che rappresenta un piano di comunicazione separato e

che contiene un insieme di Participant (entry-point per il servizio e container di altri

oggetti come gli endpoint [24]), essi a loro volta contengono gli Endpoint di

comunicazione locali, sorgente o destinazione dei messaggi RTPS e possono essere di due

tipi: Writer e Reader. Poiché i dati possono assumere differenti tipi, per ogni tipo è creato

un Writer, essi dopo aver annunciato la loro presenza, inviano i dati che sono disponibili

localmente nel dominio al Reader corrispondente. I Reader richiedono i dati disponibili

localmente nel dominio ed eventualmente riscontrano il dato ricevuto. Ogni endpoint è

caratterizzato da una cache locale, detta HistoryCache che costituisce l'interfaccia tra le

entità DDS e le entità RTPS e consente la ritrasmissione dei dati in caso di perdita. Ogni

operazione di scrittura sul DDSDataWriter aggiunge un CacheChange (cambiamento fatto

su un Data-Object) alla corrispondente HistoryCache dell' RTPS Writer. Il CacheChange è

trasmesso sulla rete all'interno di un messaggio RTPS dal Writer ed è quindi inserito nella

HistoryCache del Reader alla quale può accedere il DDSDataReader mediante apposite

API, effettuando operazioni di lettura o prelievo. Dal lato Publisher, la HistoryCache

contiene per un periodo di tempo limitato, la storia parziale dei dati (data-object)

modificati dal Writer e necessari ai Reader già esistenti o anche futuri. Dal lato Receiver,

invece, contiene la storia parziale dei dati modificati da tutti i Writer di interesse. Il

sottoinsieme dei cambiamenti dei quali è necessario conservare un’immagine, dipende

dalle politiche di QoS settate a livello delle entità DDS [1].

Osservando questo modulo, si nota l’attenzione dedicata in fase di progettazione per

conferire una natura estendibile alle entità della comunicazione.


16

1.2.2 Il modulo Message

Gli endpoint comunicano scambiando messaggi propri di RTPS: La struttura e la logica

dei messaggi è definita nel modulo Message, specificando il contenuto delle informazioni

atomiche scambiate tra RTPS Writer e Reader [1].

I messaggi possono essere di due tipi: Entity-submessage ed Interpreter-submessage, i

primi agiscono direttamente sulle entità RTPS, mentre i secondi modificano lo stato del

Receiver

Figura 5 - Modulo Structure RTPS

EndPoint

StatefullReaderStatelessReaderStatefullWriterStatelessWriter

Message

ReaderWriter

Partecipant

EntityDomain1 *

0..1 *


17

Figura 6 - Modulo Message RTPS

Submessage Descrizione Tipo

NoKeyData Contiene informazioni sul valore di un Data-Object,

sono inviati solo da endpoint con topickind settato a

NO_KEY.

Entity

AckNack Fornisce informazioni sullo stato di un Reader ad un

Writer, sono inviati da un Reader ad uno o più Writer.

Entity

InfoDestination Fornisce informazioni sulla destinazione del Interpreter


18

submessage successivo.

NoKeyDataFrag Equivalente a NoKeyData, ma contiene solo alcuni

frammenti del nuovo valore, per consentire la

trasmissione di messaggi di grandi dimensioni.

Entity

NackFrag Fornisce informazioni sullo stato di un Reader ad un

Writer, in particolare quali frammenti un Reader non ha

ricevuto, sono inviati da un Reader ad uno o più Writer.

Entity

InfoSource Fornisce informazioni sulla sorgente dalla quale ha

origine il submessage successivo

Interpreter

Data Contiene informazioni sul valore di un Data-Object,

sono inviati solo da endpoint con topickind settato a

WITH_KEY.

Entity

HeartBeat Descrive le informazioni disponibili su un Writer, è

inviato da Writer (con topickind NO_KEY o

WITH_KEY) ad uno o più Reader

Entity

DataFrag Equivalente a Data, ma contiene solo alcuni frammenti

del nuovo valore, per consentire la trasmissione di

messaggi di grandi dimensioni.

Entity

HeartBeatFrag Per dati frammentati, descrive le informazioni

disponibili su un Writer, è inviato da Writer (con

topickind NO_KEY o WITH_KEY) ad uno o più

Reader

Entity

InfoTimestamp Fornisce un timestamp per i submessage successivi. Interpreter

InfoReply Fornisce informazioni su dove inviare una replica al

submessage successivo.

Interpreter

Gap Inviato dal Writer, descrive le informazioni più

rilevanti per i Reader.

Entity

Pad Usato per aggiungere padding ad un messaggio. Interpreter

Tabella 1 - Submessage RTPS


19

La struttura dei messaggi è organizzata nel seguente modo [1]:

un Header;

un numero variabile di Submessage.

Ogni Submessage è costituito da:

un SubmessageHeader, caratterizzato da un formato fisso che facilita il

processamento;

una serie di SubmessageElement.

Questa struttura permette di estendere i Submessage e di consentire la compatibilità

all'indietro delle estensioni. Ogni messaggio inviato dal protocollo RTPS ha una lunghezza

finita, di tale dimensione deve tener traccia il sottostante livello di trasporto.

I sottomessaggi contenuti all'interno del messaggio, potrebbero avere dei vincoli di

dipendenza con sottomessaggi appartenenti al messaggio del quale fanno parte. Per questo

motivo il receiver di un messaggio deve tenere traccia dello stato dei precedenti

sottomessaggi.

Il messaggio RTPS quando viene processato deve rispettare un insieme di regole per la sua

validità, ad esempio [1]:

il SubmessageHeader deve essere interamente leggibile, altrimenti lo stato del

Receiver risulterebbe alterato;

il campo octectsToNextHeader deve assumere un valore valido;

il campo SubmessageId deve appartenere ad un range di valori validi;

nel caso in cui alcuni flag ricevuti non siano noti al receiver, essi devono essere

ignorati.

1.2.3 Il modulo Behaviour

Il modulo Behaviour definisce l'insieme delle possibili interazioni tra i nodi di

comunicazione e come essi modificano il proprio stato facendo evolvere lo stato della

comunicazione, quindi è il modulo che conferisce dinamismo al protocollo [1]. Il


20

comportamento richiesto per l’interoperabilità è descritto come l'insieme di regole che

un'implementazione deve seguire in sequenza per essere interoperabile.

Un’implementazione del protocollo OMG RTPS può realizzare comportamenti aggiuntivi

rispetto a quelli previsti dai requisiti minimi di interoperabilità, allo scopo di ottenere un

utilizzo più efficiente delle risorse, lasciando un margine di libertà a chi implementa.

I requisiti minimi per l’interoperabilità sono i seguenti [1]:

tutte le comunicazioni devono utilizzare messaggi RTPS, secondo quanto specificato

nel modulo Message;

devono essere rispettate le regole per interpretare i sottomessaggi ricevuti;

deve essere possibile settare le caratteristiche temporali;

fornire supporto al discovery.

I requisiti che interessano il Writer sono:

invio dei dati nell’ordine con cui sono aggiunti alla HistoryCache;

in caso di comunicazione reliable, deve inviare periodicamente un HEARTBEAT

message e rispondere ad eventuali ACKNACK message negativi.

I requisiti che interessano il Reader, interessano solo comunicazioni reliable, sono:

unica risposta in corrispondenza di un HEARTBEAT message.

In particolare si distinguono due implementazioni di riferimento: quella Stateful e quella

Stateless, entrambe rispettano i requisiti minimi per l'interoperabilità, ma la differenza sta

nel numero di informazioni che esse memorizzano sulle entità remote, la versione stateful

tende a memorizzare il maggior numero di informazioni di stato possibili sui nodi, mentre

quella stateless tende a minimizzare il numero di informazioni memorizzate sui nodi, ma

necessita di utilizzare maggiore larghezza di banda.

La soluzione stateless si presta meglio per soluzioni scalabili, ma assorbe una maggiore

banda, essa è ideale per comunicazioni best-effort ed in presenza di HistoryCache di

piccole dimensioni, opera preferibilmente su multicast; mentre quella stateful è meno

scalabile, ma richiede meno banda ed è migliore per soluzioni reliable;

un'implementazione del protocollo OMG RTPS potrebbe essere anche una combinazione

delle due soluzioni, la sua realizzazione potrebbe prevedere, ad esempio, una versione


21

stateless che mantiene informazioni di stato aggiuntive sulle entità remote.

La soluzione stateless non ha la caratteristica di tenere traccia dei Reader sul Writer, né

mantiene informazioni di stato, utilizza l’entità detta ReaderLocator che conserva una lista

di Locator (ognuno dei quali rappresenta un Reader), ai quali inviare i cambiamenti

(CacheChange) da trasmettere ai Reader.

Nella soluzione stateful, invece, il Writer è configurato per avere conoscenza di tutti i

Reader con cui comunica e delle informazioni sullo stato in cui ognuno di essi si trova. Le

informazioni sui Reader sono mantenute attraverso apposite entità dette ReaderProxy.

Analogamente sui Reader entità dette WriterProxy tengono traccia delle informazioni sui

Writer.

Sia il Writer che il Reader RTPS sono responsabili della propagazione delle informazioni

di aggiornamento relative alle cache locali. L’interazione tra le entità dei due standard non

sono modellate formalmente e sono lasciate alle implementazioni. Infatti, il modulo

Behavior definisce come si propaga un messaggio contente le modifiche introdotte nella

HistoryCache tra gli endpoint e l’influenza sullo stato delle entità.

Figura 7 - Esempio di interazione


22

Di seguito è descritta l’interazione tra Writer e Reader in modalità Stateful e Reliable [1]:

1. Il Publisher, applicativo che utilizza il DDS, pubblica i dati invocando la funzione

write() sul DDSDataWriter;

2. Per comunicare con RTPS, il DDSDataWriter invoca l’operazione newchange()

sull’RTPS Writer per creare un CacheChange univocamente identificato da un

sequencenumber;

3. Al DDSDataWriter è restituito come tipo di ritorno un CacheChange;

4. Il DDSDataWriter invoca l’operazione addchange() sulla HistoryCcahe lato Writer per

memorizzare il CacheChange restituito al passo precedente;

5. Si ottiene il valore di ritorno all’operazione addchange();

6. Si ottiene il valore di ritorno all’operazione write() che sta ad indicare la terminazione

dell’operazione di scrittura da parte del Publisher;

7. L’RTPS Writer invia il contenuto di CacheChange all’RTPS Reader attraverso gli strati

protocollari sottostanti RTPS, usando il Submessage DATA (opzionalmente si potrebbe

usare NOKEYDATA) unitamente ad un Submessage HEARTBEAT, essendo una

trasmissione reliable, che effettua la richiesta di un ACKNACK Submessage;

8. L’RTPS Reader riceve il Submessage DATA e dopo aver verificato che il resource limit

settato non venga violato, inserisce il contenuto del CacheChange nella HistoryCache

lato Reader invocando l’operazione addchange();

9. Si ottiene il valore di ritorno all’operazione addchange(), a questo punto poiché la

comunicazione è reliable i dati sono disponibili al DDSDataReader solo se tutti i dati

contenuti nella HistoryCache con numero di sequenza inferiore a quello ricevuto sono

già stati ricevuti;

10. Il Subscriber, applicativo che utilizza il DDS, dopo che è stato avvisato da uno dei

meccanismi del DDS (ad esempio listener o waitset), legge i dati invocando la funzione

read() (che prevede la semplice lettura del dato) o take() (che prevede la lettura del dato

e la rimozione dalla HistoryCache) sul DDSDataReader;

11. Il DDSDataReader effettua la lettura invocando l’operazione getchange() sulla

HistoryCache;


23

12. Si ottiene il valore di ritorno all’operazione getchange();

13. Si ottiene il valore di ritorno all’operazione read() o take();

14. L’RTPS Reader invia un ACKNACK Submessage per indicare che il dato inviato in

precedenza dall’RTPS Writer è stato inserito nella HistoryCache del Reader, per rendere

possibile l’identificazione dell’ACKNACK, esso deve contenere l’identificativo del

Reader ed il sequencenumber del messaggio. Questa operazione è indipendente dalla

lettura del dato da parte del Subscriber e quindi può avvenire anche in un momento

precedente o contemporaneo alla lettura;

15. L’RTPS Writer registra che l’RTPS Reader ha ricevuto il messaggio trasmesso e lo

aggiunge all’insieme di ackedchanges tenuti dal ReaderProxy, invocando l’operazione

acked:change_set;

16. Il Subscriber invoca l’operazione finish() sul DDSDataReader per indicare che non sta

più utilizzando il dato che ha richiamato per mezzo della precedente operazione di

take();

17. Il DDSDataReader provvede alla rimozione del dato dalla HistoryCache lato Reader

invocando l’operazione removechange();

18. Si ottiene il valore di ritorno all’operazione removechange();

19. Si ottiene il valore di ritorno all’operazione finish();

20. Il DDSDataWriter invoca l’operazione isackedbyall() per determinare i messaggi che

sono stati riscontrati positivamente dall’ACKNACK;

21. Si ottiene il valore di ritorno all’operazione isackedbyall(), esso indica che il

cambiamento con il sequencenumber specificato è stato acknowledged da tutti gli RTPS

Reader;

22. Il DDSDataWriter invoca l’operazione removechange() per rimuovere un dato dalla

HistoryCache lato Writer associato al sequencenumber;

23. Si ottiene il valore di ritorno all’operazione removechange().


24

1.2.4 Il modulo Discovery

Il modulo Discovery definisce come il protocollo abilita i Participant ad ottenere

informazioni, circa l'esistenza e le caratteristiche (anche informazioni relative alle QoS) di

tutti gli altri Participant ed Endpoint nel Dominio [1]. Questo metatraffico generato

permette ai Participant di ottenere informazioni sugli altri Participant e sui Reader ed i

Writer nel Dominio, configurando i Writer a comunicare con i Reader ed i Reader a

comunicare con i Writer .

Poichè sono presenti due piani di comunicazione, ovvero uno a livello di Participant ed un

altro a livello di Endpoint, il modulo per il Discovery prevede due protocolli distinti:

Participant Discovery Protocol ed Endpoint Discovery Protocol.

Il Participant Discovery Protocol specifica come ogni Participant scopre ogni altro sulla

rete, dopo che due Participant hanno scoperto ogni altro, si scambiano informazioni sugli

Endpoint che essi contengono usando l' Endpoint Discovery Protocol.

Le diverse implementazioni devono fornire almeno un Discovery Protocol per i Participant

ed uno per gli Endpoint compatibile con il Discovery Protocol implementato sull’entità

con la quale si desidera stabilire la comunicazione, oltre a questo è possibile

l’implementazione di Discovery Protocol aggiuntivi.

Gli Endpoint sono contenuti nei Participant, una volta che un Participant ha scoperto gli

Endpoint remoti, deve configurare i suoi Endpoint locali ed a seconda

dell'implementazione adottata, bisogna configurare o l'oggetto RTPS ReaderLocator

associato ad ogni RTPS StatelessWriter, oppure gli oggetti RTPS ReaderProxy e

WriterProxy associati rispettivamente con RTPS StatefulWriter e StatefulReader.

Le informazioni di discovery sono rese accessibili agli utenti attraverso DDS built-in

Topic, i topic principali sono: DCPSParticipant, DCPSSubscription, DCPSPublication e

DCPSTopic. Per ognuno di questi built-in Topic esiste un corrispondente DDS built-in

DataWriter e DDS built-in DataReader.

I built-in DataWriter sono usati per annunciare la presenza di Participant locali ed altre

entità DDS nonchè le relative QoS.


25

Il protocollo OMG RTPS mappa ogni built-in DDS DataWriter o DataReader ad un

associato built-in RTPS Endpoint, grazie ai quali le informazioni di discovery sono

scambiate tra le entità [1].

Il contenuto della HistoryCache per ogni built-in Endpoint può essere descritto tenendo in

conto i seguenti aspetti:

DataType: specifica il tipo di dato memorizzato nella HistoryCache;

Cardinality: numero di differenti Data-Object che può essere potenzialmente

memorizzato nella HistoryCache;

Data-Object insertion: condizione per consentire l’inserimento nella HistoryCache di

un nuovo Data-Object;

Data-Object modification: condizione per consentire la modifica nella HistoryCache

di un Data-Object esistente;

Data-Object deletion: condizione per consentire l’eliminazione dalla HistoryCache di

un Data-Object esistente.

Le seguenti tabelle mostrano i contenuti delle HistoryCache per i differenti built-in

Endpoint:

aspetto descrizione

DataType DiscoveredWriterData

Cardinality Numero di DataWriter che contiene il DomainParticipant. C’è una

corrispondenza uno a uno tra ogni DataWriter nel Participant ed

un data-object che descrive il DataWriter memorizzato nella

HistoryCache del Writer

Data-Object

insertion

Ogni volta che un DataWriter è creato nel DomainParticipant

Data-Object

modification

Ogni volta che è modificata la QoS di un DataWriter esistente

Data-Object

deletion

Ogni volta che un DataWriter esistente appartenente ad un

DomainParticipant è cancellato

Tabella 2 - Contenuto HistoryCache per builtinPublicationWriter e builtinPublicationReader


26

Aspetto descrizione

DataType DiscoveredReaderData

Cardinality Numero di DataReader che contiene il DomainParticipant. C’è

una corrispondenza uno a uno tra ogni DataReader nel Participant

ed un data-object che descrive il DataReader memorizzato nella

HistoryCache del Writer

Data-Object

insertion

Ogni volta che un DataReader è creato nel DomainParticipant

Data-Object

modification

Ogni volta che è modificata la QoS di un DataReader esistente

Data-Object

deletion

Ogni volta che un DataReader esistente appartenente ad un


Tabella 3 - Contenuto HistoryCache per builtinSubscriptionWriter e builtinSubscriptionReader

Aspetto descrizione

DataType DiscoveredTopicData

Cardinality Numero di Topic creati dal DomainParticipant. C’è una

corrispondenza uno a uno tra ogni topic creato dal

DomainParticipant ed un data-object che descrive il Topic

memorizzato nella HistoryCache del Writer

Data-Object

insertion

Ogni volta che un Topic è creato nel DomainParticipant

Data-Object

modification

Ogni volta che è modificata la QoS di un Topic esistente

Data-Object

deletion

Ogni volta che un Topic esistente appartenente ad un


Tabella 4 - Contenuto HistoryCache per builtinTopicWriter e builtinTopicReader


27

1.3 Platform Specific Model (PSM): UDP/IP

Il protocollo OMG RTPS ha la caratteristica di operare su livelli di trasporto e di rete

inferiori di tipo sia unicast che multicast in modalità best-effort connectionless, come

UDP/IP [1].

Il protocollo di trasporto sottostante RTPS deve rispettare dei requisiti di base:

nozione di indirizzo unicast;

nozione di porto;

possibilità di inviare datagrammi ad indirizzi e porti specificati;

possibilità di ricevere datagrammi da indirizzi e porti specificati;

gestire i messaggi corrotti o incompleti durante il trasferimento;

fornire indicazioni sulle dimensioni dei messaggi.

Il protocollo PIM è mappato con UDP mediante il PSM, con l’obiettivo di minimizzare

l’overhead.

I motivi che hanno portato ad usare UDP come protocollo di trasporto sono i seguenti:

disponibilità universale;

leggerezza, poiché introduce soltanto i servizi minimali sopra IP;

best-effort, quindi si presta al funzionamento real-time, RTPS provvederà

eventualmente a garantire le QoS e l’affidabilità necessaria, poiché IP non ha bisogno

di garantire il raggiungimento della destinazione, né la consegna in ordine;

connectionless, permettendo ad RTPS endpoint multipli di condividere le risorse

offerte da UDP (ad esempio porti e socket);

non introduce timer che potrebbero portare ad una situazione di blocco;

Scalabilità e supporto al multicast, consentendo l’efficiente distribuzione di un singolo

messaggio ad un numero considerevole di receiver.

I protocolli di trasporto tradizionali, come TCP ed UDP, non sono in grado di garantire il

giusto trade-off tra la consegna dei dati in tempo reale ed offrire sufficienti garanzie

sull'effettiva consegna dei dati, ecco perchè il protocollo OMG RTPS utilizza UDP,

provvedendo ad introdurre delle garanzie sulla consegna dei dati che danno l’ affidabilità


28

di cui necessitano i sistemi mission critical, ma si trova impossibilitato ad utilizzare

efficientemente TCP, non prestandosi in alcun modo alla consegna in tempo reale dei dati,

infatti la sua natura è quella di essere asincrono, connection-oriented ed affidabile, non

risponde quindi alle esigenze di RTPS [8].

1.4 Quality of Service

Il protocollo OMG RTPS ed i suoi meccanismi di estensione forniscono le funzionalità per

supportare le QoS offerte dal DDS, le quali sono un insieme di caratteristiche per il

controllo del comportamento del servizio [1].

I parametri di QoS che utilizza il protocollo RTPS sono i seguenti:

USER_DATA;

TOPIC_DATA;

GROUP_DATA;

DURABILITY;

DURABILITY_SERVICE;

PRESENTATION;

DEADLINE;

LATENCY_BUDGET;

OWNERSHIP;

OWNERSHIP_STRENGTH;

LIVELINESS;

TIME_BASED_FILTER;

PARTITION;

RELIABILITY;

TRANSPORT_PRIORITY;

LIFESPAN;

DESTINATION_ORDER;

HISTORY;


29

RESOURCE_LIMITS;

ENTITY_FACTORY;

WRITER_DATA_LIFECYCLE;

READER_DATA_LIFECYCLE.

Alcuni di essi sono semplicemente trasmessi dal DDS, altri necessitano di essere

implementati anche da RTPS.

Di seguito è offerta una descrizione delle politiche di QoS più interessanti:

Reliability: indica il livello di affidabilità che fornisce il Writer o che supporta il

Reader, può essere best-effort o reliable. Nel funzionamento reliable i dati trasmessi

dal Writer non sono consegnati all’applicazione fino a che i campioni precedentemente

originati non sono stati consegnati, è pertanto necessario implementare un meccanismo

di ritrasmissione direttamente a livello RTPS. Nel funzionamento best-effort i dati

sono comunque consegnati all’applicazione senza preoccuparsi dei dati eventualmente

persi.

Ownership: regola l’aggiornamento dei Reader in presenza di più Writer, può essere

shared o exclusive. Nel funzionamento shared sono consentiti aggiornamenti da ogni

Writer, mentre nel funzionamento exclusive solo un Writer è abilitato ad effettuare

aggiornamenti in un dato istante di tempo.

Ownershipstrength: in caso sia settata la policy ownership exclusive, è necessario che

solo un Writer sia abilitato ad aggiornare il Reader, è assegnato a ciascun Writer un

valore e la risorsa è affidata al Writer con il valore più elevato, che soddisfi le

proprietà di Liveliness (indica che un entità è viva) e di Deadline (indica una

frequenza minima di aggiornamento).

History: regola lo svuotamento delle HistoryCache, può essere keep_last o keep_all.

Nel funzionamento keep_last, lo svuotamento della HistoryCache è effettuato al

raggiungimento del limite Depth (generalmente settato di default ad 1), mentre nel

funzionamento keep_all, lo svuotamento della HistoryCache è effettuato

all’esaurimento dello spazio messo a disposizione della HistoryCache, settato

mediante il parametro ResourceLimit, operazione effettuata solo se i dati sono stati


30

tutti riscontrati in caso di funzionamento reliable. Nel caso in cui la HistoryCache

persista in una situazione di stallo a causa di un mancato riscontro dei dati, solo se è

superato un limite sul tempo di permanenza dei dati nella HistoryCache

(maxblocktime) questa può essere svuotata.

31

Capitolo 2 I simulatori e la simulazione

Per simulazione si intende un modello della realtà, mediante il quale è possibile valutare e

prevedere l'evoluzione dinamica di eventi in un sistema sotto determinate condizioni

settate dall'utilizzatore, lo scopo è quello di fare un'analisi del funzionamento del sistema,

poiché spesso nella realtà non si ha la disponibilità di risorse sufficienti per effettuare delle

valutazioni [23].

La difficoltà nel realizzare un modello di simulazione risiede nella capacità del progettista,

di modellare quanto più fedelmente il sistema reale.

Per realizzare un modello di simulazione corretto e funzionante bisogna seguire alcune

linee guida [23]:

definire obiettivi e problematiche mediante un'analisi del problema;

definire un modello concettuale del sistema che bisogna simulare, defininendo il

comportamento del modello;

validazione del modello concettuale;

definizione dei parametri di ingresso del modello;

calibrazione e valutazione;

definizione di una campagna di test definendo diversi scenari di simulazione e valutare

i diversi scenari al variare dei tempi di esecuzione per poi valutare i parametri di

uscita.

Nella definizione del modello è essenziale definire le entità del modello che costituiscono


32

gli oggetti gestiti dal processo di simulazione e quindi subiscono eventuali trasformazioni.

Il modello realizzato bisogna implementarlo mediante un simulatore, grazie al quale le

entità modellate sono implementate assieme alle interazioni fra esse definite, consentendo

l'esecuzione di simulazioni dalle quali estrarre i dati di interesse per l'analista.

La simulazione può essere ad eventi discreti oppure tempo continuo. Nel caso ad eventi

discreti è rappresentato lo stato del sistema in corrispondenza degli eventi da rilevare,

mediante uno schedulatore che consente agli eventi di essere eseguiti ordinatamente, senza

simulare intervalli di tempo che intercorrono tra due eventi, riducendo la complessità

computazionale. Nel caso tempo continuo lo stato del sistema è rappresentato ad ogni

istante, assicurando il sincronismo tra gli eventi, ma rappresentando anche istanti di tempo

poco significativi, facendo crescere quindi la complessità computazionale [6].

L’emulazione invece consiste nella capacità di eseguire (mediante un software), codice

realizzato per un determinato ambiente (hardware o software) in un ambiente diverso,

riproducendo virtualmente l’ambiente che è stato usato per eseguire quel codice. Il livello

di astrazione è quindi basso. L’emulazione può essere realizzata in due modalità:

ricompilando il codice sorgente (in linguaggio di programmazione di alto livello),

ottenendo il file binario per l’ambiente ospitante, oppure interpretando il codice del

programma in linguaggio macchina, approccio più efficace ma che richiede una maggiore

complessità computazionale [23].

Tenendo presente questa distinzione, poiché lo scopo del nostro lavoro è quello di

analizzare il comportamento del protocollo OMG RTPS, è necessario realizzare un

modello del protocollo stesso, mediante il quale effettuare la simulazione, essendo

necessario uno strumento per effettuare l’analisi dello standard. Il codice per RTPS è

realizzato ex-novo e non è utilizzato codice già esistente, perciò la scelta della

simulazione.

2.1 Caratteristiche di modellizzazione

Nella modellazione di OMG RTPS è stato analizzato in dettaglio lo standard, estraendo da


33

esso solo alcune delle entità, in particolare quelle strettamente coinvolte nella trasmissione

dei messaggi (si è scelta la modalità Stateless, perchè meglio si adatta ad uno studio che

mira a valutare la scalabilità). Lo scopo è quello di estrarre alcuni parametri prestazionali,

valutando l’entità dei ritardi di comunicazione, il numero di pacchetti trasmessi a livello

RTPS, il numero di pacchetti trasmessi a livello di rete, al fine di capire il loro andamento

all'aumentare del numero di nodi del sistema.

Le entità che sono state estratte, rispettando le regole dettate dallo standard OMG,

necessitano di essere implementate. A tale scopo l’attenzione è stata rivolta in particolare a

tre moduli del protocollo OMG RTPS: Message, Behaviour e Structure, fornendo le

funzionalità essenziali per il Discovery.

Per la realizzazione del modello, oltre alla pura implementazione, nasce l’esigenza di

definire una topologia per la rete modificabile in maniera flessibile, al fine di effettuare

considerazioni al mutare degli scenari operativi, nonché definire funzionalità per

l’instradamento. E’ necessario specificare la struttura dei nodi Publisher e Subscriber,

mediante una rappresentazione anche dello stack protocollare sottostante RTPS (UDP/IP),

i canali della rete devono essere caratterizzati da un ritardo di propagazione, dalla capacità

e deve essere possibile simulare perdite di pacchetti e loro corruzione.

Il simulatore deve consentire lo studio del comportamento della rete, ovvero simulare su

ogni nodo della rete tutti gli strati dello stack protocollare, per avere uno studio del traffico

dei messaggi e dell’azione dei vari protocolli.

Al fine di avere un prodotto performante, vi è l’esigenza di poter usufruire di un supporto

anche alla trasmissione multicast.

Sulla base di queste caratteristiche è stata effettuata la scelta del simulatore.

Un primo obiettivo è quello di aumentare gradualmente il numero dei nodi, fino ad avere

un degrado delle prestazioni non tollerabile dall’applicazione, monitorando l’andamento

dei pacchetti trasmessi a livello di rete ed il loro incremento, in presenza di reti che

presentano perdite (fenomeno maggiormente accentuato soprattutto in scenari WAN). Un

secondo obiettivo è quello di estrarre delle misure sull’entità dei ritardi, nella fattispecie il

Round Trip Time, per poterlo poi confrontare con valori calcolati da implementazioni reali


34

di RTPS, ricavando quindi un errore di simulazione.

2.2 Classificazione dei simulatori

I simulatori disponibili sul mercato sono molteplici, ognuno con particolari caratteristiche,

è necessario analizzare e capire le peculiarità di ognuno di essi, scegliendo quello che

meglio si adatta alle esigenze del modello che si intende realizzare.

Una prima distinzione è possibile classificando i simulatori in comportamentali ed

orientati agli algoritmi. I primi consentono la simulazione su ogni nodo della rete di tutti

gli strati dello stack protocollare, al fine di studiare il traffico di messaggi sulla rete ed il

comportamento complessivo del modello, rivolgendo meno attenzione a quello che

succede a livello applicativo ed agli algoritmi di instradamento. L’utilizzo di questo tipo di

simulatori consiste nella costruzione di nodi della rete, combinando moduli software della

libreria del simulatore, l’output della simulazione contiene gli eventi significativi della

simulazione. La seconda categoria di simulatori presenta un maggiore livello di astrazione,

lo scopo è quello di simulare l’esecuzione di un algoritmo su ogni nodo, la simulazione di

come avviene la trasmissione è generalmente poco realistica ed affidabile.

Un'altra distinzione interessa la modalità di funzionamento dei simulatori. Essi possono

essere orientati agli eventi ed ai processi [25]. Nei simulatori orientati agli eventi

(cambiamento dello stato del sistema in un determinato istante di tempo), il tempo

simulato avanza al verificarsi del prossimo evento. Nei simulatori orientati ai processi

(istanza di un programma in esecuzione che emula il flusso di un'entità del sistema da

simulare), il tempo di simulazione avanza al processo successivo, quando il flusso di

esecuzione del processo corrente è bloccato, ritardato o terminato.

Per operare la scelta del simulatore, sono state considerate un insieme di caratteristiche

generali:

tipo di licenza: indica se il simulatore è free software o è disponibile solo in versione

commerciale;

linguaggio dei componenti dei nodi: indica il linguaggio di programmazione usato per


35

implementare i componenti dei nodi;

tipo di simulazione: indica se la simulazione è ad eventi discreti o tempo continuo;

emulazione: indica se è supportata l’emulazione;

simulazione parallela: indica se è presente un supporto all’esecuzione parallela in

multithreading e se è consentito all’utente, configurare tale funzionalità mediante la

gestione dei thread.

Una classificazione di maggior dettaglio riguarda le caratteristiche qualitative, per

illustrare in dettaglio il modo in cui è condotta la simulazione. Le caratteristiche

qualitative sono:

interfaccia grafica: indica se è presente un’adeguata interfaccia grafica per l’avvio,

l’esecuzione e la terminazione della simulazione, indispensabile per studiare il

comportamento del sistema;

estensibilità e modificabilità: è la possibilità di estendere e modificare i moduli del

simulatore specializzando le funzionalità in base alle proprie esigenze di modellazione;

modularità: è la possibilità di comporre tra loro le entità della simulazione, per

formare entità più generali;

tipologia di guasti: indica il tipo di guasto che l’utente può simulare durante la

simulazione. L’attenzione è stata rivolta alla perdita dei pacchetti ed alla corruzione

dei bit dei pacchetti;

statistiche finali: indica la possibilità di produrre agevolmente statistiche finali.

2.3 Simulatori analizzati

Nel presente paragrafo è offerta una breve descrizione delle caratteristiche di alcuni

simulatori presenti sul mercato.

2.3.1 Shawn

Shawn è un simulatore tempo continuo, orientato agli algoritmi ed ai processi. Non è un


36

simulatore commerciale, presenta un elevato livello di astrazione. L’utente può scrivere in

linguaggio C++ l’algoritmo da eseguire su ogni nodo della rete, specificando anche alcune

caratteristiche della simulazione. Il suo limite principale è quello di avere pochi modelli di

protocolli, inoltre nasce principalmente per applicazioni di reti di sensori wireless, non

supporta nè l’emulazione, nè la simulazione parallela.

Per specificare le caratteristiche della simulazione, si agisce sul Communication model per

specificare quando due nodi possono scambiarsi messaggi fra loro; sull'Edge model che

usa il Communication model, per rappresentare graficamente la rete; infine sul

Transmission model per simulare gli effetti della propagazione dei messaggi nell'ambiente

reale. Esso consente di aggiungere errori sui pacchetti trasmessi, simulare ritardi e perdite

di messaggi.

Questo simulatore non presenta un'interfaccia grafica, inoltre non elabora statistiche,

l'unico modo per recuperare dei dati è quello di scrivere applicazioni C++.

Shawn consente di sviluppare e collaudare algoritmi di instradamento eseguendo

l’algoritmo su tutti i nodi della rete.

Shawn è open-source, estensibile e modificabile in tutte le sue parti, la struttura modulare

consente di sviluppare nuovi modelli per la specifica delle caratteristiche simulative [11].

Tra i motivi che lo rendono poco consono alle nostre esigenze, si segnala l'assenza di

un'interfaccia grafica e statistiche finali difficili da gestire, inoltre non c’è la possibilità di

simulare gli stack protocollari della rete.

2.3.2 Algosensim

Algosensim simulatore tempo continuo, orientato agli algoritmi ed ai processi. Esso nasce

per la simulazione di algoritmi distribuiti, è open-source. E’ scritto in Java, l'ambiente di

simulazione è configurato scrivendo file XML in cui si specificano le caratteristiche della

simulazione, inoltre ha un elevato livello di astrazione.

Su ogni nodo sono eseguiti tre algoritmi: quello di localizzazione per lo scambio di

informazioni con i nodi adiacenti per la costruzione della topologia della rete, quello di


37

routing per istradare i messaggi ricevuti ed infine un algoritmo per l'elaborazione di dati

statistici.

E' dotato di un'interfaccia grafica molto spartana, non fornisce un ausilio all'utilizzatore

nella fase di esecuzione.

Algosensim è aperto ed estensibile, è possibile scrivere nuove classi Java che

implementano alcune funzionalità utili allo sviluppatore.

Per la trasmissione dei messaggi, ogni nodo non può effettuare comunicazioni con un

numero considerevole di nodi, questo limite crea delle difficoltà nella realizzazione di reti

scalabili. Esso consente di simulare solo perdite di pacchetti, molto semplice ma

inaffidabile la gestione delle collisioni, è possibile effettuare l'elaborazione di dati statistici

ma non supporta nè l'emulazione, nè la simulazione parallela [12].

Tra i motivi che lo rendono poco consono alle nostre esigenze, in primo luogo non offre

supporto alla costruzione di modelli di grandi dimensioni, si segnala inoltre l'assenza di

modularità, un'interfaccia grafica di basso livello, la mancanza di un buon supporto a run-

time, statistiche finali difficili da gestire, inoltre non c’è la possibilità di simulare gli stack

protocollari della rete.

2.3.3 Opnet

Opnet è un simulatore comportamentale, ad eventi discreti, object-oriented, commerciale.

E' dotato di interfaccia grafica molto chiara e fornisce più editor a seconda del livello di

astrazione desiderato [13], gli oggetti (nodi, processi, link, protocolli, dispositivi) sono

estendibili e dotati di attributi. Esso consente la creazione di modelli gerarchici di reti e di

nodi, modelli personalizzati estendendo modelli esistenti o creandone nuovi, mediante

linguaggio di programmazione Proto-C. Fornisce un servizio di statistiche di base, con la

possibilità di crearne alcune aggiuntive. I modelli principali sono tre: Process, un processo

è un'istanza di un modello di processo, esso è eseguito in un modulo processor, queue o

easy, al verificarsi di un evento è generato un interrupt che invoca un processo che

risponderà con un'azione. I nodi sono un altro dei modelli principali, essi sono composti da


38

uno o più moduli che eseguono processi. Il modello Network è costituito da sottoreti

organizzate gerarchicamente, nodi e link di comunicazione consentendo di introdurre

perdite di pacchetti e corruzione dei bit trasmessi, supporta l'esecuzione parallela, ma non

l'emulazione [14].

Tra i migliori simulatori visti, risponde alle esigenze della simulazione da effettuare, ma è

commerciale ed il linguaggio di programmazione usato è poco diffuso.

2.3.4 Smurph

Smurph è un simulatore comportamentale, object-oriented, configurabile per modellizzare

eventi discreti, ma modella soltanto protocolli di comunicazione di basso livello (fino al

livello MAC). E' un simulatore commerciale. Un'interfaccia ad alto livello nasconde

all'utente la struttura del simulatore, consentendo di monitorare le caratteristiche del

protocollo. Appositi tool observer, sono forniti per testare il protocollo.

Smurph è stato realizzato in C++, gli oggetti sono estendibili, supporta la creazione di

modelli organizzati gerarchicamente.

La topologia della rete è definita come interconnessione di stazioni, porti e link che sono

oggetti di tipo Station, Port e Link, l'aggiunta di particolari caratteristiche è effettuata

dall'utente, definendo dei sottotipi.

Le caratteristiche di un protocollo sono descritte da un insieme di processi (oggetti di tipo

Process) eseguiti nelle stazioni. Le operazioni dei processi relativi ai protocolli sono

guidate da eventi, generati dagli oggetti activity interpreters.

Smurph fornisce un servizio di statistiche di base, con la possibilità per l'utente di crearne

altre, supporta sia l'emulazione che la simulazione parallela [15].

Tra i migliori simulatori visti, ma è commerciale, non risponde pienamente alle nostre

esigenze, perché i protocolli di comunicazione a livello trasporto devono essere

implementati interamente dall’utente.


39

2.3.5 NS-2

Ns-2 è un simulatore comportamentale, ad eventi, scritto in C++, con interfaccia utente in

Otcl per configurare le simulazioni, nasce per studiare il traffico di messaggi sulla rete. E'

tra i simulatori di reti più usati per l'eterogeneità d'uso e la varietà di modelli offerti, ma

manca una documentazione rigorosa ed organizzata. Ns-2 è open-source e non supporta nè

l'esecuzione parallela, nè l'emulazione.

Non c'è un’interfaccia grafica per impostare agevolmente l’ambiente di simulazione,

inoltre l'utilizzo del simulatore non è semplice. Gli output sono prodotti in diversi formati.

Un'utility che consente di seguire la simulazione graficamente è la Network Animator,

essa legge il file di tracing degli eventi e lo visualizza.

Presenta vari modelli per rappresentare i link, consentendo di impostare caratteristiche

della topologia di rete come ampiezza di banda, ritardo di propagazione, perdita di

pacchetti.

NS-2 presenta un'ampia scelta di algoritmi di routing. Il comportamento di un nodo è

specificato mediante lo script Otcl, specificando gli oggetti che lo compongono ed il modo

in cui sono collegati. La scrittura di moduli C++ offre l’opportunità di implementare

nuove caratteristiche.

Poco funzionali le API offerte, non c'è una netta distinzione tra librerie di simulazione e

modelli implementati.

Non produce dati statistici in output, ma l'utente può inserire nello script OTCL operazioni

per il prelievo di dati di interesse [16].

Tra i motivi che lo rendono poco consono alle nostre esigenze, si segnala l'assenza di

modularità, l'assenza di un'interfaccia grafica, statistiche finali difficili da gestire.

2.3.6 Glomosim

Glomosim è un simulatore comportamentale, ad eventi discreti, con supporto per

l’esecuzione parallela in ambiente multiprocessore, ma non supporta l'emulazione. Esso


40

consente di scegliere il numero di entità da creare ed in che modo assegnare nodi e strati

software ai processori (mediante l'uso di appositi algoritmi che minimizzano il traffico di

rete). I moduli sono scritti in Parsec ed ognuno è relativo ad uno strato protocollare. E’ un

simulatore commerciale, composto da una decina di strati software indipendenti, è un

esempio di simulatore altamente scalabile, modulare, estensibile e modificabile.

E' dotato di un’interfaccia grafica. La topologia della rete è costituita da una griglia

bidimensionale, sulla quale i nodi possono essere disposti manualmente o impostando le

coordinate spaziali di ogni nodo su un apposito file di testo. Esistono delle modalità di

spostamento dei nodi secondo politiche preassegnate.

La simulazione dei guasti non è comprensiva dell'intera casistica.

Offre un servizio di statistiche elaborato da ognuno degli strati software che compongono i

nodi al termine della simulazione, questo comporta delle difficoltà nell'elaborare

statistiche più generali [17].

Tra i motivi che lo rendono poco consono alle nostre esigenze, si segnala la difficoltà nella

gestione di statistiche finali, il linguaggio di programmazione poco diffuso ed il fatto di

essere commerciale.

2.3.7 J-Sim

J-Sim è un ambiente di simulazione scritto in Java, comportamentale, con interfaccia

grafica in Tcl in cui si decide il comportamento dei nodi. Si basa sulla programmazione

basata sui componenti e non è un prodotto commerciale.

L’utente nella fase di configurazione deve istanziare tutti i componenti della simulazione:

nodi, link, monitor ed altre entità necessarie alla simulazione collegandole

opportunamente. Un'utility indispensabile è l'editor grafico per generare gli script Tcl.

J-Sim ha una complessità d’uso maggiore rispetto a quella di simulatori concorrenti,

supporta l'uso dei thread, quindi l'esecuzione parallela, ma non l'emulazione, anche se è

demandato all'utente il compito di gestire i thread.

Il grado di astrazione delle operazioni da effettuare tramite Tcl è basso, per cui l’utente


41

deve specificare un notevole numero di comandi. Non ci sono costrutti specifici per la

creazione, la configurazione e la connessione di componenti in Java, quindi l’utente deve

richiamare su ogni oggetto istanziato in Tcl, i metodi per creare porti, connessioni. Questa

è la ragione che rende gli script Tcl più complessi, la configurazione della simulazione è

anch'essa complicata. Supporta la visualizzazione grafica solo di alcuni dati della

simulazione.

Il modello topologico è tridimensionale, posizionando i nodi senza alcun tipo di vincolo

nella topologia.

La simulazione dei guasti non è comprensiva dell'intera casistica.

J-Sim offre una vasta scelta di algoritmi di routing. Sono disponibili componenti che

implementano molte applicazioni e protocolli di vario livello.

J-Sim è open-source ed estensibile.

E' possibile elaborare statistiche su tutti i dati accessibili della simulazione, se l'utente ha

predisposto le apposite istruzioni nel file Tcl. Collegando dei componenti (Plotter) ai vari

componenti degli elementi della simulazione, è possibile visualizzare l’andamento grafico

nel tempo [18].

Tra i motivi che lo rendono poco consono alle nostre esigenze, si segnala la difficoltà nella

gestione di statistiche finali, la difficoltà di utilizzo ed il notevole numero di comandi

necessari a creare la rete da simulare.

2.3.8 OMNeT++

OMNeT++ [5] è un simulatore ad eventi discreti, non commerciale, scritto in C++, è

dotato di un’interfaccia grafica di alto livello, è classificato fra i simulatori

comportamentali. Esso supporta l’esecuzione parallela, ma non l’emulazione.

Il simulatore è dotato di un tool (NED) per la definizione della topologia e delle

caratteristiche della rete, offrendo sia un supporto grafico che testuale. Le entità definite

sono dei moduli che possono estendere le proprie funzionalità mediante codice C++, ogni

modulo può contenere al suo interno sottomoduli.


42

Un file di configurazione consente di settare i parametri iniziali del modello. Consente una

modellazione dei guasti introducendo soltanto la corruzione dei pacchetti. Al termine

della simulazione fornisce un servizio di base di statistiche finali, con la possibilità da

parte dell’utente di estenderle. Diversi framework consentono di utilizzare OMNeT++ in

svariati domini applicativi, quello che risponde alle esigenze del modello da simulare è

INET che modella diversi stack protocollari, fra i quali UDP/IP.

2.3.9 Mobius

Mobius è un tool non commerciale per la modellazione delle caratteristiche di sistemi

complessi, presenta caratteristiche di flessibilità, è classificabile come un simulatore

comportamentale, ad eventi discreti, supporta la simulazione parallela, ma non

l'emulazione. Nasce con l'esigenza di studiare reliability, availability, security e

prestazioni di sistemi e reti di calcolatori, oggigiorno è usato per lo studio di sistemi ad

eventi discreti. Inoltre supporta diversi modelli formali e tecniche risolutive facilmente

integrabili fra loro.

Mobius presenta linguaggi di modellazione sia grafici che testuali (MoDeST), supporta la

creazione di modelli secondo un paradigma gerarchico, dapprima specificando le

caratteristiche individuali dei componenti, poi combinando i componenti, al fine di creare

un modello di sistema completo. Fornisce tutti gli strumenti necessari per effettuare le

misurazioni.

Le funzionalità del sistema sono definite mediante i parametri del modello di input, le

caratteristiche del sistema possono essere definite attraverso i valori dei parametri di input.

Consente una buona modellazione dei guasti introducendo perdita e corruzione dei

pacchetti [19].

2.4 Scelta del simulatore da usare

Tra i simulatori esaminati è quello maggiormente in grado di competere con OMNeT++


43

tra quelli non commerciali, anche se OMNeT++ facilita l'estendibilità mediante il

linguaggio di programmazione C++, molto conosciuto dagli utilizzatori. OMNeT++

mediante il framework INET fornisce un buon supporto a modellare lo stack protocollare

sottostante RTPS, una facilità notevole nella gestione del settaggio della topologia della

rete e la gestione dell'instradamento.

Si può concludere dicendo che, la potenza del framework INET ha consentito ad

OMNeT++ di vincere la sfida con i concorrenti che presentavano caratteristiche che

andavano incontro alle esigenze del modello da implementare.

Di seguito sono mostrate delle tabelle riassuntive riguardanti la classificazione dei

simulatori in base al loro livello di astrazione (orientati a simulare il comportamento o gli

algoritmi), una classificazione basata sulle caratteristiche generali ed infine una

classificazione qualitativa.

Orientati agli algoritmi Shawn, Algosensim

Comportamentali OMNeT++, Opnet, Smurph,

NS-2, Glomosim, J-Sim, Mobius

Tabella 5 - Classificazione dei simulatori

Orientati agli eventi OMNeT++, Opnet,

NS-2, Glomosim, J-Sim, Mobius

Orientati ai processi Smurph, Shawn, Algosensim

Tabella 6 - Classificazione della tipologia dei simulatori

Licenza Linguaggio

componenti nodi

Tipo Simulazione

Emulazione

Simulazione parallela

OMNeT++ free Ned/C++ eventi discreti no si

Shawn free C++ tempo continuo no no

Algosensim free xml/java tempo continuo no no

Opnet commerciale Proto-C eventi discreti no si


44

Licenza Linguaggio componenti

nodi

Tipo Simulazione

Emulazione

Simulazione parallela

Smurph commerciale C++ eventi discreti si si

NS-2 free Otcl/C++ eventi discreti no no

Glomosim commerciale Parsec eventi discreti no si

J-Sim free Jacl/java eventi discreti no si

Mobius free MoDeST eventi discreti no si

Tabella 7 - Caratteristiche generali dei simulatori

Interfaccia

grafica Estensibilità e Modificabilità

Modularità Guasti Statistiche finali

OMNeT++ si si si bit error si

Shawn no si si packet loss bit error

no

Algosensim si si no packet loss no

Opnet si si si packet loss bit error

si

Smurph si si si - si

NS-2 no si no packet loss no

Glomosim si si si packet loss no

J-Sim si si si packet loss no

Mobius si si si packet loss bit error

si

Tabella 8 - Caratteristiche qualitative dei simulatori

La scelta di OMNeT++ e del suo framework INET (implementa strati protocollari per

l'interconnessione di calcolatori su rete) tra la vastità di simulatori presenti sul mercato, è

stata guidata dalla combinazione di molteplici esigenze. E' un simulatore

comportamentale, i moduli sono facilmente riusabili ed assemblabili fra loro, consente di

visualizzare i pacchetti sulla rete ed il loro contenuto durante l'esecuzione e come variano i


45

parametri all'evolvere dell'esecuzione, inoltre, la presenza del framework INET offre un

buon supporto per la gestione ed il settaggio della topologia della rete anche per reti di

notevoli dimensioni. L'unico limite è rappresentato dalla memoria del calcolatore in uso.

Esso offre funzionalità per supportare l'instradamento, poichè il modello di RTPS che è

stato implementato serve anche per effettuare test al variare della topologia della rete,

queste funzionalità risultano essenziali, perchè risulterebbe complesso gestire tali

caratteristiche con altri simulatori. Queste funzionalità fornite dal simulatore sono

comunque estendibili dall'utente che può imporre delle varianti al comportamento di

default, potendo introdurre algoritmi di instradamento alternativi, o settare nuove route

scrivendo direttamente gli hop per il percorso da seguire mediante appositi file.

2.5 Il simulatore OMNeT++

OMNeT++ (Objective Modular Network Testbed in C++) [5] è un simulatore di rete

modulare component-oriented ad eventi discreti basato sul linguaggio C++ ed open source

che nasce nel 2003. Tale simulatore è modulare perché ogni entità presente o da realizzare

è rappresentata mediante un modulo e tutti i moduli sono organizzati gerarchicamente,

comunicano mediante scambio di messaggi che viaggiano attraverso porte e connessioni.

Component-oriented indica che l’architettura del simulatore è costituita da componenti che

interagendo tra loro, consentono l’esecuzione del programma di simulazione. Un sistema

ad eventi discreti è un sistema in cui lo stato cambia quando accade un evento ad istanze

discrete nel tempo.

Il simulatore può essere utilizzato per [5]:

modellazione del traffico nelle reti di telecomunicazioni;

modellazione di protocolli;

modellazione di code nelle reti;

modellazione di sistemi multiprocessore;

modellazione di sistemi distribuiti;

validazione di architetture hardware;


46

valutazione delle prestazioni di sistemi software complessi;

modellazione di sistemi rappresentabili con eventi discreti.

L’innovazione principale di OMNeT++ è quella di essere component-oriented, facilita

l’uso di modelli strutturati e riusabili, supporta l'esecuzione parallela (in sistemi

multiprocessore), gli ambienti di esecuzione supportano la simulazione interattiva. Questo

simulatore fornisce per lo sviluppo ed il debugging delle topologie da simulare, un

ambiente grafico abbastanza intuitivo (GNED), il quale contiene anche una

rappresentazione testuale della topologia del modello, un’interfaccia grafica (Tkenv) per

l’esecuzione della simulazione, mediante questa interfaccia è possibile visionare i moduli

del modello e vedere l’evolvere dello stato della simulazione, un’interfaccia da linea di

comando (Cmdenv), tool grafici (PLOVE e SCALARS) per visualizzare il contenuto

degli output della simulazione scritti su appositi file dati generati automaticamente, ma

estendibili dall’utente.

Figura 8 - Costruzione ed esecuzione della simulazione


47

OMNeT++ non è un simulatore commerciale, è rivolto principalmente all’uso accademico

ed alla ricerca, la sua versione commerciale è OMNEST. Fra i simulatori esistenti,

OPNET rappresenta il migliore simulatore sul mercato, ma è commerciale. I simulatori

commerciali offrono una vasta gamma di modelli di protocolli, mentre quelli non

commerciali offrono una minore scelta. Un limite principale di OMNeT++ è proprio la

mancanza di una vasta scelta di protocolli, (ne esistono diversi, ma in scarso numero),

limite dovuto al fatto che è un simulatore nato da poco; con la diffusione delle community

questo limite dovrebbe essere superato in pochi anni. Il livello di astrazione è molto

elevato, ha una notevole facilità d'uso per l'utente (interfaccia user-friendly), la

documentazione offerta e le prestazioni durante l'esecuzione sono di livello eccellente

[21], [22].

OMNeT++ è disponibile sia per macchine Windows che Linux, la versione per Linux è la

stessa per distribuzioni diverse, inoltre la portabilità è garantita, previa modifica dei

makefile per la simulazione da effettuare.

Un modello OMNeT++ è costituito da moduli organizzati gerarchicamente e caratterizzati

attraverso parametri, i moduli comunicano mediante scambio di messaggi (che possono

anche contenere strutture dati complesse) attraverso i canali, inoltrando i messaggi

direttamente verso una destinazione o lungo un percorso, usando porte e connessioni.

Le connessioni possono essere caratterizzate da tre parametri: ritardo di propagazione,

tasso di errore per bit, tasso di trasmissione.

Gli oggetti della simulazione sono rappresentati da classi C++, le principali sono quelle

per moduli, porte, connessioni, parametri, messaggi, container, raccolta dati, stima

statistica e distribuzione.

Un modello OMNeT++ si compone di: file per la descrizione della topologia (.ned), file

per la definizione dei messaggi (.msg), tradotti in codice C++ mediante compilazione,

moduli del codice sorgente (.h/.cc) che devono essere compilati e collegati con il

simulation kernel, esso contiene il codice per gestire la simulazione, le classi di libreria

(.a/.lib) e le interfacce utente (.a/.lib) per formare il programma di simulazione eseguibile.


48

Il file eseguibile necessita del file di configurazione omnetpp.ini che contiene

informazioni di controllo, esso è utilizzato per costruire un file binario per consentire

l’esecuzione anche su macchine sulle quali non è installato OMNeT++. L’output della

simulazione è scritto in file dati: output scalar e vector file (vector file è opzionale),

visualizzabili anche graficamente con gli strumenti forniti da OMNeT++ o importabili da

software diffusi sul mercato come MatLab, Microsoft Excel, OpenOffice calc [5].

2.5.1 Il linguaggio NED

Il linguaggio NED specifica la topologia di un modello, facilitando la descrizione

modulare di una rete ed offre la possibilità di costruire una rete con sottomoduli innestati

[5]. I possibili componenti di un modello NED sono:

direttive import, usate per importare dichiarazioni da un altro file per la descrizione di

una rete:

import "ethernet";

definizioni dei canali, specificano un tipo di connessione, il nome del canale può

essere usato per la creazione di connessioni, gli attributi possono essere assegnati

anche nel corpo della dichiarazione del canale:

channel ChannelName

//...

endchannel

simple module, blocco di base per la costruzione dei moduli, è definito dalla

dichiarazione di parametri e porte:

simple SimpleModuleName

parameters:

//...

gates:

//...

endsimple


49

compound module, moduli composti di uno o più sottomoduli, anch’essi possono

avere porti e parametri:

module CompoundModule

parameters:

//...

gates:

//...

submodules:

//...

connections:

//...

endmodule

definizione della rete, dichiara un modello di simulazione come un’istanza di un tipo

di modulo definito precedentemente:

network wirelessLAN: WirelessLAN

parameters:

numUsers=10,

httpTraffic=true,

ftpTraffic=true,

distanceFromHub=truncnormal(100,60);

endnetwork

2.5.2 Il sistema di simulazione ad eventi discreti

OMNeT++ utilizza una struttura dati per mantenere l’insieme degli eventi futuri e prende

il nome di FES (Future Event Set) o FEL (Future Event List) implementato in OMNeT++

con l’heap binario.

I simple module sono i componenti attivi nel modello perché in essi accadono gli eventi,

essi creano, inviano, ricevono, memorizzano, modificano, schedulano e distruggono i


50

messaggi, sono programmati in C++ come sottoclassi di cSimpleModule con funzioni

membro virtuali ridefinite per definire le caratteristiche, tale codice genera e reagisce agli

eventi, usano OMNeT++ class library e le funzioni membro sono le seguenti:

• void initialize()

• void handleMessage(cMessage *msg)

• void activity()

• void finish()

Nella fase di inizializzazione (funzione initialize()) si costruisce la rete, si creano i simple e

compound module e sono connessi in base alle definizioni del file NED e del file di

configurazione omnetpp.ini.

Durante il processamento degli eventi sono chiamate le funzioni handleMessage() (chiamata

da ogni messaggio che arriva al modulo oppure in seguito a schedulazione ad un fissato

istante di tempo) oppure activity(), nelle quali sono implementate dall’utente le

caratteristiche del modello. La funzione activity() non necessita della preventiva

esecuzione della funzione initialize(), ma presenta limiti notevoli dal punto di vista della

scalabilità: questa funzione crea un sovraccarico dello stack, quindi in presenza di

centinaia di simple module, crea difficoltà nella gestione della memoria, inoltre introduce

un maggiore overhead a run-time, nonché una maggiore lentezza nella chiamata della

coroutine rispetto ad una normale chiamata a funzione [5].

Solo nella fase finale è possibile memorizzare i dati statistici raccolti durante la

simulazione (durante l’invocazione della funzione finish()).

Gli eventi sono rappresentati mediante i messaggi da un’istanza della classe cMessage. I

messaggi sono inviati da un modulo ad un altro, quindi il posto dove occorre un evento è

il modulo destinazione del messaggio. Gli eventi in ingresso al buffer del FES sono

consumati in base all’ordine d’arrivo, dati due messaggi, quello con il tempo d’arrivo più

basso è eseguito prima, se tali valori sono uguali, si esegue prima quello con il valore di

priorità più basso, se le priorità sono le stesse si valuta quello schedulato o inviato prima.

Un dettaglio tecnico interessante nel funzionamento di OMNeT++ riguarda le porte,

infatti esse hanno associate code per memorizzare messaggi in attesa di essere trasmessi, i


51

messaggi sono però memorizzati nei buffer della FES. Questo tipo di approccio dovrebbe

essere più veloce rispetto ad una soluzione che fa uso delle code, perché evita l’overhead

dovuto all’accodamento (ed al disaccodamento), eventi e messaggi sono trattati come

un’unica entità.

Altri simulatori (come ad esempio OPNET) assegnano code di pacchetti alle porte in

ingresso prima di bufferizzare i messaggi, in questo modo gli eventi sono gestiti da

un’entità equivalente alla FES, mentre i messaggi dalle porte, quindi eventi e messaggi

risultano essere due entità separate [5], [21].

La registrazione della classe con OMNeT++ avviene mediante la macro Define_Module()

inserita nel codice C++:

#include <omnetpp.h>

class HelloModule : public cSimpleModule

{

protected:

virtual void initialize();

virtual void handleMessage(cMessage *msg);

};

Define_Module(HelloModule);

void HelloModule::initialize()

{

ev << "Hello World!\n";

}

void HelloModule::handleMessage(cMessage *msg)

{

delete msg; }


52

2.5.3 La macchina a stati finiti

La macchina a stati finiti [5] fa parte del modello di programmazione supportato

dall’ambiente di simulazione, è attivata con il metodo handleMessage(), OMNeT++

fornisce una classe ed un insieme di macro per costruire una FSM in cui sono possibili

due stati: transient e steady. Lo stato transient indica una condizione temporanea della

FSM che si verifica durante la transizione da un evento al successivo; lo stato steady

indica una condizione in cui l’evento è accaduto.

Il modello di programmazione di OMNeT++ comprende anche una soluzione basata sulle

coroutine che implementa l’interazione tra i processi mediante la funzione activity().

Queste due soluzioni differenziano OMNeT++ dai suoi concorrenti che generalmente

implementano una sola soluzione, ad esempio OPNET, SMURPH usano FSM, mentre

GloMoSim usa i thread (quindi una soluzione basata sulle coroutine) [21].

Ad ogni evento la FSM transita da uno stato costante attraverso uno o più transitori per

poi ritornare in uno stadio costante. Nel codice del metodo è possibile inserire i punti di

ingresso e di uscita da uno stato. La FSM è memorizzata in un oggetto cFSM [5].

2.5.4 I messaggi

L’oggetto cMessage rappresenta i messaggi, o anche eventi, pacchetti, frame, celle, bit o

segnali (o altre entità) che viaggiano attraverso la rete. Tale oggetto ha degli attributi,

alcuni usati dal simulation kernel, altri di utilità per il programma di simulazione, ecco

alcuni di essi: nome del messaggio, tipo, lunghezza, bit error flag (settato ad uno quando

la probabilità d’errore supera una certa soglia), priorità usata dal kernel per ordinare i

messaggi in ingresso al FES, timestamp usato in caso di accodamento o reinvio, lista

parametri, messaggio incapsulato per modellare il passaggio attraverso i livelli della pila

protocollare, informazioni di controllo, indicatore di contesto, infine attributi per la

memorizzazione di informazioni come moduli e porte sorgente e destinazione, tempo di

invio e di ricezione.


53

Questo oggetto può essere esteso per aggiungere nuovi campi ed OMNeT++ fornisce un

modo molto conveniente per la definizione dei messaggi creando file con estensione

*.msg, dal quale in seguito ad una compilazione, è generato codice C++ che fornisce i

metodi all’utilizzatore per settare i campi dei messaggi definiti dall’utente [5].

2.5.5 Architettura

L’architettura di OMNeT++ è realizzata mediante i seguenti componenti [5]:

Sim è il simulation kernel ed una libreria di classi che l’utente può collegare alla

propria simulazione. Questo componente gestisce gli eventi futuri, istanzia simple

module ed altri componenti all’inizio dell’esecuzione della simulazione;

Envir è un’altra libreria contenente il codice comune a tutte le interfacce utente,

consente di estendere le interfacce di base, mediante plug-in aggiuntivi. Esso

mantiene il controllo di cosa accade durante la simulazione. Il metodo main() è

localizzato in questo componente e determina quali modelli richiamare durante la

simulazione;

Cmdenv e Tkenv sono implementazioni di interfacce utente specifiche da collegare

alla propria simulazione: la prima agisce da linea di comando, la seconda è grafica.

Mediante queste interfacce l’utente ha la possibilità di iniziare e terminare la

simulazione, nonchè seguire l’evolvere della simulazione;

Model Component Library consiste di definizioni di simple module e relativa

implementazione in C++, tipi di compound module, canali, reti, messaggi ed altre

entità legate alla simulazione;

Executing Model è il modello che è stato impostato per la simulazione. Esso contiene

oggetti (moduli, canali) che sono tutte istanze di componenti appartenenti al Model

Component Library.


54

Sim <-> Executing Model: Sim invoca i moduli nell’Executing Model come eventi

accaduti memorizzandoli nell’oggetto principale di Sim: simulation (della classe

cSimulation, che memorizza i moduli del modello in esecuzione e tiene traccia degli

eventi nella FES), mentre Executing Model chiama le funzioni nel Sim ed usa le sue

classi di libreria.

Sim <-> Model Component Library: Sim fa riferimento al Model Component Library

quando è usata la creazione dinamica dei moduli (durante la fase di inizializzazione della

simulazione).

Executing Model <-> Envir: l’oggetto ev (unica istanza della classe cEnvir, serve a

gestire le funzionalità per l’I/O e fornire metodi per accedere a Sim), è usato per

visualizzare informazioni durante la simulazione e per la scrittura sul file di log.

Sim <-> Envir: invoca Sim per le funzionalità legate allo scheduling ed all’esecuzione

degli eventi, mentre Sim usa Envir per produrre i risultati della simulazione.

Envir <-> Tkenv e Cmdenv: Envir definisce una classe per l’interfaccia utente:

TOmnetApp, Tkenv e Cmdenv sono sue sottoclassi che consentono all’utente di scegliere

quale usare mediante il metodo main() che crea un’istanza e la esegue. Envir fornisce

anche delle funzionalità di base per le sottoclassi di TOmnetApp che usano i suoi stessi

metodi essendo sue sottoclassi [5].

Figura 9 - Architettura di OMNeT++


55

2.6 INET framework

INET framework è un modello di simulazione per alcuni strati protocollari per

l'interconnessione di calcolatori su rete. Esso contiene l’implementazione di protocolli

come TCP/IP ed UDP/IP, è stato scritto per l'ambiente di simulazione

OMNeT++/OMNEST, utilizzando i moduli attraverso i quali sono scambiati i messaggi.

Include anche MPLS con RSVP-TE e segnalazione LDP. I modelli del livello di

collegamento sono PPP, Ethernet e 802.11.

Si osserva che la distribuzione dell'INET framework presenta delle differenze tra Linux e

Windows, infatti la distribuzione Windows offre una scelta dell’insieme di protocolli più

limitati, poichè nasce come una versione dimostrativa e non di sviluppo.

Esso contiene alcuni esempi di reti da simulare, modelli di entità di rete, classi C++ per la

definizione di messaggi che viaggiano sulla rete.

Rispetto ad altri concorrenti, come già detto, presenta pochi modelli, questo framework

fornisce alcuni modelli che per lo scopo del nostro lavoro sono più che sufficienti,

consentendo di sfruttare al meglio i pregi del simulatore.

I protocolli sono rappresentati mediante simple module. L’interfaccia esterna del modulo

è descritta mediante file NED, l’implementazione corrispondente è contenuta in file C++

con lo stesso nome del file NED. Questi moduli possono liberamente essere combinati fra

loro con il linguaggio NED per formare host o altri device, senza effettuare la

ricompilazione. Sono comunque presenti host preassemblati, router, switch, access-point

utilizzabili dall’utente, ma è possibile crearne di nuovi.

Le interfacce di rete sono compound module, composti da una coda, un MAC, ed

eventualmente altri simple module.

Non tutti i moduli implementano protocolli, esistono molti moduli che servono a facilitare

la comunicazione con altri moduli, consentire l'autoconfigurazione della rete, spostare un

nodo mobile.

I protocolli sono dotati di specifici messaggi, sono descritti dai file con estensione *.msg

di OMNeT++. Essi sono rappresentati da classi C++, estensioni della classe cMessage,


56

generate automaticamente quando è compilato l’INET framework.

Ci sono alcuni moduli in comune a modelli di host, router e device che è opportuno

segnalare:

InterfaceTable che contiene la tabella delle interfacce di rete nell'host. Questo

modulo non invia né riceve messaggi, è acceduto da altri moduli, nella fattispecie

quelli che implementano interfacce di rete, per determinare l’interfaccia attraverso la

quale inviare il pacchetto, usando chiamate a funzioni membro C++.

RoutingTable che contiene la tabella di routing del protocollo IP v.4 (RoutingTable6

ha la tabella IP v.6), si affida all'interfaccia di rete per effettuare le sue operazioni.

Questo modulo è acceduto da altri moduli attraverso chiamate a funzioni membro

C++. Sono presenti funzioni membro per fare query, aggiungere e rimuovere percorsi

nonché per trovare il miglior percorso.

NotificationBoard per fornire la comunicazione in modalità publish-subscribe. Se ad

esempio un modulo modifica il suo stato, se ha sottoscritto una notifica, questa sarà

consegnata agli altri nodi che hanno sottoscritto quella categoria di notifica.

Altri moduli in comune al livello di rete sono:

FlatNetworkConfigurator assegna indirizzi IP agli host ed ai router, impostando il

routing statico.

NetworkConfigurator assegna indirizzi IP agli host ed ai router, impostando il

routing statico ma a differenza del precedente opera anche oltre gli ambienti LAN.

ScenarioManager supporta gli scripting per implementare l'interfaccia

IscriptableC++.

ChannelControl serve per simulazioni wireless, tiene traccia di quali nodi sono nel

raggio di interferenza di altri nodi.

Questo framework offre supporto al multicast, ma le funzioni di instradamento utilizzate

nella modalità unicast, non funzionano per il multicast. Il motivo risiede nel fatto che le

funzioni di instradamento utilizzate per l’unicast, sono definite nei moduli

FlatNetworkConfigurator e NetworkConfigurator che assegnano indirizzi IP solo a nodi e

non a gruppi, nel caso del multicast non essendo loro ad assegnare l’indirizzo multicast,


57

non consentono neppure l’uso delle funzioni di instradamento. L’utente è costretto a

creare degli appositi file di routing di semplice costruzione (con estensione *.rt, *.irt,

*.mrt) in cui configurare i nodi della rete per specificare l’appartenenza ad un gruppo

multicast e specificare il percorso da seguire per raggiungere una data destinazione.

Questi file possono essere utilizzati anche per configurare i nodi di rete e specificare un

percorso nel funzionamento unicast, ma solo nel caso non si voglia utilizzare il

NetworkConfigurator o il FlatNetworkConfigurator.

ifconfig: # ethernet card (modelled by point-to-point link) 0 to router name: ppp0 inet_addr: 172.0.0.1 MTU: 1500 Metric: 1 BROADCAST MULTICAST Groups: 225.0.0.1:225.0.1.1:227.0.2.1 ifconfigend. route: default: 172.0.0.11 0.0.0.0 G 0 ppp0 225.0.0.0 172.0.0.11 255.0.0.0 G 0 ppp0 routeend. ifconfig: # ethernet card (modelled by point-to-point link) 0 to host 1 name: ppp0 inet_addr: 172.0.0.11 MTU: 1500 Metric: 1 BROADCAST MULTICAST # ethernet card (modelled by point-to-point link) 1 to host 2 name: ppp1 inet_addr: 172.0.0.12 MTU: 1500 Metric: 1 BROADCAST MULTICAST # ethernet card (modelled by point-to-point link) 2 to host 3 name: ppp2 inet_addr: 172.0.0.13 MTU: 1500 Metric: 1 BROADCAST MULTICAST # PPP link to router 2 name: ppp3 inet_addr: 172.1.0.0 MTU: 512000 Metric: 1 ifconfigend. route: 172.0.0.1 * 255.255.255.255 H 0 ppp0 172.0.0.2 * 255.255.255.255 H 0 ppp1 172.0.0.3 * 255.255.255.255 H 0 ppp2 default: 172.1.0.1 0.0.0.0 G 0 ppp3 225.0.0.1 * 255.255.255.255 H 0 ppp0 225.0.0.1 * 255.255.255.255 H 0 ppp1 225.0.0.1 * 255.255.255.255 H 0 ppp2


58

225.0.0.2 172.1.0.1 255.255.255.255 G 0 ppp3 225.0.0.3 172.1.0.1 255.255.255.255 G 0 ppp3 225.0.1.1 * 255.255.255.255 H 0 ppp0 225.0.1.1 172.1.0.1 255.255.255.255 G 0 ppp3 225.0.1.2 * 255.255.255.255 H 0 ppp1 225.0.1.2 * 255.255.255.255 H 0 ppp2 225.0.1.2 172.1.0.1 255.255.255.255 G 0 ppp3 225.0.2.1 * 255.255.255.255 H 0 ppp1 225.0.2.1 * 255.255.255.255 H 0 ppp2 225.0.2.1 172.1.0.1 255.255.255.255 G 0 ppp3 routeend.

Figura 10 - Esempio di file di routing per un host ed un router

Quando un protocollo di livello superiore vuole inviare un pacchetto dati ad un protocollo

di livello inferiore, invia l'oggetto messaggio che rappresenta il pacchetto incapsulandolo.

Il processo di invio dal basso verso l'alto, prevede l'operazione inversa a quella di

incapsulamento del pacchetto. Spesso è necessario trasportare informazioni aggiuntive

con il pacchetto, ad esempio inviando dati su TCP o UDP serve un identificatore della

connessione TCP o informazioni utilizzate da UDP nel messaggio inviato dal livello

applicativo. TCP o UDP a loro volta inviano un segmento su IP, il messaggio a livello

trasporto necessita di un indirizzo destinazione ed altri parametri come TTL,

analogamente IP effettua l'invio di datagrammi verso un'interfaccia Ethernet, anche qui

nel messaggio di livello rete bisogna specificare un indirizzo MAC. Queste informazioni

aggiuntive sono attaccate al messaggio oggetto come informazioni di controllo che sono

piccoli oggetti attaccati ai pacchetti con la relativa funzione membro.


59

Figura 12 - Visualizzazione dei componenti di un’entità OMNeT++

Figura 11 - Esempio delle informazioni di controllo di un pacchetto UDP


60

All'interno di host e router sono presenti diverse entità (possono essere sia simple che

compound module), ad esempio un possibile modello di host client contiene:

un'interfaccia Ethernet, il livello rete, un'applicazione (ping), un modello UDP ed uno

TCP, un modello applicativo (soprastante TCP), la tabella di routing ed un modulo per

consentire possibili estensioni future [27].

61

Capitolo 3 Descrizione del modello

Il modello è costituito dalle entità RTPS mostrate nel diagramma delle classi in Figura 13,

classi realizzate mediante simple module di OMNeT++ estesi mediante codice C++. Essi

generano eventi e reagiscono ad essi, ad eccezione delle entità CacheChange ed

HistoryCache che invece sono delle normali classi C++.

Al fine di effettuare una simulazione è stato utilizzato il framework INET che offre

un’implementazione dello stack protocollare sottostante RTPS, utilizzando gli strati

UDP/IP.


62

Figura 13 - Diagramma delle classi

3.1 Descrizione delle entità

E’ qui offerta una breve descrizione delle caratteristiche delle classi implementate, per

ogni simple module è mostrata una tabella riassuntiva contenente porti, ruolo del porto e

tipologia del porto: scalare (consente l’uso di un unico porto) o vettoriale (consente l’uso

di più porti).Un’altra tabella contiene i parametri dell’entità in esame con una loro

descrizione.

DDSDataWriter

Entità che estende le proprie funzionalità mediante classe C++, implementa un leggero

strato DDS che funge da interfaccia applicativa lato Publisher, in questo modulo sono

settate le politiche di QoS implementate.

Questa classe ha il compito di dare inizio alla simulazione e di pubblicare i pacchetti che

viaggeranno attraverso la rete sottostante, ha anche il compito al termine della


63

simulazione, di effettuare la scrittura sul file di log delle informazioni sui dati statistici

relativi all’entità dei ritardi e sul numero di pacchetti trasmessi in rete.

Porto Ruolo Tipologia

from_rtps input da RTPS scalare

to_rtps output verso RTPS scalare

Parametro Descrizione

message_freq Frequenza alla quale il Publisher invia messaggi

all’RTPS Writer ed alla HistoryCache.

reliabilitylevel Livello di affidabilità: best-effort (settato a 0) o

reliable (settato a 1).

history Modalità di svuotamento delle HistoryCache:

keep_last (settato a 0) o keep_all (settato a 1).

resourcelimit Dimensione massima della HistoryCache.

depth Limite oltre il quale svuotare le HistoryCache

per History keep-last.

max_block_time Periodo di tempo oltre il quale la HistoryCache

bloccata viene svuotata.

ownership Modalità di utilizzo dei Subscriber: shared

(settato a 0) o exclusive (settato a 1).

ownershipstrength In caso di ownership exclusive il Publisher

settato a 1 ha la priorità sugli altri Publisher.

DDSDataReader

Entità che estende le proprie funzionalità mediante classe C++, implementa un leggero

strato DDS che funge da interfaccia applicativa lato Subscriber, in questo modulo sono

settate le politiche di QoS implementate.


64

Fornisce le funzioni per effettuare le operazioni di read() o di take() secondo quanto

previsto dall’utente nel file di configurazione.


from_rtps input da RTPS scalare

to_rtps output verso RTPS scalare


message_freq Frequenza alla quale il Subscriber verifica lo

stato della HistoryCache.

reliabilitylevel Livello di affidabilità: best-effort (settato a 0) o

reliable (settato a 1).

history Modalità di svuotamento delle HistoryCache:

keep_last (settato a 0) o keep_all (settato a 1).

resourcelimit Dimensione massima della HistoryCache.

depth Limite oltre il quale svuotare le HistoryCache

per History keep-last.

ownership Modalità di utilizzo dei Subscriber: shared

(settato a 0) o exclusive (settato a 1).

modo Modalità di utilizzo dei dati dalla HistoryCache

lato Reader: read (settato a 0), take (settato a 1).

UDPRTPSBase

Entità che estende le proprie funzionalità mediante classe C++, contiene

l’implementazione di alcune funzioni di utilità per Writer e Reader RTPS (StatelessWriter

e StatelessReader): binding ad un porto specificato, invio dei pacchetti al livello UDP

fornendo il messaggio da trasmettere, numero di porto sorgente e destinazione ed indirizzo

di rete e stampa a video alcuni dati relativi al pacchetto da trasmettere.



65

from_udp input da UDP scalare

to_udp output verso UDP scalare

StatelessWriter

E’ una classe C++ che eredita la classe UDPRTPSBase, implementa lo RTPS Writer

secondo la modalità stateless che non mantiene molte informazioni di stato sulle entità

remote, conferendo maggiori vantaggi in termini di scalabilità.

Contiene un attributo per settare l’heartbeatperiod e fornisce la funzione per effettuare la

pubblicazione di un dato (newchange()) da trasmettere attraverso la rete al subscriber.




from_dds input da DDS scalare

to_dds output verso DDS scalare


message_freq Frequenza alla quale il Publisher inietta

messaggi sulla rete.

numUdpApps Numero di connessioni UDP da aprire su ogni

StatelessWriter.

udpAppType Stringa che specifica il tipo di connessione UDP

per un dato nodo (è il nome di un file, nella

fattispecie StatelessWriter).

message_length Lunghezza del messaggio DATA in bit.

packet_loss Probabilità di perdita di un pacchetto localmente

al nodo Publisher.

heartbeatperiod Periodo di tempo oltre il quale è effettuata la


66

ritrasmissione dell’Heartbeat nel caso per quello

inviato in precedenza non si sia avuto un

riscontro.

local_port Numero del porto in uscita.

dest_port Numero del porto in entrata.

dest_addresses Stringa mediante la quale sono digitati i nomi o

direttamente gli indirizzi IP dei nodi che

fungono da Subscriber.

read_addresses Stringa mediante la quale sono digitati i nomi o


fungono da Subscriber, ma a differenza del

precedente campo serve solo in caso di

ritrasmissione di pacchetti.

pushmode Funzionamento push (settato a 0) pull (settato a

1).

StatelessReader

E’ una classe C++ che eredita la classe UDPRTPSBase, implementa lo RTPS Reader,

anch’esso realizzato in modalità stateless, senza mantenere molte informazioni di stato

sulle entità remote.




from_dds input da DDS scalare

to_dds output verso DDS scalare


numUdpApps Numero di connessioni UDP da aprire su ogni


67

StatelessReader.

udpAppType Stringa che specifica il tipo di connessione UDP

per un dato nodo (è il nome di un file, nella

fattispecie StatelessReader).

message_length Lunghezza del messaggio DATA in bit.

packet_loss Probabilità di perdita di un pacchetto sui canali

che connettono al nodo Subscriber.

local_port Numero del porto in uscita.

dest_port Numero del porto in entrata.

dest_addresses Stringa mediante la quale sono digitati i nomi o


fungono da Publisher.

HistoryCache

Entità realizzata mediante una classe C++, implementa le operazioni su una tabella

dinamica con inserimenti ordinati sulla base del numero di sequenza del pacchetto

pubblicato.

E’ presente un’istanza di questa tabella sul lato Publisher ed una sul lato Subscriber.

Il suo ruolo lato Publisher è quello di garantire una copia aggiornata degli ultimi pacchetti

trasmessi, copia che sarà utilizzata in caso di ritrasmissione, ma solo in seguito ad un

apposito segnale di mancata ricezione da parte del Subscriber.

L’istanza presente sul lato Subscriber, ha il compito di interfacciare il livello DDS con il

livello RTPS, utile soprattutto in fase di creazione dei messaggi di ACKNACK poiché è

da questa tabella che sono recuperate le informazioni necessarie. Inoltre il livello DDS in

fase di lettura e comunicazione reliable, necessita che i dati nella HistoryCache siano

presenti in ordine ed i numeri di sequenza, precedenti a quello di cui si effettua la lettura,

siano disponibili nella HistoryCache, perciò nasce l’esigenza di realizzare questa tabella.


68

L’HistoryCache fornisce le funzioni per effettuare l’aggiunta di un campo, la rimozione, la

lettura e lo svuotamento dell’intera tabella o di un singolo campo. Altre funzionalità

offerte, mostrate di seguito, sono quelle per la ricerca di dati nella tabella ed il settaggio

dei campi relativi allo stato:

searchsn: verifica il campo statusreader, restituisce il valore del sequencenumber del

primo statusreader settato a false, è invocato dallo StatelessWriter in fase di creazione

dell’HEARTBEAT. Il valore statusreader false indica che in corrispondenza di quel

sequencenumber non è avvenuto il riscontro da parte dell’acknack, quindi da quel

sequencenumber in poi, è richiesto l’HEARTBEAT per questi messaggi;

searchb: ricerca nella tabella un dato sulla base del sequencenumber e verifica lo

statusreader, scorrendo la tabella (quindi cresce il valore del sequencenumber), al

primo valore dello statureader a false, restituisce il booleano true per indicare che fino

a quel punto, i dati sono tutti ordinati in memoria. E’ invocato dallo StatelessReader

per costruire l’ACKNACK;

searchset: setta statusreader a true per i dati nella HistoryCache che sono in ordine,

è invocato dall StatelessReader;

searchack: effettua la ricerca di un dato nella HistoryCache sulla base del

sequencenumber e restituisce la struttura ad esso associata, è invocato dallo

StatelessWriter in caso di ritrasmissione di un pacchetto per prelevare i dati da

ritrasmettere dalla HistoryCache;

settasr: setta il valore dello statusreader a true nella HistoryCache lato Writer, solo

nel caso in cui non c’è bisogno di effettuare la ritrasmissione del pacchetto.

La HistoryCache è istanziata localmente da ogni nodo sia lato Publisher che lato

Subscriber.

CacheChange

Entità realizzata mediante una classe C++, implementa una tabella dinamica costituita da


69

record contenenti elementi identificativi dei pacchetti: tipo, valore del dato da trasmettere,

identificativo del nodo che trasmette, sequencenumber ed i bit relativi allo stato del reader.

La classe invece presenta oltre ad un attributo che punta alla struttura, un contatore che

tiene traccia del numero di elementi in tabella. Fornisce la funzione per effettuare

l’aggiunta di un campo in testa alla tabella.

3.2 Moduli OMNeT++

Un’altra categoria di moduli non prevede l’estensione mediante classi C++, quindi non

serve compilarli prima di effettuare una simulazione.

RTPS

Modulo in cui è definita la topologia della rete, sono impostate le proprietà della rete

mediante il modulo network properties e le proprietà dei canali mediante il modulo

channel properties in cui è possibile settare delay, data rate e bit error rate.

In Figura 14 è mostrato un esempio di topologia di rete in cui si identifica un host Writer

connesso ad un router, il quale è connesso ad altri due router (r2, r3)che separano la rete in

due rami. Il ramo servito dal router r2 che serve tre host Reader ed il ramo servito dal

router r3 che serve altri tre host Reader.


70

Figura 14 - Esempio di topologia di rete simulata

RTPSHostWriter

SimpleModule in cui è definito l’host Writer a partire dal livello DDS, seguito dal livello

RTPS e gli strati sottostanti (UDP/IP).


in input da PPP vettore

out output verso PPP vettore

ethIn input da ethernet vettore

ethOut output verso ethernet vettore


71

Figura 15 - Host Writer

RTPSHostReader

SimpleModule in cui è definito l’host Reader a partire dal livello DDS, seguito dal livello

RTPS e gli strati sottostanti (UDP/IP).


in input da PPP vettore

out output verso PPP vettore

ethIn input da ethernet vettore

ethOut output verso ethernet vettore


72

Figura 16 - Host Reader

3.3 Funzionamento del modello

L’utente che si accinge ad effettuare una simulazione deve settare i parametri nel file di

configurazione omnetpp.ini, nel caso alcuni di essi non siano settati quando è lanciata

l’esecuzione della simulazione, una finestra di dialogo invita l’utente a settare il parametro

che non è stato settato (ove non siano previsti i valori di default). I parametri da settare

sono tutti quelli definiti nei simple module OMNeT++ precedentemente descritti,

rispettando i tipi definiti nel file stesso, a seconda delle esigenze. L’utente potrebbe

decidere di modificare i valori di default per gli strati sottostanti RTPS, come ad esempio

le dimensioni delle code, che per reti aventi un elevato numero di nodi è opportuno settare,

al fine di evitare perdite di pacchetti a causa delle stesse code sovraccariche. In merito ad

eventuali ritardi ed altri parametri caratteristici, bisogna specificare direttamente da questo


73

file gli eventuali valori da utilizzare per la simulazione. Tra i parametri relativi al

funzionamento generale del simulatore è necessario settare preload-ned-files che

contiene il path relativo al file nedfiles.lst, nel quale sono specificati i percorsi relativi

ai file NED utili alla simulazione, essi sono caricati a run-time. Un altro parametro utile è

quello relativo allo spazio allocato per lo stack, total-stack-kb, che conviene

specificare in caso di un notevole utilizzo di questa area di memoria. Una nota riguarda il

parametro relativo al campo dest_addresses e read_addresses su StatelessWriter e

StatelessReader sul quale è possibile settare più di un indirizzo, inoltre bisogna fare

attenzione a scrivere il nome esatto dell’host specificato nel file in cui è definita la rete da

simulare. E’ possibile sia inserire direttamente l’indirizzo IP corrispondente ad un dato

host, sia il nome rappresentativo dell’host, nel caso di comunicazione multicast bisogna

inserire necessariamente l’indirizzo del gruppo multicast al quale inviare i dati.

Da questo file è possibile specificare le dimensioni dei pacchetti di tipo DATA trasmessi a

livello RTPS (espressi in bit).

Il modello rappresentato supporta sia il funzionamento unicast che quello multicast,

modalità che è possibile settare direttamente specificando l’indirizzo di destinazione.

Nel funzionamento unicast l’INET framework offre un eccellente ausilio all’utilizzatore,

poiché mediante il FlatNetworkConfigurator e la classe cTopology, oltre ad assegnare gli

indirizzi agli host, specifica il percorso ottimale per raggiungere la destinazione.

Nel funzionamento multicast, invece, l’INET framework pur supportando questa modalità

di funzionamento, offre un’assistenza meno completa all’utilizzatore, gli indirizzi agli

elementi IP della rete sono assegnati dal FlatNetworkConfigurator, ma spetta all’utente

assegnare i nodi ad un gruppo multicast e specificarne il percorso, operazione possibile

mediante la creazione di un file di routing per gli elementi IP coinvolti nel multicast (con

estensione *.mrt), che di fatto svolge il ruolo del FlatNetworkConfigurator.

Il percorso di questo file deve essere specificato nel modulo RTPSNet (file rtps.ned) che

definisce la rete da simulare tra i parametri che caratterizzano i nodi della rete (campo


74

routingFile).

Si offre di seguito un esempio dei file di routing necessari per una rete con un nodo

Publisher, un Router e 4 nodi Subscriber:

ifconfig: # interface 0 to router name: eth0 inet_addr: 10.0.0.1 MTU: 1500 Groups: 225.0.0.1 ifconfigend. route: default: 10.0.0.6 0.0.0.0 G 0 eth0 225.0.0.1 10.0.0.6 255.255.0.0 G 0 eth0 routeend.

Figura 17 - Esempio file di routing nodo Publisher

Nella prima parte del file (ifconfig: ... ifconfigend.) è specificata la configurazione

del nodo, specificando il nome dell’interfaccia di rete utilizzata per la comunicazione,

l’indirizzo IP del nodo e le dimensioni massime del pacchetto trasferito a livello IP, queste

informazioni sono inserite per completezza, ma sono in ogni caso create automaticamente

dal FlatNetworkConfigurator, l’informazione che è necessario inserire è quella relativa

all’indirizzo del gruppo Multicast.

Nella seconda parte del file (route: ... routeend.) sono invece specificate le

informazioni per raggiungere il router (indirizzo 10.0.0.6).

ifconfig: # interface 0 to host 1 name: eth0 inet_addr: 10.0.0.6 MTU: 1500 # interface 1 to h[0] name: eth1 inet_addr: 10.0.0.6 MTU: 1500 # interface 2 to h[1] name: eth2 inet_addr: 10.0.0.6 MTU: 1500 # interface 3 to h[2] name: eth3 inet_addr: 10.0.0.6 MTU: 1500 # interface 4 to h[3] name: eth4 inet_addr: 10.0.0.6 MTU: 1500 ifconfigend.


75

route: 225.0.0.1 * 255.255.255.255 H 0 eth1 225.0.0.1 * 255.255.255.255 H 0 eth2 225.0.0.1 * 255.255.255.255 H 0 eth3 225.0.0.1 * 255.255.255.255 H 0 eth4 routeend.

Figura 18 - Esempio file di routing del Router

Nella prima parte del file (ifconfig: ... ifconfigend.) è specificata la configurazione

del router, specificando i nomi delle interfacce di rete utilizzate per comunicare con i nodi

a cui il router è connesso, l’indirizzo IP del nodo e le dimensioni massime del pacchetto

trasferito a livello IP.

Nella seconda parte del file (route: ... routeend.) sono invece specificate le

informazioni per raggiungere i nodi Subscriber appartenenti all’indirizzo multicast

specificato (indirizzo 225.0.0.1).

Per i file di routing relativi ai nodi Subscriber, è stata specificata solo la configurazione dei

nodi necessaria per consentire l’assegnazione dei nodi ad un gruppo multicast, evitando di

fornire indicazioni per l’instradamento che sono specificate dal FlatNetworkConfigurator

(riducendosi ad una comunicazione unicast quella dai Subscriber al Publisher).

ifconfig: # interface 1 to router name: eth0 inet_addr: 10.0.0.2 MTU: 1500 Groups: 225.0.0.1 ifconfigend.

ifconfig: # interface 2 to router name: eth0 inet_addr: 10.0.0.3 MTU: 1500 Groups: 225.0.0.1 ifconfigend. ifconfig: # interface 3 to router name: eth0 inet_addr: 10.0.0.4 MTU: 1500 Groups: 225.0.0.1 ifconfigend.


76

ifconfig: # interface 4 to router name: eth0 inet_addr: 10.0.0.5 MTU: 1500 Groups: 225.0.0.1 ifconfigend.

Figura 19 - Esempio di file di routing per 4 nodi Subscriber

A questo punto non si deve fare altro che eseguire la simulazione regolando la velocità che

l’utente preferisce. Si noti che il funzionamento Express non consente di visualizzare

graficamente l’evoluzione dello stato della rete e non fornisce neppure la funzionalità di

stampa a video, privando l’utente della possibilità di interagire con il modello. Nel

funzionamento normale l’utente ha la possibilità di interagire con il modello, sono mostrati

graficamente i pacchetti che viaggiano attraverso la rete con l’indicazione del loro nome e

conteggiati il numero di pacchetti in transito su ogni canale.

I moduli OMNeT++ costituiti da altri moduli o sottomoduli, sono esplorabili anche

durante la fase di esecuzione, consentendo di vedere, ad esempio sugli host, i pacchetti che

attraversano i diversi strati protocollari e le interazioni con le tabelle di routine, nonché il

numero di pacchetti sulle code. Un’altra funzionalità offerta, risultata molto utile per

testare il modello realizzato, è quella che consente l’esplorazione dei messaggi trasmessi

con piena visibilità dei valori assunti da tutti i campi.

La prime operazioni che sono eseguite riguardano l’inizializzazione della rete e delle

variabili: sono invocati i moduli FlatNetworkConfigurator e ChannelInstaller (moduli

appartenenti al framework INET), il primo provvede ad assegnare gli indirizzi IP a tutti i

nodi IP presenti sulla rete, scoprire la topologia della rete (usando la classe cTopology di

OMNeT++), registrare le interfacce di rete mediante il modulo InterfaceTable ed a

specificare nel modulo RoutingTable (entrambi propri di INET) di ogni nodo, i percorsi

(statici) più brevi per raggiungere gli altri nodi, mentre il secondo imposta i parametri sui

canali. I parametri settati dal file di configurazione sono assegnati ai moduli che

costituiscono la rete.


77

Poiché il simulatore è ad eventi discreti, la schedulazione degli eventi avviene o in

corrispondenza dell’invio di messaggi (funzione send()) oppure fissando l’istante di tempo

in cui sarà schedulato l’evento (funzione scheduleAt()); gli eventi sul DDSDataWriter e

StatelessWriter sono schedulati ad un istante di tempo settato mediante un parametro che

regola la frequenza di pubblicazione dei messaggi sul file di configurazione. Per

consentire la schedulazione in sequenza prima del DDSDataWriter e poi dello

StatelessWriter si assegna una priorità maggiore al livello DDS.

Il DDSDataWriter per trasmettere dati invoca la funzione newchange() dello

StatelessWriter, essa ha il ruolo di creare una struttura, atta a contenere i dati da

trasmettere, in modo che il livello RTPS è in grado di procedere alla costruzione del

messaggio autonomamente, nonché a restituire al DDSDataWriter il contenuto di questa

struttura, per effettuare la scrittura dei dati sulla HistoryCache lato Writer, che servirà per

Figura 20 - Interazione tra le entità RTPS


78

un’eventuale ritrasmissione.

Il diagramma in Figura 21 illustra i diversi stati del Writer. I due stati presenti sono quello

di “scrittura”, in cui si pone il Writer dopo che è stato istanziato, quando si trova in

questo stato è pronto a ricevere i dati dal livello DDS, oppure effettuare l’invio dei dati ai

Reader e stato “attesa UDP”, in cui il Writer aspetta di ricevere dati dal livello UDP.

Quando i dati sono stati trasmessi, il Writer si pone nello stato “attesa UDP”: nel caso di

trasmissione best-effort, quando riceve il dato di ECHO, lo memorizza nella HistoryCache

e transita nello stato “scrittura”, la trasmissione reliable effettua la transizione dello stato

solamente se per quel dato non è richiesto ACKNACK, altrimenti resta nello stato

corrente. Quando riceve l’ACKNACK se non è necessaria la ritrasmissione, transita allo

stato “scrittura”, altrimenti effettua la ritrasmissione senza modificare il proprio stato.

Lo StatelessWriter effettua il binding ai porti ed apre le socket di comunicazione, crea il

pacchetto da trasmettere in rete utilizzando le informazioni ricevute dal DDSDataWriter

ed effettua l’invio agli strati protocollari sottostanti. In caso di trasmissione reliable oltre

Figura 21 - Comportamento del Writer


79

al messaggio DATA effettua l’invio del messaggio HEARTBEAT ogni due messaggi

DATA trasmessi (è possibile inviare l’Heartbeat anche per ogni messaggio DATA

trasmesso), esso serve per richiedere la trasmissione di un ACKNACK relativamente ad

un range di sequencenumber associati ai corrispondenti pacchetti.

Il diagramma in Figura 22 illustra i diversi stati del Reader. I due stati presenti sono quello

di “attesa UDP”, in cui si pone il Reader dopo che è stato istanziato, in cui è possibile

ricevere i dati dal livello UDP e quello “attesa dati HistoryCache”, in cui il Reader

aspetta di ricevere dati dalla sua HistoryCache. Quando sono ricevuti i dati da UDP, il

Reader transita nello stato “attesa dati HistoryCache”, modificando i dati nella

HistoryCache del Reader ed aspetta che il livello DDS modifichi il contenuto della

HistoryCache con il messaggio di ECHO. La modifica implica che il Reader trasmetta il

messaggio di ECHO al Writer, provocando la transizione nello stato “attesa UDP”.

Figura 22 - Comportamento del Reader

Quando lo StatelessReader riceve il pacchetto DATA, lo scompatta e crea una struttura

dati da memorizzare nell’apposita HistoryCache lato Reader, nella quale l’inserimento dei

dati è effettuato in ordine (ordine disciplinato dal numero di sequenza), il DDSDataReader

invocando la funzione read() (lettura dei dati dalla HistoryCache, quindi un’invocazione


80

della funzione chang()) o take() (prelievo dei dati letti dalla HistoryCache, quindi

un’invocazione della funzione chang() seguita dalla rimozione del dato dalla

HistoryCache, removechange()) completa l’interazione col Publisher. Nel caso in cui la

modalità di comunicazione sia reliable, lo StatelessReader, dopo aver effettuato

l’operazione di searchset() sulla HistoryCache (che setta a true tutti i campi con

sequencenumber in ordine), invoca searchb() che a seconda del valore restituito (può

essere true o false) indica se riscontrare un ack oppure un nack. Per effettuare il riscontro

sull’acknack nel campo sequencenumberset è rappresentato mediante una struttura che nel

primo campo (base) contiene il valore del primo pacchetto che l’Heartbeat richiede di

riscontrare, nel secondo il numero di pacchetti da riscontrare e nel terzo si codifica in

valore decimale la sequenza di bit che indica i pacchetti di cui è richiesta la ritrasmissione.

Dopo che è stato creato l’ACKNACK, è effettuato l’invio ai livelli protocollari sottostanti

RTPS, quindi il pacchetto giunge allo StatelessWriter che dopo aver decodificato il valore

relativo ai pacchetti di cui necessita la ritrasmissione, effettua dapprima il riscontro dei

pacchetti ricevuti dal Reader e dopo la ricerca nella HistoryCache lato Writer dei pacchetti

che devono essere ritrasmessi. Per le eventuali ritrasmissioni, i pacchetti devono essere

creati in base ai dati ricevuti con l’ACKNACK ed a quelli prelevati dalla HistoryCache

lato Writer. A questo punto è’ effettuato l’invio del nuovo pacchetto (o dei nuovi pacchetti

in caso di perdite multiple), esso giunto sullo StatelessReader è processato come un

normale pacchetto dati, però nel caso in cui sia già presente nella HistoryCache lato

Reader un campo con il numero di sequenza del pacchetto inviato, l’inserimento non

avviene (il pacchetto viene scartato). Nell’eventualità che il tempo che intercorre tra

l’invio del pacchetto originale e la ritrasmissione del pacchetto superi un certo intervallo

temporale, indicato come heartbeatperiod, è effettuato l’invio di un ulteriore

HEARTBEAT identico al precedente.

Per consentire sia alla classe che implementa lo strato applicativo DDS sia a quella che

implementa lo strato RTPS di poter utilizzare i dati della stessa istanza della

HistoryCache, la HistoryCache è rappresentata mediante una variabile statica che consente


81

la visibilità delle modifiche effettuate ad entrambi gli strati: è stata creata un’istanza dello

StatelessWriter sul DDSDataWriter ed un’istanza della HistoryCache sullo StatelessWriter

(analogamente un’istanza dello StatelessReader sul DDSDataReader ed un’istanza della

HistoryCache sullo StatelessReader).

Altre variabili statiche presenti sullo StatelessWriter sono: un vettore contenente il

sequencenumber corrente per ogni publisher, perché i numeri di sequenza sono settati a

livello DDS e la loro visibilità è necessaria anche al livello RTPS, mentre il vettore è

necessario per garantire l’indipendenza dei numeri di sequenza in presenza di più

publisher; variabili per rendere visibili al livello RTPS le politiche di QoS impostate dal

livello DDS che dovranno essere poste dentro il messaggio dati da trasmettere sulla rete ed

una variabile per tenere traccia degli identificativi dei Publisher (solo in presenza di più

Publisher).

Altre variabili statiche presenti invece sullo StatelessReader sono: un contatore degli

ACKNACK ed una variabile per tenere traccia degli identificativi dei Subscriber (in

presenza di più Subscriber).

Un’altra variabile statica presente invece sul DDSDataWriter (e DDSDataReader) è una

variabile per tenere traccia degli identificativi dei Publisher (e dei Subscriber).


82

Per effettuare il calcolo del Round Trip Time è necessario valutare il ritardo end-to-end

dal DDSDataWriter al DDSDataReader e viceversa, poiché sono queste le entità che

fungono da interfaccia di livello applicativo. A tale scopo è stato necessario l’invio di una

copia del messaggio all’indietro (detto di ECHO), questa copia è creata solo per l’ultimo

subscriber, il messaggio che ha viaggiato attraverso la rete è stato scompattato dal livello

RTPS per essere memorizzato nella HistoryCache lato Reader. Il DDSDataReader riceve

una struttura che è copiata e scritta in una HistoryCache creata appositamente per svolgere

le misurazioni, del tutto identica a quella utilizzata dalla simulazione effettiva, per avere

dati delle misurazioni fedeli, essendo il tempo di scrittura sulle HistoryCache dipendente

dalla posizione in cui il dato è inserito (infatti l’inserimento è effettuato in ordine). A

questo punto lo StatelessReader effettua la lettura del dato da rispedire alla sorgente dalla

HistoryCache ed effettua la creazione del pacchetto che invia sul canale. Lo

StatelessWriter scrive il dato sulla HistoryCache lato Writer dedicata alle misurazioni, tale

dato è letto dal DDSDataWriter che provvede a calcolare il Round Trip Time. Questa

Figura 23 - Schema per il calcolo del RTT

Publisher Subscriber Subscriber Subscriber… …

t1

t4

t3

t22

t21

t2n


83

operazione è effettuata per ogni Subscriber in comunicazione con il Publisher. Al termine

della simulazione sul file di log è incluso il valore della mediana del Round Trip Time,

valore massimo e minimo per ogni Subscriber, nonché il valore della deviazione standard

ed il numero di pacchetti a livello RTPS sui quali è stata effettuato il calcolo della

mediana.

Altre informazioni di interesse incluse nel file di log sono: il numero di pacchetti a livello

rete inviati dal Publisher, comprensivi dei messaggi DATA, HEARTBEAT e quelli

necessari ad effettuare le richieste ARP (i quali sono anche conteggiati separatamente ed

anch’essi inclusi nel file di log), nonchè dell’eventuale ritrasmissione di pacchetti in caso

di perdite, conteggiando quindi anche i pacchetti che sono stati persi.

I pacchetti trasmessi a livello rete differiscono dal numero di pacchetti trasmessi agli altri

livelli, poiché la dimensione massima di questi pacchetti è inferiore a quella dei livelli

superiori ed è pari a 1500 byte, quindi in caso di pacchetti di dimensioni superiori è

effettuata la frammentazione, ecco perché c’è la trasmissione di un numero superiore di

pacchetti.

Informazioni analoghe sono calcolate ed incluse nel file di log per il Router e per i nodi

Subscriber.

I nodi Subscriber contano i messaggi trasmessi di tipo DATA (perché è effettuato l’ECHO

del messaggio al fine di calcolare il Round Trip Time), gli ACKNACK e le richieste ARP

(conteggiati anche qui separatamente).

Il Router conta i messaggi in entrata alle diverse interfacce di rete, riportando quindi il

numero di pacchetti che transitano per ogni singola interfaccia.

Un particolare significativo durante la fase di progettazione delle HistoryCache riguarda il

campo statusreader (vettore di booleani), che viene settato di default a false, esso assume

significati diversi a seconda se la HistoryCache sia posta sul lato Writer o Reader:

- lato Writer: il suo utilizzo è previsto solo in una comunicazione di tipo reliable, è creato

un vettore dalle dimensioni pari al numero di subscriber, perché bisogna mantenere


84

informazioni sullo stato della HistoryCache di ogni subscriber. La posizione del vettore i-

esima rappresenta lo stato dell’i-esimo subscriber, essendo un valore booleano, se è settato

a true indica che per il dato con il numero di sequenza corrispondente, il subscriber ha

inviato un ack, quindi non serve alcuna ritrasmissione ed il dato potrebbe anche essere

cancellato dalla HistoryCache;

- lato Reader: il suo utilizzo è previsto anche in una comunicazione di tipo best-effort, è

creato un vettore di dimensione 1, perché bisogna mantenere informazioni sullo stato della

HistoryCache del subscriber stesso. Se è settato a true indica che il dato con il numero di

sequenza corrispondente oltre ad essere stato inserito in ordine nella HistoryCache, i

numeri di sequenza che lo precedono, sono tutti presenti nella HistoryCache, quindi è

possibile effettuare le operazioni di read() e take() dal livello DDS.

I pacchetti che sono stati implementati nella costruzione del modello sono: DATA,

HEARTBEAT, ACKNACK, definiti negli appositi file *.msg, essi hanno un messaggio in

comune, RTPSMsg che sfruttando il meccanismo dell’ereditarietà lo estendono.

RTPSMsg è a sua volta un’estensione della classe cMessage di OMNeT++.


85

Figura 24 - Messaggi

Poiché OMNeT++ ed INET non forniscono meccanismi per simulare la perdita dei

pacchetti è stato necessario implementare un apposito modulo, il quale consente all’utente

di inserire dal file di configurazione (omnetpp.ini) un valore di probabilità di perdita di

pacchetti, interpretato come valore percentuale di perdita.

La possibilità di perdere i pacchetti può essere specificata o su un singolo canale che serve

ad esempio un Subscriber o su più canali.

Di seguito sono mostrati alcuni snapshot dell’esecuzione della topologia di rete mostrata

in Figura 14:


86

Figura 25 - Messaggio DATA sul Writer

In Figura 25, sulla sinistra è mostrato il messaggio DATA (identificato con un puntino

rosso e l’etichetta con il nome) sull’host Writer, è trasmesso attraverso lo stack

protocollare, in particolare è mostrata la trasmissione dal Writer RTPS al livello UDP. Sul

livello UDP è visualizzato il contatore dei pacchetti ricevuti e trasmessi, sulla routing table

e l’interface table sono mostrate rispettivamente route ed interfacce di rete attive, sul

networkLayer il numero di pacchetti contenuti nella coda e non ancora trasmessi. Sulla

destra è visualizzata una porzione dell’interfaccia grafica che visualizza gli eventi che

accadono: si può notare lo stato del vettore di booleani statusreader, che tiene traccia di

quali Subscriber hanno riscontrato i dati inviati. Poiché il dato è appena stato inviato, tutti

visualizzano 0 perché nessuno ha ricevuto il dato, quindi non lo ha riscontrato.


87

Figura 26 - Messaggio DATA trasmesso sulla rete

In Figura 26 è mostrata la trasmissione del messaggio DATA (canale di color giallo, con

associata l’etichetta DATA che identifica il messaggio) sulla rete, in particolare sul canale

che divide l’host Writer dal router.


88

Figura 27 - Messaggio DATA sul Reader

In Figura 27 è mostrato il messaggio DATA dall’host Reader (host4), in particolare è

mostrato il momento in cui è utilizzata la tabella di rouing da parte del networkLayer per

effettuare la consegna del messaggio.


89

Figura 28 - Trasmissione messaggio ACKNACK

In Figura 28 è mostrata la trasmissione del messaggio ACKNACK dall’host Reader

(host6) al router, il canale è identificato dal colore giallo ed il messaggio dall’etichetta

ACKNACK.

90

Capitolo 4 Risultati sperimentali

Il modello per il protocollo OMG RTPS implementato con OMNeT++, necessita di essere

validato. Sono di seguito riportate le analisi quantitative relative alle valutazioni sulla

scalabilità e l’entità dei ritardi di trasmissione.

I parametri per popolare il modello provengono da rilevazioni reali effettuate sulla rete del

consorzio SESM, in particolare il ritardo di propagazione sul canale è stato ottenuto

eseguendo il comando traceroute dal nodo Publisher verso ogni Subscriber e dividendo

questo valore per due per caratterizzare il ritardo in una direzione del canale. Il datarate

del canale è stato ricavato dalle specifiche della scheda di rete, mentre il numero di

messaggi inviati al secondo dal Publisher sono dati reali utilizzati da SELEX-SI in

applicazioni per il controllo del traffico aereo.

4.1 Valutazioni sulla scalabilità

Il primo obiettivo è quello di effettuare dei test per valutare la scalabilità: come

all'aumentare del numero dei nodi degradano le prestazioni.

Tutti i test sono stati effettuati su un processore Intel Core Duo 1.8 Ghz, con 2 GB di

RAM e 4MB di Cache con installato sistema operativo Red Hat Enterprise 4.

I test per la scalabilità sono stati effettuati a partire da un nodo Publisher ed un nodo


91

Subcriber aggiungendo gradualmente nodi Subscriber nel numero di 1, 25, 50, 75 e 100, il

nodo Publisher è interconnesso ai Subscriber mediante un router, i collegamenti utilizzati

sono di tipo ethernet.

La configurazione settata è la seguente:

• Ritardo di propagazione sul canale: 0.000158s

• Data rate del canale 1000Mb/s in configurazione full-duplex

• Dimensioni massime delle HistoryCache (lato Writer e lato Reader): 30 elementi

• Heartbeatperiod: 0,015s con invio di HEARTBEAT message ogni 2 pacchetti dati

inviati

• Maxblocktime: 0,01s

• Messaggi inviati al secondo dal Publisher: 100

• Funzionamento RELIABLE, history settata KEEP_ALL, ownership EXCLUSIVE

• Comunicazione di tipo Unicast.

Sulla rete simulata viaggiano dal publisher i messaggi DATA e gli HEARTBEAT, mentre

dai subscriber gli ACKNACK ed i messaggi di ECHO (che sono copie di messaggi

DATA).

Ogni simulazione è stata monitorata alla partenza e dopo 60 e 120 secondi virtuali di

simulazione (12000 pacchetti DATA trasmessi), valutando la memoria fisica assorbita

dall’esecuzione della simulazione, escludendo la quantità di memoria assorbita dal

simulatore, il Roun Trip Time mediano ed il numero di messaggi pubblicati dal Publisher

Figura 29 - Schema della rete usata per la simulazione


92

che attraversano il livello rete.

020000400006000080000

100000120000140000160000180000200000220000240000

1 25 50 75 100

Numero di nodi

Mem

oria

occ

upat

a (K

B)

0 secondi60 secondi120 secondi

Figura 30 - Memoria occupata al crescere dei nodi (reliable senza perdita di pacchetti)

020000400006000080000

100000120000140000160000180000200000220000240000

1 25 50 75 100 Numero di nodi

Mem

oria

occ

upat

a (K

B)


Figura 31 - Memoria occupata al crescere dei nodi (reliable perdita di pacchetti 10%)


93

020000400006000080000

100000120000140000160000180000200000220000240000


Mem

oria

occ

upat

a (K

B)


Figura 32 - Memoria occupata al crescere dei nodi (reliable perdita di pacchetti 20%)

Un’altra serie di test analoga alla precedente è stata effettuata con la stessa configurazione

utilizzata prima, ma con funzionamento in modalità BEST-EFFORT, quindi la rete non

risulta essere sovraccaricata dai messaggi di HEARTBEAT dal publisher ai subscriber e

dai messaggi di ACKNACK dai subscriber al publisher.

0

2000040000

60000

80000100000

120000

140000160000

180000


Mem

oria

occ

upat

a (K

B)


Figura 33 - Memoria occupata al crescere dei nodi (best-effort senza perdita di pacchetti )


94

0

20000

40000

60000

80000

100000

120000

140000

160000

180000


Mem

oria

occ

upat

a (K

B)


Figura 34 - Memoria occupata al crescere dei nodi (best-effort perdita di pacchetti 10%)

0

20000

40000

60000

80000

100000

120000

140000

160000

180000


Mem

oria

ocu

upat

a (K

B)


Figura 35 - Memoria occupata al crescere dei nodi (best-effort perdita di pacchetti 20%)


95

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

2000000


Num

ero

di p

acch

etti

0% packet loss10% packet loss20% packet lossbest-effort

Figura 36 - Andamenti del numero di pacchetti

3,0E-04

3,5E-04

4,0E-04

4,5E-04

5,0E-04

5,5E-04

1 25 50 75 100Numero di nodi

RTT

med

iano

(sec

)

packet loss 0%packet loss 10%packet loss 20%best-effort

Figura 37 - Andamenti del Round Trip Time mediano

Nei casi di test che prevedono una probabilità di errore non nulla, si simula la perdita di

pacchetti per ogni subscriber.

Dai grafi mostrati (Figure 30-31-32-33-34-35) la rete è popolata con un numero crescente

di nodi fino ad arrivare a 100 (indicati sull’asse delle ascisse), sull’asse delle ordinate si


96

valuta come cresce l’occupazione della memoria: è evidente la maggiore quantità di

memoria occupata in modalità reliable rispetto al caso best-effort, maggiormente

accentuata quando aumenta la percentuale di perdita di pacchetti. Nel caso best-effort

sostanzialmente non c’è differenza nell’occupazione della memoria al variare della

probabilità di perdita di pacchetti, perché non sono memorizzate informazioni aggiuntive

relative alla ritrasmissione dei pacchetti persi.

Il grafico in Figura 36 valuta come al crescere del numero dei nodi, variano il numero di

messaggi a livello rete inviati dal Publisher (indicati sull’asse delle ordinate). Il confronto

ha interessato i tre diversi casi di trasmissione reliable, in cui è incrementata la probabilità

di errore ed il caso best-effort senza nessuna probabilità di errore, poiché in modalità best-

effort all’aumentare della probabilità d’errore non aumenta il numero di messaggi inviati a

livello rete, perché non è effettuata alcuna richiesta di ritrasmissione (dalle tabelle in

Appendice B si evince la somiglianza tra i valori, relativamente al numero di messaggi

inviati a livello rete in modalità best-effort, con e senza perdite di pacchetti). Emerge

chiaramente come l’aumento del numero di pacchetti segua sempre un andamento lineare

al crescere del numero dei nodi. Le pendenze delle linee relative all’andamento dei

pacchetti, mostrano come il caso reliable crei un traffico del 50% superiore rispetto al caso

best-effort. Le simulazioni effettuate sono state monitorate dopo 120 secondi di

esecuzione.

Il grafico in Figura 37 mostra come al crescere del numero dei nodi si discostano i valori

del RTT mediano (indicati sull’asse delle ordinate), all’aumentare della probabilità di

errore (in modalità reliable). L’andamento del numero di messaggi in modalità best-effort

è confrontato con gli andamenti in modalità reliable. In modalità best-effort in presenza di

perdite di pacchetti non c’è una sostanziale differenza dei valori del RTT mediano (dalle

tabelle in Appendice B si evince la somiglianza tra i valori, relativamente ai valori

calcolati del RTT mediano in modalità best-effort, con e senza perdite di pacchetti). Le

pendenze delle linee relative all’andamento del RTT mediano, mostrano come il caso

reliable abbia un degrado superiore al 5%, mentre reliable con perdite introduce un ritardo


97

costante. Le simulazioni effettuate sono state monitorate dopo 120 secondi di esecuzione.

Durante queste campagne di test, sono state effettuate alcune osservazioni sul

comportamento del modello nell’ambiente operativo durante l’esecuzione.

Nel funzionamento reliable con un solo subscriber e pacchetti da 100 byte, l’esecuzione

termina dopo oltre tre giorni di simulazione, si nota che durante l'esecuzione della

simulazione una volta esaurita una fase transitoria iniziale, c'è un utilizzo crescente della

memoria (sia fisica che virtuale) ed un utilizzo della CPU che varia nel range di valori

prossimi al 50%, poco prima della fine dell'esecuzione, la memoria tende ad effettuare

swapping, quindi l'utilizzo della stessa memoria tende a decrescere gradualmente e

contemporaneamente anche la CPU tende ad essere utilizzata sempre meno, infatti le

percentuali tendono ad abbassarsi fino a scendere a valori prossimi al 20%.

Questo comportamento è imitato dalle simulazioni effettuate con un numero crescente di

nodi, nel caso di 100 nodi si osserva che l’esecuzione termina oltre i 50 minuti di

simulazione, le osservazioni fatte sull’utilizzo della CPU e della memoria sono analoghe ai

casi precedenti.

Nel funzionamento best-effort con un solo subscriber e pacchetti da 100 byte, l’esecuzione

termina oltre i quattro giorni di simulazione, si nota che durante l'esecuzione della

simulazione una volta esaurita una fase transitoria iniziale, c'è un utilizzo crescente della

memoria (sia fisica che virtuale) ed un utilizzo della CPU che varia nel range di valori

prossimi al 50%, poco prima della fine dell'esecuzione, la memoria tende ad effettuare

swapping, quindi l'utilizzo della stessa memoria tende a decrescere gradualmente,

contemporaneamente anche la CPU tende ad essere utilizzata sempre meno, infatti le

percentuali tendono ad abbassarsi fino a scendere a valori prossimi al 20%.

Questo comportamento è imitato dalle simulazioni effettuate con un numero crescente di

nodi, nel caso di 100 nodi si osserva che l’esecuzione termina poco oltre i 60 minuti di

simulazione, le osservazioni fatte sull’utilizzo della CPU e della memoria sono analoghe ai

casi precedenti.


98

Dalle prove condotte, il modello realizzato consente di aggiungere un numero di nodi

superiori a 100, sono state lanciate delle simulazioni anche con 170 nodi (la scelta del

numero è imposta dal simulatore, poiché le stringhe accettate per specificare i subscriber,

non consentono di superare i 1024 byte [5]), ma le prestazioni tendono ad essere sempre

meno performanti, poiché inviando sulla rete 100 messaggi al secondo, il tempo di

simulazione virtuale risulta di molto inferiore al tempo di simulazione reale già nel caso di

100 nodi (con il processore utilizzato per questi test, un processore più potente consente di

migliorare questo risultato), ovviamente inviando un numero inferiore di messaggi al

secondo i risultati migliorano.

4.2 Validazione del modello

Un secondo obiettivo è quello di effettuare dei test con un’implementazione già affermata

di OMG RTPS: Ocera Real Time Ethernet (ORTE) [9].

Tutti i test sono stati effettuati su un processore Intel Core Duo 1.8 Ghz, con 2 GB di

RAM e 4MB di Cache con installato sistema operativo Red Hat Enterprise 4.

I test sono stati eseguiti nel testbed del consorzio SESM presso lo stabilimento SELEX-SI

di Giugliano (NA). Le postazioni utilizzate sono dotate di sistema operativo RedHat

Enterprice 4, collegate tra loro attraverso una Gigabit Ethernet. L’affidabilità dei test è

garantita dal fatto che tutti i nodi del testbed hanno uguali caratteristiche software ed

hardware, inoltre il testbed è stato isolato da interazioni con l’esterno per evitare

interferenze.


99

Figura 38 - Rete del consorzio SESM

I test consistono nell’effettuare la misura del Round Trip Time mediano sulla rete reale,

mediante un applicativo sviluppato per ORTE dal CINI-ITEM, variando la dimensione dei

pacchetti.

Si fa notare che l’implementazione ORTE utilizza la sola modalità di comunicazione

unicast, quindi il confronto ha riguardato questa modalità di funzionamento.

Per ogni misurazione sono stati considerati i seguenti scenari operativi:

I. Il calcolatore con indirizzo IP 192.168.100.134 funge da Publisher, mentre quello

con indirizzo IP 192.168.100.135 da Subscriber;

II. Il calcolatore con indirizzo IP 192.168.100.134 funge da Publisher, mentre quelli

con indirizzo IP 192.168.100.135, 192.168.100.136 da Subscriber;

III. Il calcolatore con indirizzo IP 192.168.100.134 funge da Publisher, mentre quelli

con indirizzo IP 192.168.100.135, 192.168.100.136, 192.168.100.137 da

Subscriber;

IV. Il calcolatore con indirizzo IP 192.168.100.134 funge da Publisher, mentre quelli

con indirizzo IP 192.168.100.135, 192.168.100.136, 192.168.100.137 e

192.168.100.138 da Subscriber.

La rete reale è stata modellata mediante il modello simulativo realizzato, estraendo il


100

Round Trip Time mediano.

Il test mediante il modello simulativo di RTPS implementato con il simulatore OMNeT++,

presenta la seguente configurazione:

• Ritardo di propagazione sul canale: 0.000158s

• Data rate del canale 1000Mb/s in configurazione full-duplex

• Dimensioni massime delle HistoryCache (lato Writer e lato Reader): 30 elementi

• Heartbeatperiod: 0,015s con invio di HEARTBEAT message ogni 2 pacchetti dati

inviati

• Maxblocktime: 0,01s

• Messaggi inviati al secondo dal Publisher: 100

• Funzionamento RELIABLE, history settata KEEP_ALL, ownership EXCLUSIVE

• Comunicazione di tipo Unicast.

Sulla rete simulata viaggiano dal publisher i messaggi DATA e gli HEARTBEAT, mentre

dai subscriber gli ACKNACK ed i messaggi di ECHO (che sono copie di messaggi

DATA) con probabilità di perdita nulla.

Ogni simulazione è stata monitorata alla partenza e 60 secondi dopo (6000 pacchetti

DATA trasmessi), valutando il Round Trip Time mediano.

E’ stata fatta variare la dimensione dei pacchetti assegnando i valori in byte pari a 50 e

100.




dai messaggi di ACKNACKdai subscriber al publisher.


101

8,00E-05

9,00E-05

1,00E-04

1,10E-04

1,20E-04

1,30E-04

1,40E-04

1 2 3 4Numero nodi

Erro

re s

imul

azio

ne (s

ec)

50 bytereliable100 bytereliable50 bytebest-effort100 bytebest-effort

Figura 39 - Rappresentazione dell’errore di simulazione

Dal confronto tra i risultati della simulazione e quelli dell’esecuzione reale, emerge un

errore di simulazione che si mantiene pressocchè costante all’aumentare del numero dei

nodi, ma subisce un lieve incremento all’aumentare delle dimensioni dei pacchetti. Queste

osservazioni sono valide sia nel caso reliable che best-effort. I valori dell’errore di

simulazione per questi pacchetti sono prossimi all 20%.

4.3 Confronto con il funzionamento multicast

E’ interessante notare i risultati ottenuti con una simulazione, che con la stessa

configurazione settata per i test appena effettuati (ma con una topologia di rete che utilizza

un numero di nodi subscriber pari a 1-25-50-75-100, facendo variare le dimensioni dei

pacchetti 100-500-1000-1500 byte e la probabilità di errore) utilizza il multicast. Il

confronto ha interessato una simulazione che utilizza l’unicast.

Una prima serie di test ha analizzato il funzionamento in modalità reliable per simulazioni

della durata di 60 secondi (6000 messaggi DATA trasmessi).


102

3,00E-04

5,00E-04

7,00E-04

9,00E-04

1,10E-03

1,30E-03

1,50E-03

1,70E-03


Rou

nd tr

ip ti

me

med

iano

(sec

) unicast 100bytemulticast 100byteunicast 500bytemulticast 500byteunicast 1000bytemulticast 1000byteunicast 1500bytemulticast 1500byte

Figura 40 - Differenza tra simulazione Multicast ed Unicast (reliable senza perdite)

3,00E-04

5,00E-04

7,00E-04

9,00E-04

1,10E-03

1,30E-03

1,50E-03

1,70E-03

1,90E-03


Rou

nd tr

ip ti

me

med

iano

(sec

)

unicast 100bytemulticast 100byteunicast 500bytemulticast 500byteunicast 1000bytemulticast1000 byteunicast 1500bytemulticast1500 byte

Figura 41 - Differenza tra Multicast ed Unicast (reliable con probabilità d’errore 10%)

Dal confronto tra la simulazione che utilizza il multicast e quella che utilizza l’unicast, in

modalità di funzionamento reliable, emerge chiaramente come all’aumentare del numero

di subscriber, si ha un graduale miglioramento delle prestazioni: il Round Trip Time


103

mediano calcolato con le due implementazioni, assume un andamento monotono crescente

nel caso unicast, mentre un andamento pressoché costante nel caso multicast. Per quanto

riguarda la variazione delle dimensioni dei pacchetti, si osserva un naturale aumento del

Round Trip Time mediano all’aumentare delle dimensioni dei pacchetti.

All’aumentare della probabilità di errore (10%), il comportamento rimane sostanzialmente

lo stesso, però l’apprezzamento del multicast all’aumentare del numero di subscriber,

presenta un’entità meno marcata del caso con probabilità di errore nulla. Questo fenomeno

può essere in parte spiegato con il fatto che la ritrasmissione è effettuata in modalità

unicast, poiché se fosse effettuata in modalità multicast ci sarebbe uno spreco, poiché

anche i nodi che non necessitano della ritrasmissione risulterebbero influenzati.




dai messaggi di ACKNACK dai subscriber al publisher.

3,00E-04

5,00E-04

7,00E-04

9,00E-04

1,10E-03

1,30E-03

1,50E-03

1,70E-03


Rou

nd tr

ip ti

me

med

iano

(sec

)

unicast 100bytemulticast 100byteunicast 500bytemulticast 500byteunicast 1000bytemulticast 1000byteunicast 1500bytemulticast 1500byte

Figura 42 - Differenza tra Multicast ed Unicast (best-effort)


104

Dal confronto tra la simulazione che utilizza il multicast e quella che utilizza l’unicast in

modalità di funzionamento best-effort, emerge chiaramente come all’aumentare del

numero di subscriber, si ha un graduale miglioramento delle prestazioni: il Round Trip

Time mediano calcolato con le due implementazioni, assume un andamento monotono

crescente nel caso unicast, mentre un andamento pressoché costante nel caso multicast.

Per quanto riguarda la variazione delle dimensioni dei pacchetti, si osserva un naturale

aumento del Round Trip Time mediano all’aumentare delle dimensioni dei pacchetti.

Un’altra analisi ha riguardato l’andamento del numero di pacchetti a livello rete inviati dal

Publisher. Una prima serie di test ha interessato il funzionamento in modalità reliable per

simulazioni della durata di 30 minuti (180000 messaggi DATA trasmessi). Le prove sono

state effettuate per pacchetti di dimensioni di 100 e 1500 byte perchè pacchetti di 1500

byte subiscono una frammentazione a livello rete.

0200000400000600000800000

100000012000001400000160000018000002000000

1 2 3 4Numero di nodi

Num

ero

di p

acch

etti

unicast 100bytemulticast100 byteunicast 1500bytemulticast1500 byte

Figura 43 - Andamento del numero di pacchetti in multicast ed unicast (reliable)

Un’altra serie di test analoga alla precedente è stata effettuata con funzionamento in

modalità BEST-EFFORT.


105

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1 2 3 4Numero di nodi

Num

ero

di p

acch

etti

unicast 100byte

multicast 100byte

unicast 1500byte

multicast 1500byte

Figura 44 - Andamento del numero di pacchetti in multicast ed unicast (best-effort)

Da questi test è possibile osservare come nel funzionamento unicast, il numero dei

pacchetti inviati segue un andamento lineare al crescere del numero dei nodi, mentre nel

caso multicast è costante, sia che si tratti di trasmissione reliable che best-effort. Solo nel

caso unicast reliable con pacchetti di 1500 byte, i messaggi di HEARTBEAT

conferiscono un andamento non lineare alla funzione rappresentata: infatti i pacchetti

DATA sono frammentati in due pezzi, mentre gli altri restano in numero uguale non

avendo bisogno di essere frammmentati.


106

0

200000

400000

600000

800000

1000000

1200000

1400000

25 50 75 100

Messaggi al secondo

Num

ero

di p

acch

etti

reliable senzaperdite

reliableperdite 10%

best-effort

reliableperdite 10%multicastreliable senzaperditemulticastbest-effortsenza perditemulticast

Figura 45 - Andamento dei pacchetti al variare della frequenza di trasmissione

Dal grafico in Figura 45 si osserva l’andamento del numero di pacchetti a livello rete al

variare della frequenza di invio dei messaggi dal Publisher (test effettuati per pacchetti di

100 byte per 30 minuti di simulazione) sia nel caso multicast che best-effort.

Incrementando il numero di paccheti trasmessi dal Publisher, cresce il numero di pacchetti

trasmessi in maniera lineare sia nel caso unicast che in quello multicast. Anche da questo

grafico si può apprezzare la potenza del multicast nell’abbassare il numero di pacchetti che

sono creati dal Publisher ed inviati sulla rete.

05000

1000015000200002500030000350004000045000

10 20 30Dimensioni code

Num

ero

di p

acch

etti


reliableperdite 10%

reliableperdite 20%

reliableperdite 10%multicastreliable senzaperditemulticastreliableperdite 20%multicast

Figura 46 - Andamento del numero di pacchetti al varaiare delle dimensioni delle HistoryCache


107

3,20E-04

3,30E-04

3,40E-04

3,50E-04

3,60E-04

3,70E-04

3,80E-04

3,90E-04

10 20 30Dimensioni code

Rou

nd T

rip T

ime

med

iano

(sec

)


reliable perdite10%

reliable perdite20%

reliable perdite10% multicast

reliable senzaperditemulticastreliable perdite20% multicast

Figura 47 - Andamento del RTT mediano al variare delle dimensioni delle HistoryCache

Nel grafico di Figura 46 è mostrato come aumentando gradualmente le dimensioni delle

HistoryCache, in una comunicazione di tipo reliable con perdite, si ha un miglioramento

delle prestazioni, poiché si riduce il numero di pacchetti generati a livello rete. Il caso

senza perdite (come mostrato dalle tabelle in Appendice B) mantiene un andamento

costante del numero di pacchetti, anche all’aumentare delle dimensioni delle

HistoryCache, poiché non vi è la necessità di richiedere ritrasmissioni. Il caso con perdite

del 10% presenta una piccola flessione del numero di pacchetti trasmessi, all’aumentare

delle dimensioni delle HistoryCache (come mostrato dalle tabelle in Appendice B). Il caso

con perdite del 20% presenta una maggiore flessione del numero di pacchetti trasmessi,

all’aumentare delle dimensioni delle HistoryCache. Questa maggiore flessione registrata

nell’ultimo caso, è giustificabile dal maggior numero di ritrasmissioni e richieste di

ritrasmissioni necessarie, a causa dell’assenza di informazioni sufficienti nelle

HistoryCache. Le considerazioni svolte, sono uguali sia nel caso unicast che multicast,

l’unica differenza interessa il numero di pacchetti trasmessi.

Nel grafico di Figura 47 è mostrato come aumentando gradualmente le dimensioni delle

HistoryCache, in una comunicazione di tipo reliable con perdite, si ha un miglioramento

delle prestazioni, poiché si riduce il Round Trip Time mediano. Il caso senza perdite

(come mostrato dalle tabelle in Appendice B) mantiene un andamento costante del Round

Trip Time mediano, anche all’aumentare delle dimensioni delle HistoryCache, poiché non

vi è la necessità di richiedere ritrasmissioni. Il caso con perdite del 10% presenta un

piccolo peggioramento del Round Trip Time mediano, all’aumentare delle dimensioni

delle HistoryCache (come mostrato dalle tabelle in Appendice B). Il caso con perdite del


108

20% presenta un maggiore peggioramento del Round Trip Time mediano (per

HistoryCache di dimensioni 10 il Round Trip Time mediano, assume valori

particolarmente elevati rispetto al caso con HistoryCache di dimensione maggiore),

all’aumentare delle dimensioni delle HistoryCache. Questa maggiore flessione registrata

nell’ultimo caso, è giustificabile dal maggior numero di ritrasmissioni e richieste di

ritrasmissioni, necessarie a causa dell’assenza di informazioni sufficienti nelle

HistoryCache. Le considerazioni svolte sono uguali sia nel caso unicast che multicast,

l’unica differenza interessa il Round Trip Time mediano.

Una simulazione ha interessato la trasmissione reliable di 6000 pacchetti di 16 byte, per 1-

25-50-75-100-125-150 nodi, il vincolo prestazionale per il RTT mediano fornito da Selex-

SI (eFDPfi_MW_DDS_3), è pari a 20 ms. Per i test effettuati, anche nel caso unicast è

ampiamente soddisfatto questo vincolo.

3,00E-043,20E-043,40E-043,60E-043,80E-044,00E-044,20E-044,40E-044,60E-044,80E-045,00E-04

1 25 50 75 100 125 150

Numero di nodi

Roun

d Tr

ip T

ime

med

iano

(sec

)

unicastreliable16 bytemulticastreliable16 byte

Figura 48 - Andamento del RTT mediano per 16 byte

109

Conclusioni

Il modello consente l'aggiunta di nodi in maniera agevole, inoltre si osserva anche come

sia possibile variare le dimensioni dei pacchetti in maniera altrettanto agevole.

La presenza di una rete affidabile è importante per una trasmissione reliable, poichè in

caso di perdita di pacchetti si ha un degrado del Round Trip Time mediano ed a seconda

delle esigenze applicative, è necessario valutare l'effettivo vantaggio, nell'utilizzare questo

protocollo di comunicazione. Ad esempio in scenari WAN la probabilità di errore cresce,

quindi è utile capire quali siano i limiti temporali oltre i quali l'incremento del Round Trip

Time mediano non è più tollerabile dall'applicazione.

Un confronto con un'implementazione reale di OMG RTPS ha mostrato come i risultati

della simulazione, presentano un basso errore di simulazione pari al 20% circa.

E’ stato interessante notare come il modello realizzato, consenta l’utilizzo dell’opzione

multicast che introduce un ulteriore grado di ottimizzazione relativamente al Round Trip

Time mediano. Esso presenta un andamento pressoché costante all’aumentare del numero

di nodi, rendendo il modello decisamente più scalabile. Il numero di pacchetti trasmessi

nella modalità di funzionamento multicast ha un’andamento costante al crescere del

numero dei nodi, a differenza del caso unicast che presenta un andamento lineare.

Aumentando la frequenza di trasmissione, il numero di messaggi trasmessi sulla rete in un

intervallo di tempo diminuisce, aumentando le dimensioni delle HistoryCache, il numero

di messaggi trasmessi sulla rete in un intervallo di tempo ed il Round trip time mediano

diminuiscono in comunicazioni con perdite, sono costanti in comunicazioni senza perdite.

I vincoli imposti da Selex-SI sono soddisfatti per i test effettuati.

110

Sviluppi futuri

Il modello realizzato risulta essere una buona implementazione degli aspetti che hanno

interessato lo studio affrontato in questo lavoro di tesi. Sono però possibili degli

aggiornamenti soprattutto per quanto riguarda il modulo relativo al discovery, poiché è il

modulo che lascia maggiore spazio agli implementatori ed è quindi possibile introdurre

soluzioni alternative.

Altri sviluppi potrebbero interessare lo studio di altre politiche di QoS e la modellazione

mediante OMNeT++ dello strato DDS, poiché scopo di questo lavoro di tesi è stato quello

di studiare RTPS, ma poiché per effettuare i test è stato necessario l’utilizzo di un

interfaccia di livello superiore, si è scelto di fornire le funzionalità di base del DDS.

Le valutazioni principali su questo modello sono state orientate alla valutazione di alcune

metriche ed alla scalabilità.

Allo stato attuale non è stato necessario calcolare altre metriche, se le esigenze lo

richiedano sarà possibile introdurre nuove metriche nel modello.

OMNeT++ è un simulatore ancora in fase di crescita, presenta alcune inefficienze nella

gestione della memoria che con le versioni successive dovrebbero subire dei

miglioramenti.

Selex-SI sta fornendo nuovi vincoli prestazionali, quindi alla luce di questi dati sarà

possibile effettuare ulteriori test.

111

Appendice A Utilizzare OMNeT++

L'installazione di OMNeT++ su una macchina Linux, necessita dell'installazione delle

librerie Tcl/Tk ed il supporto per le XFT, seguendo la seguente procedura (da riga di

comando):

tar zxvf tcl8.5a5-src.tar.gz

cd tcl8.5a5

./configure --prefix=/usr

make

make install (da effettuare da utente root)

e

tar zxvf tk8.5a5-src.tar.gz

cd tk8.5a5

./configure --prefix=/usr --enable-xft

make

make install (da effettuare da utente root)

poi è necessario settare le variabili d'ambiente per OMNeT++, il framework INET e le tcl

digitando da riga di comando vi .bashrc quindi modificando il relativo file:

export PATH=$PATH:/home/francesco/omnetpp-3.3/bin

export LD_LIBRARY_PATH=/home/francesco/omnetpp-

3.3/lib:/home/francesco/INET/bin


112

export TCL_LIBRARY=/usr/share/tcl8.4

A questo punto è possibile installare OMNeT++:

tar zxvf omnetpp-3.3-src.tar.gz

cd omnetpp-3.3

./configure

make

Per eseguire un esempio, è possibile posizionarsi nella cartella dell'esempio e digitare

./nome_eseguibile.

E' necessario creare il Makefile in base ai file sorgenti presenti nella directory, mediante il

comando opp_makemake.

Se i file non sono stati compilati, bisogna digitare make -k da riga di comando che genera

il file eseguibile.

Per utilizzare INET Framework (le variabili d'ambiente sono state già settate):

tar zxvf INET-src.gz

cd INET

./configure

make

quindi bisogna settare il path del file omnetconfig nel file inetconfig, la gestione dei

progetti è analoga a quella di OMNeT++, essendo INET una raccolta di modelli per

OMNeT++.

113

Appendice B Tabelle relative ai risultati sperimentali

VALUTAZIONI SULLA SCALABILITÀ

Comunicazione reliable, probabilità di errore nulla

Test 1: 1 Publisher ed 1 Subscriber

Tempo

virtuale di

simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)

RTT mediano (sec) Messaggi liv.

rete dal

Publisher

0 0 11488 0

60 3 12128

120 5 12616 0,000321404950661 18003

Test 2: 1 Publisher e 25 Subscriber

Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 13708 0

60 81 38344


114

120 162 62908 0,000362684950612 450051


Tempo

virtuale di

simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 14636 0

60 205 66032

120 409 117668 0,00040568495056 900101


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 15192 0

60 364 95128

120 728 173728 0,000448684950508 1350151


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 17744 0

60 552 126192

120 1104 236304 0,000491684950456 1800201


115

Comunicazione reliable, probabilità di errore 10%


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)

RTT mediano

(sec)

Messaggi liv.

rete dal

Publisher

0 0 11348 0

60 3 12224

120 5 12988 0,00035032047066 19083


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 13432 0

60 82 32284

120 165 51000 0,000392426070609 477051


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 14636 0

60 219 66032

120 439 117668 0,000436286070557 954101



116

Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 15020 0

60 367 96228

120 734 176104 0,000480146070504 1431151


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 16908 0

60 565 127368

120 1130 239288 0,000524006070451 1908201



Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 11756 0

60 3 12824

120 5 13964 0,000366404310659 19683


Tempo virtuale

di simulazione

Tempo reale di

simulazione

Memoria

occupata


rete dal


117

(sec) (sec) (KB) Publisher

0 0 13460 0

60 85 38728

120 170 63728 0,000409857750609 492051


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 14412 0

60 223 67192

120 445 120652 0,000455121750557 984101


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 16732 0

60 376 98780

120 752 179648 0,000500385750505 1476151


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 17568 0


118

60 567 132388

120 1133 242940 0,000545649750452 1968201

Comunicazione best-effort, probabilità di errore nulla


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 11388 0

60 2 12280

120 3 13112 0,000321404950661 12003


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 13432 0

60 55 32284

120 110 51000 0,000353276950641 300051


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)

RTT mediano

(sec)

Messaggi liv.

rete dal

Publisher

0 0 14672 0

60 153 53648


119

120 307 92080 0,00038647695062 600101


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 15732 0

60 251 75040

120 503 134484 0,000419676950599 900151


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 16596 0

60 396 93948

120 792 177932 0,000452876950578 1200201

Probabilità di errore 10%


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 11284 0

60 2 12160

120 3 12924 0,000321414143585 1200201


120


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 13216 0

60 52 30896

120 104 48480 0,000353476950756 300051


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 15344 0

60 145 51584

120 289 87968 0,000386486143543 600101


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 16756 0

60 239 72400

120 476 128152 0,000419686143522 900151


Tempo virtuale

di simulazione

Tempo reale di

simulazione

Memoria

occupata


rete dal


121

(sec) (sec) (KB) Publisher

0 0 17636 0

60 382 93112

120 762 168784 0,000452886143501 1200201

Probabilità di errore 20%


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 10900 0

60 2 11656

120 3 12480 0,000321420082165 1200201


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 12504 0

60 51 29528

120 101 46444 0,000353286143564 300051


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher


122

0 0 14764 0

60 139 50000

120 278 84668 0,000386492082124 600101


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 16756 0

60 229 70368

120 459 124092 0,000419692082103 900151


Tempo virtuale

di simulazione

(sec)

Tempo reale di

simulazione

(sec)

Memoria

occupata

(KB)


rete dal

Publisher

0 0 17052 0

60 456 89556

120 911 162364 0,000452892082082 1200201

VALIDAZIONE DEL MODELLO

Comunicazione reliable

Test 1: pacchetti di dimensioni pari a 50 byte

Subscriber Simulazione RTT

mediano (sec)

ORTE RTT mediano

(sec)

Errore di simulazione

(sec)

1 0,000319791671998 0,000409854833333 0,000097453543948


123

2 0,000321111671999 0,000419789998339 0,00009867832634

3 0,000322431671999 0,000419885215947 0,000097453543948

4 0,000323751671999 0,000424211713954 0,000100460041955



mediano (sec)

ORTE RTT mediano

(sec)


(sec)

1 0,000321374852011 0,000443566833333 0,000133955876653

2 0,000323094849085 0,000452457892999 0,000129363043914

3 0,000324814846159 0,000458770722812 0,000133955876653

4 0,000326519798343 0,000460141427618 0,000133621629275

Comunicazione best-effort



mediano (sec)

ORTE RTT mediano

(sec)


(sec)

1 0,000319791671998 0,000401989897317 0,000097418530093

2 0,000320719671998 0,000413051872721 0,000092332200723

3 0,000321647671998 0,000419066202091 0,000097418530093

4 0,000322575671998 0,000423211829208 0,00010063615721



mediano (sec)

ORTE RTT mediano

(sec)


(sec)

1 0,000321374852011 0,000440364332898 0,000129980436292

2 0,00032270285195 0,000451548938288 0,000128846086338


124

3 0,000324030851889 0,000454011288181 0,000129980436292

4 0,000325358851828 0,000458237961278 0,00013287910945

CONFRONTO CON IL MULTICAST

Comunicazione reliable, probabilità di errore nulla


Subscriber Simulazione unicast

RTT mediano (sec)

Simulazione multicast

RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000321391672005 0,000321342983211 0,000000048688794

25 0,000362671672054 0,000321365114672 0,000041306557382

50 0,000405671672105 0,000321365114672 0,000084306557433

75 0,000448671672157 0,000321365114672 0,000127306557485

100 0,000491671672208 0,000321359629357 0,000127306557485



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000334174852012 0,000334142983212 0,0000000318688

25 0,000452271672000 0,000341290738679 0,000110980933321

50 0,000575271672003 0,000350287738694 0,000224983933309

75 0,000698271672006 0,000359284738709 0,000338986933297

100 0,000821271672010 0,000368281738724 0,000338986933297



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)


125

1 0,000350174851975 0,000350142983175 0,0000000318688

25 0,000564271672053 0,000355291405353 0,0002089802667

50 0,000787271672103 0,000364288405367 0,000422983266736

75 0,001010271672150 0,000373285405382 0,000636986266768

100 0,001233271672200 0,000382282405397 0,000636986266768



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000366654852202 0,000366622983402 0,0000000318688

25 0,000687887672051 0,000369884034686 0,000318003637365

50 0,001022487672100 0,000378881034700 0,0006436066374

75 0,001357087672150 0,000387878034715 0,000969209637435

100 0,001691687672200 0,000396875034730 0,000969209637435




RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000350320470660 0,000350263814644 0,000000056656016

25 0,000392426070609 0,000353786554676 0,000038639515933

50 0,000436286070557 0,000357438554681 0,000078847515876

75 0,000480146070504 0,000360214074684 0,00011993199582

100 0,000524006070451 0,000363892634689 0,00011993199582



126


RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000363829912956 0,000363799814645 0,000000030098311

25 0,000484284792000 0,000381889778677 0,000102395013323

50 0,000609744792004 0,000402258778689 0,000207486013315

75 0,000737393432006 0,000419231778702 0,000318161653304

100 0,000873433432009 0,000413535652639 0,000318161653304



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000380749912917 0,000380719814606 0,000000030098311

25 0,000599124792054 0,000407450445356 0,000191674346698

50 0,000835313432113 0,000438336336593 0,00039697709552

75 0,001082353432170 0,000432961796930 0,00064939163524

100 0,001329393432220 0,000448076702355 0,00064939163524



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000398180953157 0,000398150854846 0,000000030098311

25 0,000725852152053 0,000434840834688 0,000291011317365

50 0,001095036792110 0,000438819445373 0,000656217346737

75 0,001465952792160 0,000443161920919 0,001022790871241

100 0,001836868792220 0,000450222914403 0,001022790871241



127



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000321404950661 0,000321343868456 0,000000061082205

25 0,000353276950641 0,000321365114672 0,000031911835969

50 0,000386476950620 0,000321365114672 0,000065111835948

75 0,000419676950599 0,000321365114672 0,000098311835927

100 0,000491671672208 0,000321365114672 0,000098311835927



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000334174852012 0,000334143868456 0,000000030983556

25 0,000442863671991 0,000334165114664 0,000108698557327

50 0,000556063671984 0,000334165114664 0,00022189855732

75 0,000669263671977 0,000334165114664 0,000335098557313

100 0,000782463671970 0,000334165114664 0,000335098557313



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000350174851975 0,000350143868419 0,000000030983556

25 0,000554863672043 0,000350165114671 0,000204698557372

50 0,000768063672084 0,000350165114671 0,000417898557413

75 0,000981263672124 0,000350165114671 0,000631098557453

100 0,001194463672160 0,000350165114671 0,000631098557453


128



RTT mediano (sec)


RTT mediano(sec)

Differenza

simulazioni (sec)

1 0,000366654852202 0,000366623868647 0,000000030983555

25 0,000678479672041 0,000366645114671 0,00031183455737

50 0,001003279672080 0,000366645114671 0,000636634557409

75 0,001328079672120 0,000366645114671 0,000961434557449

100 0,001652879672160 0,000366645114671 0,000961434557449

Comunicazione reliable


Subscriber Messaggi liv. rete dal

Publisher (unicast)

Messaggi liv. rete dal

Publisher (multicast)

1 270036 270019

2 540055 270019

3 810074 270019

4 1080022 270019



Publisher (unicast)



1 450036

450020

2 540055 450020

3 1350077

450020

4 1800026 450020


129




Publisher (unicast)



1 180036 180019

2 360055 180019

3 540074 180019

4 720093 180019



Publisher (unicast)



1 360037 360020

2 720057 360020

3 1080077 360020

4 1440097 360020

Pacchetti di dimensioni 100 byte, 4 subscriber Test 1: comunicazione reliable senza perdita

Messaggi

trasmessi al

secondo


Publisher (unicast)



25 270089 67518

50 540089 135018

75 810089 202518

100 1080022 270019


130

Test 2: comunicazione reliable, perdita 10%

Messaggi

trasmessi al

secondo


Publisher (unicast)



25 286288 83718

50 572488 167418

75 858688 251118

100 1144892 270021

Test 3: comunicazione best-effort senza perdita

Messaggi

trasmessi al

secondo


Publisher (unicast)



25 180089 45018

50 360089 90018

75 540089 135018

100 720093 180019

Pacchetti di dimensioni 100 byte, 4 subscriber Test 1: comunicazione reliable senza perdita

Dimensioni

coda


Publisher (unicast)



10 36008 9002

20 36008 9002

30 36008 9002


131


Dimensioni

coda


Publisher (unicast)



10 38176 11170

20 38176 11170

30 38168 11162


Dimensioni

coda


Publisher (unicast)



10 40256 13250

20 39376 12370

30 39368 12362

Test 4: comunicazione reliable senza perdita

Dimensioni

coda

RTT mediano unicast

(sec)

RTT mediano

multicast (sec)

10 0,000326551672011 0,000325349114677

20 0,000326551672011 0,000325349114677

30 0,000326551672011 0,000325349114677


Dimensioni

coda

RTT mediano unicast

(sec)

RTT mediano

multicast (sec)

10 0,000355671482851 0,000354525859391

20 0,000355668395880 0,000354522924369


132

30 0,000355570392012 0,000354423994677


Dimensioni

coda

RTT mediano unicast

(sec)

RTT mediano

multicast (sec)

10 0,000381958917403 0,000380995988440

20 0,000371915300245 0,000370840365223

30 0,000371822712012 0,000370746874678

133

Bibliografia e Webgrafia

[1] The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol,

OMG, anno 2007 [2] OMG Data-Distribution Service: Architectural Overview, Gerardo Pardo-Castellote,

anno 2003

[3] RTI Data Distribution Service The Real Time Publish-Subscribe Middleware – User’s

manual v. 4.1, anno 2005

[4] Couloris, Distributed System, anno 2005

[5] OMNeT++ Discrete Event Simulation System vers. 3.2 User Manual, Andràs Varga,

anno 2005

[6] Thomas J. Schriber, Daniel T. Brunner, Inside discrete-event simulation

software: how it works and why it matters, anno 1997

[7] OMG Data Distribution Service: Real Time Publish/Subscribe becomes a standard,

Gerardo Pardo-Castellote, anno 2005

[8] RTPS middleware for Real-Time Distributed Industrial Vision Systems, Based

Almadani, anno 2005

[9] ORTE - open source implementation of RealTime Publish-Subscribe protocol, Petr

Smolik, Zdenek Sebek, Zdenek Hanzalek, anno 2002

[10] http://www.iniziativasoftware.it

134

[11] http://www.swarmnet.de/shawn/

[12] http://tcs.unige.ch/doku.php/code/algosensim/overview

[13] http://twiki.di.uniroma1.it/twiki/viewfile/Reti_Avanzate/WebHome?rev1.1;

filename=opnet21.pdf

[14] http://twiki.di.uniroma1.it/twiki/viewfile/Arc_internet/WebHome?rev=1.1;

filename=opnet.ppt

[15] http://web.cs.ualberta.ca/~pawel/SMURPH/smurph.html

[16] http://www.isi.edu/nsnam/ns/

[17] http://pcl.cs.ucla.edu/projects/glomosim/

[18] http://www.j-sim.org/

[19] http://www.mobius.uiuc.edu/

[20] http://www.ewh.ieee.org/soc/es/Nov1999/18/Begin.htm

[21] http://personal.stevens.edu/~hli5/Tutorial%20of%20OMNET.htm

[22] http://www.tkn.tu-berlin.de

[23] http://www.wikipedia.org

[24] Data Distribution Service for Real-Time Systems Specification, OMG, anno 2003

[25] http://deisnet.deis.unibo.it

[26] A framework for DRE middleware, an application to DDS. Hugues, Pautet,

Kordon. s.l. : IEEE, April 24-26, 2006, pp. 224-231.

Fonti delle illustrazioni Modello Publish-Subscribe, Figura 1: Riferimento [7]

Meccanismo Publish-Subscribe, Figura 3: Riferimento [7]

Costruzione ed esecuzione della simulazione, Figura 8: Riferimento [5]

Architettura di OMNeT++, Figura 9: Riferimento [5]

Documents

Modellazione dello standard OMG RTPS mediante OMNeT++