Elaborato Karamanolis Gabriella N46001643

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Programmazione II
Analisi di soluzioni per la distribuzione dati
affidabile e in tempo reale basate su DDS
Anno Accademico 2015/2016
Candidato:
Gabriella Karamanolis
matr. N46/1643
A colui che più di tutti vorrebbe
essere qui con me oggi e
a colei senza la cui forza non
sarei qui:
a mio padre e mia madre.
Indice
Analisi di soluzioni per la distribuzione dati affidabile e in tempo reale basate su DDS ....................I
Indice .............................................................................................................................................. III
Introduzione ..................................................................................................................................... 4
Capitolo 1: Lo standard DDS ........................................................................................................... 6
1.1 Livelli del DDS .................................................................................................................... 6
1.2 Modalità di funzionamento .................................................................................................. 9
1.3 Global Data Space .............................................................................................................. 10
1.4 Quality of Service .............................................................................................................. 10
Capitolo 2: RE.VE.N.GE. .............................................................................................................. 12
2.1 Architettura ........................................................................................................................ 13
2.2 Policy DDS ........................................................................................................................ 15
2.3 Sistema di code .................................................................................................................. 17
2.4 Test .................................................................................................................................... 17
Capitolo 3: RDDS .......................................................................................................................... 20
3.1 Architettura ........................................................................................................................ 21
3.2 Comunicazione semantics-aware ...................................................................................... 24
3.3 Garanzie Quality of Service e Quality of Data .................................................................. 25
3.4 Test ..................................................................................................................................... 27
Conclusioni .................................................................................................................................... 30
Bibliografia .................................................................................................................................... 32
Introduzione
“Il mio programma gira su un sistema distribuito quando
non funziona per colpa di una macchina di cui non ho mai sentito parlare” - L. Lamport.
Siamo sempre più circondati da macchine e software eterogenei nella vita di tutti i giorni
ma non ce ne rendiamo conto. Sistemi eterogenei che possono interagire fra di loro solo
tramite scambio di opportuni messaggi sono detti sistemi distribuiti.
Nei sistemi distribuiti vari fattori aumentano la complessità dello sviluppo di un buon
software :
• le applicazioni sono distribuite su una rete di calcolatori, con hardware e sistemi
operativi diversi ;
• occorre adoperare linguaggi di programmazione diversi ;
• i dati sono distribuiti su più nodi di elaborazione memorizzati in archivi o DBMS
diversi.
In informatica, è raro che i sistemi più complessi vengano costruiti ex novo, ma sono
invece evoluzioni e integrazioni di sistemi datati ma robusti con in aggiunta qualche
modifica. L‟integrazione di sistemi informativi sviluppati in momenti diversi, con
linguaggi e tecniche diverse, è un problema centrale delle tecnologie software. Prima di
proseguire è giusto dare una defizione di middleware. Esso è uno strato software che si
interpone fra sistema operativo e applicazioni, in grado di fornire servizi utili per lo
sviluppo di applicazioni distribuite: questo fornisce ai programmatori le API (Application
Programming Intarface), librerie di funzioni in grado di mascherare l‟eterogeneità dei
4
sistemi permettendo al programmatore di ignorare i dettagli degli stessi.
Molte tecnologie middleware sono nate con il preciso obiettivo di fornire una risposta al
problema dell‟integrazione di applicazioni differenti (EAI). Alcune applicazioni real-time
e fault-tolerant hanno la necessità di modellare la loro comunicazione come puro scambio
incentrato
sul
dato,
data-centric,
dove
dei
processi
pubblicano il dato che è poi disponibile ad altri processi remoti interessati ad esso. In
questo elaborato verrà presentata la specifica emergente per la distribuzione dei dati, Data
Distribution Service, che tenta di risolvere il problema e verranno analizzate due diverse
modalità d‟uso dello stesso. La prima è un lavoro svolto da ingegneri italiani,
“RE.VE.N.GE.: implementazione tramite RTI-DDS e replicazione del sistema di
consegna”3, che tratta di un progetto chiamato „Reliable and versatile news delivery
support for agencies‟ il cui scopo è quello di realizzare un sistema per la distribuzione di
notizie
su
larga
scala
usando
RTI-DDS.
La seconda è un lavoro svolto da americani, “RDDS: A Real-Time Data Distribuition
Service for Cyber-Physical System”4 che tratta dell‟implementazione dello standard DDS
per la creazione di una nuova applicazione, RDDS, usata nei sistemi ciber-fisici, sistemi
che lavorano a stretto contatto con il mondo fisico.
5
Capitolo 1: Lo standard DDS
Il Data Distribution Service (DDS) è uno standard emanato dall'Object Management
Group (OMG) che definisce un middleware per la distribuzione di dati in tempo reale
secondo il paradigma publish/subscribe. DDS è un MOM (message-oriented middleware)
data-centric che prevede un‟architettura ad alte prestazioni, caratterizzata da scalabilità e
affidabilità.
L‟obiettivo della specifica del DDS può essere riassunto nella frase “Efficient and Robust
Delivery of the Right Information to the Right Place at the Right Time.”1
I middleware data-centric hanno un differente approccio dai tipici MOM messagecentric: i data-centric si focalizzano sulla distribuzione dei dati da più sorgenti a più
destinazioni in tempo reale e delle informazioni sullo stato del sistema. Più nel dettaglio,
il middleware sa se un dato è condiviso tra più applicazioni di sistemi distribuiti e i
messaggi sono costruiti dal middleware in maniera tale che possano comunicare eventuali
cambiamenti dello stato del sistema.
1.1 Livelli del DDS
La specifica DDS si compone di due livelli e le applicazioni hanno libero accesso ad
entrambi i livelli :
Data Centric Publish-Subscribe (DCPS) definisce le funzionalità usate da una
applicazione per pubblicare o sottoscriversi ai valori di un dato oggetto.
6
Le principali classi del DCPS che realizzano la comunicazione sono:
• La classe DomainPartecipant, il cui oggetto rappresenta la partecipazione
dell‟applicazione a un piano di comunicazione, il dominio, che isola le une dalle altre le
applicazioni in esecuzione sullo stesso insieme di elaboratori fisici. Un dominio stabilisce
una “rete virtuale”, collegando tutte le applicazioni che condividono lo stesso domainID e
isolandole dalle applicazioni in esecuzione su domini differenti. In questa maniera,
diverse applicazioni distribuite indipendenti possono coesistere in una stessa rete fisica
senza che interferiscano fra loro o che siano a conoscenza le une delle altre. Gli oggetti
DomainPartecipant sono creati e distrutti dal singleton DomainPartecipantFactory.
• La classe Publisher, il cui oggetto è responsabile della reale diffusione delle
pubblicazioni. Ad un Publisher possono appartenere più oggetti DataWriter, in questo
modo un oggetto di tipo Publisher può inviare dati su più Topic distinti. Quando è
informato di un cambiamento di un dato associato ad uno dei suoi oggetti DataWriter, il
Publisher decide quando è realmente appropriato mandare un messaggio di data-update in
accordo alla propria QoS o a quella del corrispondente DataWriter.
• La classe DataWriter, il cui oggetto rappresenta l‟intenzione del Publisher di pubblicare
un dato. Esso consente all‟applicazione di settare il valore del dato che dev‟essere
pubblicato sotto il Topic scelto. Un DataWriter è legato a un solo Publisher che gli fa da
costruttore, a un solo Topic e di conseguenza a un solo tipo di dato. Il Topic deve esser
creato prima del DataWriter. DataWriter è una classe astratta che dev‟essere specializzata
per
ogni
particolare
tipo
di
dato
dell‟applicazione.
• La classe Subscriber, il cui oggetto è responsabile della reale ricezione dei dati derivanti
dalla sottoscrizione. Ad un Subscriber possono appartenere più oggetti DataReader; in
questo modo un oggetto di tipo Subscriber può leggere dati su più Topic distinti. Quando
riceve un dato (da un‟altra parte del sistema), costruisce una lista dei DataReader
interessati, e poi indica all‟applicazione quale dato è disponibile, attraverso i suoi listener
o abilitando le relative condizioni.
• La classe DataReader, il cui oggetto consente all‟applicazione di dichiarare il dato che
7
desidera ricevere e di accedere al dato interessato tramite il Subscriber. Un DataReader si
riferisce al Topic che identifica il dato che dev‟essere letto. La sottoscrizione può dare un
solo tipo di risultato. Il DataReader potrebbe avere accesso a molte istanze del risultato
distinte dalla loro chiave. DataReader è una classe astratta che dev‟essere specializzata
per ogni particolare tipo di dato dell‟applicazione.
• La classe Topic è la descrizione base del dato che dev‟essere pubblicato e sottoscritto.
Un Topic è identificato dal suo nome che dev‟essere unico in tutto il dominio.
Tutte queste classi estendono la classe Entità del DCPS che a sua volta rappresenta la
possibilità di queste di essere configurate attraverso le politiche di QoS e di poter ricevere
notifiche di eventi attraverso i Listener.
DCPS è la API più bassa tra gli strati di DDS ed è utilizzata dalle applicazioni per le
comunicazioni con altri processi basati su DDS.
Data Local Reconstruction Layer (DLRL) è invece opzionale e situato sullo strato più alto
perché specifica come un‟applicazione può interfacciarsi attraverso una visione objectoriented ai servizi sottostanti.
La specifica OMG definisce anche un livello aggiuntivo sottostante il DDS: il Real-Time
Publish Subscribe (RTPS)2. Esso è un wire control (protocollo di collegamento) che
indica “come” deve avvenire l‟interazione fra publisher e subscriber. La specifica RTPS
quindi usa molte delle entità centrali usate dalla specifica DDS.
RTPS è progettato per funzionare su IP multicast e con protocolli di trasporto
connectionless e best-effort come UDP/IP. Il protocollo presenta le seguenti principali
caratteristiche:
• Specifiche QoS atte a realizzare comunicazioni publish-subscribe best-effort e affidabili
per applicazioni Real-Time, utilizzando reti IP standard;
• La tolleranza ai guasti per consentire la connessioni di reti senza single point of failure;
• Estensibilità per consentire al protocollo di essere esteso e migliorato senza toccare
compatibilità e interoperabilità con vecchie versioni dello standard;
• Connettività plug-and-play così che le nuove applicazioni vengano rilevate
8
automaticamente e le applicazioni possano aderire e abbandonare la rete in qualsiasi
momento senza necessità di riconfigurazione;
• Modularità, per consentire ai dispositivi di utilizzare soltanto un sottoinsieme delle
caratteristiche offerte dal protocollo;
• Scalabilità;
• Type-safety per prevenire errori di programmazione che possano compromettere il
funzionamento di nodi remoti.
1.2 Modalità di funzionamento
Consideriamo due nodi, A e B, separati e distinti. Sul nodo A agisce un‟applicazione, il
producer, che produce messaggi mentre sul nodo B vi è un‟applicazione, il receiver, che
riceve messaggi. Attraverso il DDS e più specificamente tramite il suo livello DCPS il
producer invia i suoi messaggi al DataWriter. I messaggi verranno poi inviati al Publisher,
l‟elemento attivo che dissemina il messaggio attraverso la rete. Il legame fra DataWriter e
Publisher è Topic-Based e tale legame rappresenta l‟intenzione dell‟applicazione di
pubblicare un messaggio di uno specifico dato. Il Pulisher attraverso il Domain, canale
virtuale che collega Publisher e Subscriber, invia il messaggio verso il Subscriber nel
nodo di ricezione B.
La comunicazione fra Publisher e Subscriber è regolata dalle politiche di QoS secondo un
pattern offerta/richiesta : la comunicazione è instaurata se le QoS del Subscriber
concordano con quelle offerte dal Publisher. Il Subscriber manda il messaggio al
DataReader, il cui legame è sempre Topic-based. Infine il messaggio giunge a
destinazione.
9
1.3 Global Data Space
Il DDS fornisce un‟archiviazione dati locale ad ogni applicazione detta Global Data
Space. Ad ogni partecipante del dominio, il GDS appare come una memoria locale alla
quale si accede tramite apposite API, mentre DDS gestisce l‟invio degli opportuni
messaggi finalizzati all‟aggiornamento della memoria sui rispettivi nodi remoti. I dataobject sono accessibili dalla tupla (Topic, Key). Le sottoscrizioni sono disaccoppiate
dalle pubblicazioni. Le relazioni sono stabilite tramite QoS.
Il DDS fornisce anche il Local Object Cache costruito dal GDS; le modifiche sul Local
Object Cache vengono riportarte sul GDS.
DDS opera una comunicazione peer-to-peer, per cui non è necessaria la presenza di
un‟entità broker. Questo permette di garantire un certo grado di affidabilità grazie
all‟assenza di single point of failure.
1.4 Quality of Service
Con QoS (Quality of Service) si intende un insieme di caratteristiche che controlla alcuni
aspetti del comportamento del Servizio DDS. Esse controllano come i dati devono essere
condivisi tra le applicazioni permettendo di garantire requisiti di affidabilità, sicurezza e
salute del sistema:
• In un sistema non tutte le applicazioni necessitano di tutti i dati presenti nel Global Data
Space: DDS invia solo ciò di cui ogni processo ha effettivamente bisogno;
• Se i messaggi non raggiungono le destinazioni, il middleware implementa l‟affidabilità
della consegna quando necessario;
• Se la quantità di dati è notevole, il DDS li filtra e invia soltanto i dati di cui ogni
applicazione ha bisogno;
• Quando il sistema cambia, DDS riconosce dinamicamente a chi inviare quale dato, e
informa i partecipanti dei cambiamenti;
10
• Quando sono necessari aggiornamenti veloci, DDS invia messaggi multicast per
eseguire l‟aggiornamento di molte applicazioni remote contemporaneamente;
• Con l‟evolversi dei tipi di dato, DDS tiene traccia delle versioni utilizzate dalle varie
parti del sistema ed esegue automaticamente le dovute traduzioni;
• Per applicazioni security-critical, DDS controlla gli accessi, impone percorsi ai flussi di
dati e cripta i dati on-the-fly.
11
Capitolo 2: RE.VE.N.GE.
RE.VE.N.GE. è l‟acronimo di „Reliable and versatile news delivery support for agencies‟,
un progetto nato da ingegneri italiani il cui scopo è quello di realizzare un sistema per la
distribuzione
di
notizie
su
larga
scala.
Obiettivi principali per la realizzazione del middleware sono :
• il disaccoppiamento delle due realtà interessate, fonti e fruitori (sources e sinks) ;
• un supporto alle QoS sia per le fonti che per i fruitori che devono essere capaci di
configurarle;
• replicazione del servizio di consegna per incrementare l‟affidabilità del sistema.
Utile strumento per rispondere a questi obiettivi è proprio lo standard DDS per sistemi
real-time, RTI-DDS. Esso è un middleware sviluppato da Real-Time Innovations che
implementa le API DCPS fornite dalla specifica DDS per applicazioni distribuite realtime. Il middleware RTI-DDS non è a conoscenza del sistema operativo e del linguaggio
di programmazione, permettendo a sistemi eterogenei la comunicazione. Esso ha riscosso
successo in molti campi mission-critical e data-critical come: monitoraggio del traffico
aereo, ferroviario e nella gestione di transazioni finanziarie.
RTI-DDS offre servizi utili all‟applicazione che si vuole creare, che sono: heartbeat,
ovvero il controllo della vita di sink e source, responsabilità dunque del middleware;
affidabilità della comunicazione, garantita per mezzo di protocolli di ack e code di
ritrasmissione configurabili; partizioni dei topic che permettono di mettere in
comunicazione solo alcuni DataReader/DataWriter all‟interno dello stesso topic.
12
Sono stati appurati i „limiti‟ della struttura DDS per il progetto e dove è necessario
operare per l‟aggiunta di uno strato ulteriore, con i suoi pro e contro e nello specifico sono
state analizzate le problematiche relative alla fault tolerance del sistema.
2.1 Architettura
Sono tre le entità che partecipano alla comunicazione: la fonte, source, che è il produttore
delle notizie, caratterizzato da una quantità minima e massima di notizie consegnabili
nell‟unità di tempo e livelli di affidabilità e priorità; il fruitore, sink, che riceve le notizie,
caratterizzato da affidabilità delle consegne, i tempi minimi e massimi di consegna della
notizia, il numero minimo e massimo di notizie da ricevere nell‟unità di tempo e gli
argomenti di interesse, sui quali è anche possibile richiedere un‟esclusiva riguardo alcuni
tipi di notizie; il sistema di consegna, system, fulcro del progetto che fa da ponte fra
sources e sinks inglobando tutte le principali funzionalità dell‟applicazione, ovvero il
controllo della qualità di servizio e della distribuzione delle news, garantendo alta
affidabilità del servizio, essendo replicato; il system permette la registrazione dei sources
e dei sinks, con associata la QoS da loro richiesta, e assicura la ricezione e l‟inoltro delle
notizie secondo la QoS. Al fine di garantire flessibilità nel settaggio della QoS, essa è resa
completamente personalizzabile per ogni sink/source: in particolare si hanno N+M canali,
monodirezionali o bidirezionali a seconda della garanzia di trasmissione di cui si necessita
(rispettivamente best-effort o reliable), con N numero di source registrati e M numero di
sink registrati. La QoS è imposta tramite delle code interne: in esse le notizie vengono
ordinate secondo la priorità delle sources ed eliminate se la loro deadline di consegna non
viene rispettata.
Per rendere il sistema robusto ad eventuali guasti è implementata una replicazione
spaziale del sistema: infatti, in un sistema distribuito, la presenza di un insieme di
processori partecipanti permette la replicazione delle risorse che servono all‟applicazione
su più nodi diversi, facendo sì che se cade un nodo ve ne sia un altro pronto ad essere
utilizzato.
13
Il modello di replicazione scelto è quello a copie attive indipendenti, non basato su una
comunicazione di tipo master-slave che avrebbe snaturato il modello DDS, bensì
orientato a una comunicazione alla pari. All‟atto della pubblicazione di una notizia ad
opera di un source, tutti i sistemi ne ricevono una copia attraverso una trasmissione
multicast realizzata dal DDS, il quale, realizzando un‟astrazione di un sistema unico,
assicura ad ogni singolo sistema di potersi occupare del proprio insieme di sink lavorando
indipendentemente dagli altri sistemi-copia, distribuendo così il carico di elaborazione. A
seguito di un invio di una notizia ad un suo sink, un sistema informa i suoi pari tramite
messaggi di sincronizzazione, caratterizzati da quadruple che hanno al loro interno i
GUID (identificatore unico globale) della notizia inviata, del sistema-copia che ha
recapitato la notizia, del source origine e del sink destinazione. Le tempistiche dipendono
dalla bufferizzazione operata dal DDS nell‟invio dei messaggi dai DataWriter ai
DataReader.
La comunicazione è ovviamente basata su Topic, divisi in due gruppi: quelli inerenti il
rapporto fra system e sink/source e quelli interessati alla comunicazione tra i sistemicopia. I Topic tra system e source/sink sono: sourceNewsTopic e sinkNewsTopic, topic
partizionati che si occupano rispettivamente dell‟invio della notizia da source a system e
dell‟invio della notizia da system a sink; sourceManagerTopic e sinkManagerTopic, che
si occupano delle richieste di Join/Leave rispettivamente di source e sink. I Topic dedicati
all‟interazione tra i sistemi-copia sono: systemMsg, topic adibito alla presentazione del
nuovo sistema di consegna che vuole unirsi, così da attivare il protocollo di join usato per
garantire una corretta sincronizzazione delle copie; sourceSync e sinkSync attraverso i
quali i sistemi-copia si scambiano informazioni in modo tale da garantire consistenza
globale (tutti i sistemi-copia dovranno conoscere le stesse entità); queueUpdate, in cui un
sistema-copia avvisa gli altri sistemi che una determinata notizia destinata a un proprio
sink è stata correttamente inviata, permettendo loro di rimuoverla dalle proprie code
interne, necessarie in caso di cadute impreviste (se va offline un sistema, le notizie ai sink
di quest‟ultimo vengono recapitate dagli altri); whois, sink/source/peer recovery sono
14
invece topic usati in casi di malfunzionamento, come ad esempio un messaggio mancante.
2.2 Policy DDS
Una buona quality of service è obbiettivo centrale del progetto e attraverso delle policy
del DDS vengono risolti alcuni problemi essenziali. Per la heartbeat, cioè il controllo
della liveliness delle entità, è usata la policy discovery_config per configurare il processo
di discovery. Questa politica offre delle callback implementabili all‟avvenire di un evento
come quando un dataWriter perde/acquista un dataReader associato o viceversa.
Personalizzando la frequenza di invio dei pacchetti di discovery si stabilisce un criterio
per decidere se un‟entità (sink o source) è attiva o meno (pacchetti liveliness).
Il sistema-copia nel lato source ha N dataReader su un topic partizionato N volte, quindi
alla caduta di un nodo source si saprà presso quale dataReader è scattato l‟evento e così il
sistema-copia saprà quale fonte è caduta, provvedendo a rimuovere le entità, procedura
necessaria con RTI-DDS per non appesantire l‟applicazione. Nel lato sink, invece, il
fruitore, avente un unico dataReader, riceve notizie da un sistema-copia che possiede un
solo dataWriter che lavora su un topic partizionato; risulta pertanto semplice riconoscere
la caduta di un sink e informare gli altri sistemi. Il protocollo di discovery del DDS non
copre la caduta di un sistema-copia, essendo DDS un publish/subscribe e non potendo
dunque riconoscere quale specifico dataReder/dataWriter si sia disassociato dal topic.
Così si è previsto un heartbeat firmato con cui un sistema-copia, ogni quanto di tempo
deciso con criterio, manda un messaggio imfine con il GUID associato.
I sistemi-copia garantiscono un sistema robusto che difficilmente perde notizie: infatti,
alla caduta di un sistema-copia, un sink registratovi viene spostato su un altro, lasciando
lo stesso dataReader in attesa sul topic; nel sistema-copia subentrato, invece, viene
aggiunto un nuovo dataWriter per comunicare col nuovo fruitore, in maniera del tutto
trasparente agli occhi del sink grazie al DDS.
Per l‟affidabilità delle comunicazioni è adottata la policy reliability del DDS, che
permette
15
di decidere se il dato pubblicato da un DataWriter su un preciso Topic va trasmesso a un
DataReader in maniera affidabile. Settando reliability a best_effort, il dato verrà inviato al
DataReader senza attendere conferme di buon esito della ricezione; altrimenti, settando a
reliable, a seguito dell‟invio del dato viene ricevuto un ack di conferma, senza il quale il
dato è inviato ancora. Modificando il parametro history si può scegliere la quantità di dati
da bufferizzare per la pubblicazione mentre si aspetta l‟ack riguardante la ricezione del
dato precedente. La reliability effettiva verrebbe raggiunta permettendo al DDS di
allocare code send e receive illimitate: rispettivamente, le prime mantengono i messaggi
per i quali non vi sono stati gli ack relativi ai dataReader associati al Topic e le seconde
mantengono i messaggi successivi ad un eventuale messaggio mancante mentre viene
inviato un ack negativo per la ritrasmissione del messaggio mancante. Allocando code
send/receive illimitate si eviterebbe il caso di code piene e la conseguente mancanza di
messaggio, ma questa strategia è sconsigliata poiché il DDS sforerebbe i limiti di
memoria accettabili. Il progetto adotta quindi una politica reliable con history a keep all,
mantenendo soltanto i messaggi relativi alle fasi di Join/Leave di sink/source, allo scopo
di evitare, in caso di pubblicazioni di notizie ad un rate troppo elevato, un
sovraffaticamento del sistema. Questo è possibile grazie al protocollo RTPS usato dal
DDS che abbassa notevolmente le probabilità di un‟eventuale perdita di messaggio. Nel
caso peggiore di perdita di un messaggio di leave/join di un sink/source, il sistema
recupera la piena consistenza grazie al protocollo whois: quando riceve un messaggio di
aggiornamento (consistente in una quadrupla: GUID della notizia inviata, del sistemacopia che ha inviato la notizia, del source origine e del sink destinazione), ogni singolo
sistema-copia o riconosce le entità in gioco o, in caso contrario, utilizza il topic whois per
chiedere agli altri sistemi-copia le informazioni di tali entità ignote.
La policy partitioning assicura un canale personalizzato qualora richiesto, nonostante tutti
i sink e source utilizzino lo stesso Topic (news).
Esiste la policy deadline del DDS, ma questa dà solo la possibilità di scatenare un evento
in caso non si presentino notizie entro un certo lasso di tempo e non è d‟aiuto per il
16
controllo della frequenza minima/massima di trasmissione delle news dove è invece
sfruttato un meccanismo a code esterno al DDS.
2.3 Sistema di code
Come detto nel capitolo precedente, il sistema di code agisce dove le policy DDS non
sono sufficienti. Source e sink hanno delle entità predisposte, rispettivamente:
NewsCatcher legge le notizie e NewsDispatcher effettua la consegna al sink interessato ad
esse. Quando una source/sink si registra vi sono parametri da specificare che vanno
mantenuti dal sistema in una struttura dati, quali: priorità, numero massimo e minimo di
news per unità di tempo, l‟unità di tempo da considerare e l‟affidabilità. L‟affidabilità è
usata per considerare i DataReader e DataWriter opportuni mentre i restanti parametri
sono usati dal sistema di code. All‟arrivo di una notizia questa viene inserita in coda. La
coda è in grado di controllare la QoS del source; infatti, ha un timer per controllare il
numero minimo di news per unità di tempo, che se non rispettato attiva un listener per
segnalare il problema, mentre, per il numero massimo di news, la coda si blocca appena si
raggiunge il numero massimo durante l‟unità di tempo e si sblocca quando il timer
conclude il conteggio; l‟entità NewsPusher usa take sulla coda controllando che la
deadline della notizia non sia stata superata: se è scaduta, la notizia viene eliminata e si
continua ad estrarre dalla coda fino a che non viene trovata una notizia con deadline
valida, la quale viene prelevata e inserita da NewsPusher nelle altre code possedute dai
NewsDispatcher, che provvedono a recapitarla ai sink.
2.4 Test
I test sono stati eseguiti su una macchina monitorata facente da sistema-copia e altre due
macchine usate per sink, source e altri sistemi-copia. In fig. 1 è possibile consultare i
risultati in termini di banda impiegata dal sistema-copia monitorato in diverse situazioni
d‟utilizzo:
17
1. Due sistemi-copia a riposo attivi solo per analizzare l‟overhead causato dai meccanismi di
discovery del DDS e i messaggi imfine.
2. Un source attivo con rate 10 news/sec che fa aumentare la banda di 3 KB/sec a causa
delle pubblicazioni.
3. Un sink attivo, gestito dal sistema-copia 2, aumento della banda di 3 KB/sec a causa degli
update da sistema-copia 2.
4. Un sink attivo gestito da sistema-copia 1, ulteriori 3 KB/sec per l‟invio delle notizie più
altri 3 per l‟invio degli update.
5. Un ulteriore sink attivo gestito da sistema-copia 1.
6. Attivazione di sistema-copia 3, altri 10 kb/sec per gli update e gli overhead del DDS e dei
messaggi imfine.
7. Un sink attivo gestito dal sistema-copia 3, aumento della banda di 3 KB/sec.
Dal test emerge il peso che
comporta un nuovo sistemacopia, che non introduce
overhead nella trasmissione
della
notizia,
sempre
realizzata da uno solo dei
sistemi, ma „consuma‟ una
porzione crescente di banda
per via dei messaggi di
Figura 1: risultati test sulla banda impiegata
update e sincronizzazione.
Simile andamento è seguito dal costo di gestione di un sink (supponendo una frequenza di
trasmissione di 10 news/sec) al crescere del numero di copie (in altre parole, inserire un
sink in N copie equivale a inserire N sink in un unico sistema).
18
È stato svolto anche un test per capire il carico limite del processore (avente frequenza
600MHz). Il test è stato eseguito con un sistema-copia e 10 sink e ha fatto registrare dei
malfunzionamenti
raggiungimento
al
della
soglia di 600 news/sec,
ma
i
risultati
sono
soddisfacenti considerato
che il rate-soglia è molto
alto.
Figura 2: risultati test sul carico della CPU
19
Capitolo 3: RDDS
Requisito principale in molti sistemi ciber-fisici (Cyber-Physical Systems, CPS, ovvero
sistemi informatici interagenti in modo continuo con un sistema fisico) è che i dati dei
sensori, usati per interagire strettamente col mondo fisico, dovrebbero essere diffusi in
maniera tempestiva e affidabile a tutte le entità che interagiscono nel sistema. In questi
sistemi, infatti, un gran numero di entità coopera per il raggiungimento di scopi comuni. I
sensori acquisiscono i dati dal mondo esterno per poi trasmetterli alle risorse
computazionali, che a turno, in cooperazione, prendono le decisioni in tempo reale con la
condivisione dei dati e delle informazioni. Le difficoltà in questi sistemi si riscontrano
nella natura altamente dinamica dei sistemi, sia per quanto riguarda le risorse di calcolo
che per i processi fisici; inoltre, la disponibilità delle entità partecipanti può cambiare nel
corso delle operazioni per cause diverse, e negli strati-rete usati da questi sistemi vi sono
di solito instabilità, dato che molte delle applicazioni non possono permettersi di avere
reti fisse e affidabili. Nell‟articolo “RDDS: A Real-Time Data Distribuition Service for
Cyber-Physical System”, viene presentata una nuova archittettura middleware
publishe/subscribe, chiamata RDDS che mira a fornire un servizio dati affidabile e
tempestivo in ambienti dove i carichi di lavoro schizzano improvvisamente e la
comunicazione è instabile. Il lavoro si focalizza su due aspetti del RDDS per ottenere un
servizio di distribuzione affidabile e tempestivo. Uno dei meccanismi fondamentali del
RDDS è la comunicazione semantics-aware che usa modelli di sensori predittivi leggeri.
20
Dato che la maggioranza dei processi fisici reali lavora in tempo-continuo, ad esempio i
cambi di temperatura, RDDS modella i flussi di dati usando modelli computazionalmente
leggeri. Quest‟abilità può apportare benefici significativi per i sistemi dove il feedback
real-time è necessario ma la rete è lenta o instabile. Inoltre, viene esteso il meccanismo
comunicativo semantics-aware al problema della QoS in TPS (Topic-Publish-Subscribe),
integrando meccanismi di controllo della qualità dei dati dei sensori. Dei meccanismi
feedback ai publisher e feedforward ai subscribers sono integrati per accrescere la qualità
della distribuzione dei dati in real-time. Con questi anelli di controllo integrati, si può
provvedere alla robustezza contro i carichi di lavoro imprevedibili sia in favore del
publisher che dei suoi sottoscrittori. Per mostrare la validità dell‟approccio proposto, gli
ideatori hanno implementato RDDS come estensione dello standard DDS di OMG per
includere i meccanismi che sostengono ambienti instabili e valutato RDDS mettendo in
piedi un banco di test con carichi di lavoro realistici.
3.1 Architettura
RDDS concepisce un CPS su larga scala, in cui molti publisher collezionano dati realtime da sensori sia fisici che logici e li pubblicano per molti sottoscrittori. Ciascun
publisher colleziona dati da un set di sensori e pubblica i corrispondenti flussi di dati al
sottoinsieme di subscribers interessato. Sottoscrittori interessati al consumo di dati da un
gruppo di sensori si uniscono al gruppo dei sottoscritti con la sottoscrizione al topic
corrispondente. Il dato in RDDS è identificato dal Topic, che permette al publisher e al
sottoscrittore di riferirvisi senza ambiguità. Ciascun tipo di topic appartiene o alla
categoria DATA_CONTINUOUS o alla categoria DATA_DISCRETE. Un topic che
appartiene alla prima categoria riceve flussi di dati da sensori che monitorano
continuamente fenomeni fisici in evoluzione. Al contrario la seconda rappresenta flussi di
dati provenienti da sensori che registrano valori discreti. Il lavoro si focalizza su sensori
che hanno proprietà continue.
21
Mentre la trasmissione dei dati dai publishers ai sottoscrittori si verifica direttamente tra
le due parti, la scoperta delle entità (publisher, subscriber e topics) e la negoziazione
QoS/QoD si verifica in maniera centralizzata usando un broker. RDDS usa un
meccanismo di scoperta centralizzato per ragioni di performance e semplicità, visto che
un meccanismo di scoperta distribuito può essere più robusto ma causa maggiore
overhead di comunicazione. Per evitare di essere un single point of failure, un broker di
RDDS può essere replicato. L‟esistenza di flussi di dati dei sensori è comunicata dai
publishers ai sottoscrittori via broker o un gruppo di broker. In RDDS, QoD (Quality of
Data) è definita in termini di limite di precisione dei data sensor, il cui limite massimo
può essere specificato dagli utilizzatori. Esiste un compromesso fra QoD e la freshness
dei dati, per aumentare la quale va ridotto il limite di precisione richiesto, al costo di un
incremento di carico di lavoro. D‟altronde, ciò è necessario per prevenire sovraccarichi e
conseguenti ritardi sulla consegna dei messaggi a ciascun nodo, in ragione del
soddisfacimento della QoD richiesta. A questo fine, la primaria metrica QoS nell‟articolo
in esame è il limite di utilizzazione della CPU in ciascun nodo. Entrambe le parti,
publisher e sottoscrittori, possono definire il livello di QoS e QoD, che essi forniscono o
che richiedono negoziando un livello di QoS e QoD che soddisfi entrambe le parti e al
quale accettano di aderire. La negoziazione QoS/QoD, gestita dal broker, segue un
modello di richiesta/offerta nel quale la richiesta QoD/QoS dev‟essere la stessa o minore
di quella che è stata offerta. Un broker mantiene inoltre meta-informazioni come la
liveliness delle entità partecipanti, con controlli periodici del segnale di heartbeat dalle
entità. La registrazione delle entità di RDDS coinvolge un broker ma la consegna effettiva
del data sensor si verifica tra il publisher e i suoi sottoscrittori. Entrando nel vivo
dell‟architettura, RDDS ha una struttura asimmetrica per publishers e subscribers. Per i
publishers, RDDS consiste in: un negoziatore di QoS/QoD, un controllore di precisione,
modelli per i sensori, un monitor del carico e protocolli di trasporto settabili. Ogni flusso
di dati dai sensori continui ha un corrispondente modello sia lato publisher sia lato
subscriber; questi modelli sono utilizzati dai publisher per determinare se i dati in arrivo
22
dai sensori vadano trasmessi ai subscriber o meno. I nuovi aggiornamenti vengono inviati
ai subscriber solo se i valori osservati dai sensori si scostano dal valore predetto dal
modello di un δ che sia superiore allo specifico limite di tolleranza, settato dinamicamente
per adattarsi al carico di CPU desiderato. Il monitor di carico riporta periodicamente
l‟attuale carico della CPU al controllore di precisione, il quale calcola la differenza fra il
carico di CPU desiderato e quello misurato. Sulla base di questo errore, il controllore
determina se e come il limite di tolleranza andrà aggiornato al successivo periodo di
campionamento. Per i subscribers, RDDS consiste in: un negoziatore di QoS/QoD, un
buffer, modelli dei sensori, un previsore di occupazione del buffer e un controllore di
carico. In primo luogo, le rilevazioni dei sensori provenienti dai publishers vengono
bufferizzate. Per i sensori continui, ogni flusso di dati ha un modello corrispondente, lo
stesso che hanno i publisher. I modelli sono aggiornati solo se arriva una nuova
osservazione da un publisher: è in questa situazione che avviene l‟effettiva
sincronizzazione tra publisher e subscribers. Quando non ci sono aggiornamenti in arrivo
da un publisher, i modelli dei subscribers predicono periodicamente lo stato corrente dei
sensori corrispondenti e popolano il buffer con i dati predetti. Con questo meccanismo, i
subscribers mantegono aggiornati i valori dei sensori anche in assenza di comunicazione
con i publishers, utile soprattutto in sistemi la cui rete è lenta o instabile. Per settare la
giusta frequenza di ricezione di dati dai publishers, il previsore di occupazione del buffer
stima il riempimento di buffer previsto. Il controllore di carico invia periodicamente un
segnale di controllo del carico al broker. Il broker mette insieme i segnali di controllo
provenienti dai subscribers, ricavandone il minimo, ovvero il segnale generato dal
subscriber più in sovraccarico. Il publisher usa questo valore minimo per regolare il
proprio target di carico di CPU. Essenzialmente, il ciclo di controllo a retroazione dei
publisher e il ciclo di controllo con azione in avanti dei subscriber formano un doppio
ciclo utile a migliorare la qualità della distribuzione dei dati.
23
3.2 Comunicazione semantics-aware
A differenza degli approcci basati su cache, RDDS sfrutta il fatto che la maggior parte dei
processi fisici lavora in continuo nel mondo reale. Avvantaggiandosi della semantica dei
dati dei sensori, non soltanto si riducono i carichi di computazione/comunicazione, ma in
più si fornisce una disseminazione dei dati affidabile e puntuale. Quando un publisher
riceve l‟osservazione v dal sensore si, la va a confrontare col valore predetto dal modello
relativo a si. Se la differenza tra il valore previsto dal modello e l‟osservazione del sensore
rientra nel limite di precisione, la nuova osservazione viene cestinata (o salvata
localmente per ragioni di logging). Questo implica che i modelli attuali (condivisi da
publisher e subscriber) sono sufficientemente precisi nel predire l‟osservazione del
sensore entro i limiti di precisione richiesti. In caso contrario, se la differenza è maggiore
del limite di tolleranza, il modello non è più in grado di catturare il corretto
comportamento in uscita dal sensore. In questo caso, il modello del publisher è
immediatamente aggiornato, e v viene trasmessa in multicast per raggiungere tutti i
subscribers. A seguito della ricezione di v, il subscriber aggiorna il proprio modello in
accordo con v. Un beneficio di quest‟approccio è che un‟applicazione può ottenere
dinamicamente il valore corrente di un sensore dal suo modello, usando le predizioni
anziché comunicando realmente col publisher. Questo rende RDDS altamente resistente a
potenziali perdite di pacchetti di dati in reti con comunicazione instabile. Inoltre, dato che
le letture dei sensori possono essere stimate prontamente senza ritardi di comunicazione,
può essere raggiunta la timeliness negli accessi ai dati. Le stime dei modelli di publisher e
subscriber possono essere differenti quando la rete è instabile. Per applicazioni nelle quali
quest‟errore è critico, RDDS permette agli utenti di scegliere il protocollo di trasporto
richiesto, TCP o UDP, benché TCP non si adatti alle esigenze delle applicazioni real-time.
Basarsi su modelli complessi è computazionalmente proibitivo. Perciò, ogni sensore in
RDDS è modellato con un semplice spazio di stato. In RDDS, un processo fisico, come la
temperatura misurata da un sensore al tempo k, è rappresentato in un vettore di stato
24
avente due variabili, [x 𝑑𝑥 𝑑𝑡]t, dove x è il valore corrente del sensore all‟istante k e
𝑑𝑥 𝑑𝑡 è la derivata rispetto al tempo di x. A giudizio degli autori dell‟articolo, la
dinamica della maggior parte dei processi fisici semplici può essere descritta usando
queste due variabili di stato. Tuttavia, i dati dei sensori sono spesso imprecisi per via di
disturbi nella misura, comunicazione instabile e incertezze nel modello. RDDS sfrutta
filtri di Kalman per predire correttamente stato corrente xk e stato futuro xk+1 a partire da
osservazioni del sensore rumorose. Non c‟è comunicazione tra publisher e subscribers a
meno che il modello non abbia perso accuratezza; tuttavia, la freshness dei dati ricevuti
dal subscriber va a perdersi col passare del tempo. Il periodo in cui l‟ultimo valore
ricevuto resta valido è chiamato intervallo assoluto di validità (avi). Dal momento che
ogni subscriber possiede i modelli dei sensori, può esso stesso determinare stato presente
e stati futuri del sistema per mantenere osservazioni dei sensori “fresche” anche in
assenza di aggiornamenti dai publishers. Periodicamente, lo stato di ciascun sensore
stimato localmente viene aggiunto al buffer. In RDDS, il carico di comunicazione
aumenta solo quando i modelli non sono sufficientemente accurati. Anziché usare un
modello più complesso, che causerebbe un overhead costante, è stato sviluppato un
meccanismo di adattamento della QoD che gestisce i temporanei e improvvisi carichi di
lavoro causati da inaccuratezze nel modello.
3.3 Garanzie Quality of Service e Quality of Data
È un compito proibitivo settare un corretto limite di precisione in fase di progetto o di
sviluppo, dal momento che la massima qualità dei dati che il sistema può reggere si
evolve dinamicamente con il carico del sistema. Per questo, RDDS usa meccanismi di
controllo per tarare dinamicamente il limite di precisione.
In RDDS, la specifica di un sistema comprende sia una specifica sulla QoD,
corrispondente alla definizione di un limite di tolleranza massimo della precisione dei
sensor data, sia una sulla QoS, indicante il massimo carico di CPU, allo scopo di evitare
25
situazioni di sovraccarico; in base al limite di carico specificato, dinamicamente viene di
volta in volta settato il carico target, mai superiore a tale limite. Ogni publisher e
subscriber setta la QoS richiesta e, prima che i subscribers si sottoscrivano a un topic
creato da un publisher, le due entità dovrebbero raggiungere un accordo sulle QoS
associate al topic.
Per ottenere il carico di utilizzo richiesto, i publishers sono supportati da una strategia di
controllo a retroazione. Lo scopo del controllore è quello di assicurare che l‟utilizzo di
CPU misurato sia quanto più possibile vicino a quello di riferimento. Perché si possa
agire sia sulle proprietà a regime che su quelle del transitorio, viene utilizzato un
controllore PI (proporzionale integrale), grazie al quale, selezionando i giusti valori per i
parametri di controllo, è possibile raggiungere le proprietà desiderate, come tempo di
assestamento e sovraelongazione. Altro parametro critico è quello relativo all‟intervallo di
campionamento: se troppo ridotto, in caso di uscita del sistema misurata rapidamente
variabile, il controllore può risultare troppo sensibile a cambiamenti non significativi del
sistema; al contrario, se eccessivo, il controllore può non riuscire a catturare in modo
appropriato la dinamica del sistema.
Invece il principale obiettivo del ciclo con azione in avanti dei subscribers è quello di
stabilire la giusta frequenza di arrivo delle letture dei sensori dai publishers. La teoria
delle code fornisce strumenti di previsione dell‟occupazione di buffer e dei ritardi a
partire dai carichi d‟ingresso. Anziché inviare il segnale di controllo associato al carico di
CPU richiesto direttamente al publisher (il che richiederebbe al publisher di tener traccia
degli stati di ogni singolo subscriber), ogni subscriber lo indirizza al broker: tutti questi
segnali di feed-forward sono raccolti dal broker che ne individua il minimo, che
rappresenta il segnale di feed-forward da trasmettere al publisher.
26
3.4 Test
Gli obiettivi del test sulle performance sono: accertare l‟efficacia della comunicazione
semantics-aware e determinare se i meccanismi di controllo riescono a garantire i carichi
di CPU richiesti dalle specifiche QoS.
Il banco di simulazione emula le operazioni di emergenza svolte nel corso di
un‟operazione in un edificio in fiamme. Ciascun vigile del fuoco possiede un palmare che
colleziona i dati dai sensori vicini, installati nell‟edificio, tramite comunicazione senza fili
e li pubblica per gli altri nodi. Il banco di test impiega un tablet Nokia N810 (con
processore TI OMAP 400 MHz, su cui sono state effettuate le misurazioni) e un insieme
di 33 PC, di cui 31 atti a simulare i dispositivi di 31 pompieri, 1 a fare la parte del broker
e 1 atto a generare le letture dei sensori, tramite il simulatore CFAST (Consolidated
model of Fire And Smoke Transport) del NIST (National Institute of Standards and
Technology). È utilizzato di default il protocollo di trasporto UDP.
I test su RDDS sono stati effettuati in comparazione con un‟implementazione tradizionale
dello standard DDS, OpenDDS, e con un‟implementazione che sfrutta una strategia
differente, denominata approx-caching, in cui la trasmissione dei valori osservati dai
sensori avviene soltanto se la differenza tra il corrente e il valore precedentemente
trasmesso è superiore di una data soglia.
In primo luogo, viene mostrata la distribuzione dati in RDDS che sfrutta la semanticsawareness. A tal fine, sono stati monitorati i carichi di lavoro al variare del numero di
pompieri partecipanti da 1 a 32; durante questo test, i controllori di publisher e subscriber
non sono stati attivati, dunque il limite di tolleranza sulla precisione dei dati è rimasto
fissato. Il test è stato ripetuto 10 volte, e mostra, in tutti e 3 i casi analizzati, una crescita
lineare del numero di messaggi scambiati tra le entità all‟aumentare del numero di
pompieri chiamati in causa, con una sostanziale differenza nel caso di RDDS, in cui la
crescita avviene con una pendenza molto meno elevata rispetto ad esempio all‟approccio
tipico di OpenDDS. Queste evidenze pratiche dimostrano che le operazioni di filtraggio
effettuate in RDDS sui messaggi da trasmettere permettono una estrema scalabilità anche
27
in ambienti con reti a banda limitata. Risultati simili sono scaturiti dal carico di CPU, che
aumenta proporzionalmente in tutti gli approcci; mantenere un livello corretto del carico
della CPU è particolarmente importante per sistemi cyber-physical, in cui la distribuzione
tempestiva dei dati va sempre garantita. Con OpenDDS e approx-caching il sistema va in
sovraccarico rispettivamente a 16 e 32 terminali attivi, mentre con RDDS mantiene un
carico di CPU inferiore al 20% anche con tutti i terminali in funzione.
L‟approccio semantics-aware basato sui modelli di RDDS, dunque, permette di ridurre
sensibilmente l‟overhead dovuto alla comunicazione fra le entità coinvolte.
Il secondo esperimento verifica l‟adattabilità a carichi di lavoro impredicibili. Per questo
test, sono stati invece attivati i controllori di QoS (carico di CPU) e QoD (limite di
precisione) di publisher e subscriber. È stato scelto un limite di precisione massimo di
1°C e un carico di CPU massimo del 70%, e si sono confrontati i risultati con i controlli in
funzione o meno. I risultati hanno mostrato che la presenza del controllo permette al
carico di CPU di avvicinarsi al target qualunque sia il carico di lavoro del sistema; al
contrario, il carico di CPU fluttua significativamente tra sotto-utilizzo e sovraccarico
quando i meccanismi di controllo non sono in funzione, causando con ciò potenzialmente
gravi ritardi di disseminazione dei dati. In RDDS, il limite di precisione sui dati aumenta
all‟aumentare dei carichi di
lavoro.
Oltre
a
questa
valutazione “a regime”, ne è
stato
valutato
comportamento
il
transitorio
quando vengono introdotte
improvvise variazioni
del
–
in
carico
di
lavoro
particolare sul device N810 –
oppure quando aumenta il
tempo di elaborazione dei
Figura 3: test sull‟utilizzo della CPU
28
messaggi lato subscriber, al fine di testare il ciclo di feed-forward. Non appena è
introdotta l‟anomalia nel carico, il limite di precisione segue la CPU e aumenta anch‟esso
per far decrescere il carico di CPU verso il target; entrando in gioco, poi, il segnale di
controllo proveniente dai subscriber in sovraccarico, il carico di riferimento viene ancora
una volta regolato verso il basso grazie all‟aumento del limite di precisione fin quasi al
valore limite 1°C.
29
Conclusioni
Con l‟elaborato appena presentato si è cercato di mostrare l‟ampia potenzialità dello
standard DDS. I due articoli presentati si costruiscono sul DDS andando con intelligenti
artifici a personalizzare il sistema rispetto alle necessità della situazione.
La prima applicazione che si concentra sulla distribuzione di notizie su larga scala
consente alle fonti e ai fruitori di personalizzare il canale di comunicazione configurando
alcuni parametri. È una soluzione flessibile che introduce dei costi che sono stati ridotti
dall‟utilizzo del DDS.
Per ottenere un buon livello di disponibilità di servizio si è fatto ricorso alla replicazione
del sistema di consegna le cui copie si spartiscono i sink in modo casuale, lavorando in
load balancing. Il test ha mostrato che la quantità di overhead è risultata linearmente
proporzionale al numero delle copie. È stato necessario introdurre un ulteriore strato di
gestione per realizzare funzionalità specifiche che le QoS del DDS non coprono.
Il secondo articolo che si concentra su sistemi distribuiti ciber-fisici è uno dei primi
tentativi di portare garanzie di QoS sfruttando la semantica sui dati provenienti dai sensori
e i doppi cicli di controllo integrati. Esso ha mirato a mostrare come l‟utilizzo di CPU di
publisher e subscriber sia una metrica di QoS di primaria importanza, dal momento che i
30
sovraccarichi dei processori sono la prima causa di congestione e di conseguenti ritardi di
propagazione delle informazioni dalla sorgente alle destinazioni, da evitare il più possibile
in applicazioni real-time mission-critical o safety-critical.
31
Bibliografia
[1] OMG, “Data Distribuition Service (DDS)”, http://www.omg.org/spec/DDS/1.4
[2] OMG, “The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability
Wire Protocol Specification”, http://www.omg.org/spec/DDSI-RTPS/2.2
[3] M. Altini, S. Bonetti, G.Cardone, A. Corradi e L. Foschini, “RE.VE.N.GE.:
implementazione tramite RTI-DDS e replicazione del sistema di consegna”,
http://lia.deis.unibo.it/Research/REVENGE/sb_revenge.pdf,
http://www-lia.deis.unibo.it/Courses/RetiLS/prove/Altini/REVENGE%20-%20QoS%20%20relazione.pdf, http://lia.deis.unibo.it/Research/REVENGE/index.html
[4]
W. Kang, K. Kapitanova e S. Hyuk Son, “RDDS: A Real-Time Data Distribuition
Service for Cyber-Physical System”, 2012
32