dds on the wan: the dds routing service -...
TRANSCRIPT
Escuela Técnica Superior de Ingenierías Informática y
de Telecomunicación
Master in Multimedia Systems
MASTER THESIS
DDS on the WAN:
The DDS Routing Service
José María López Vega
Granada, 11th December 2009
MASTER IN MULTIMEDIA SYSTEMS
DDS on the WAN:
The DDS Routing Service
Author:
José María López Vega
Director:
Juan Manuel López Soler
Department:
Teoría de la Señal, Telemática y Comunicaciones
Granada, 11th December 2009
DDS on the WAN:
The DDS Routing Service
José María López Vega
KEYWORDS: DDS, routing, service, WAN, scalability.
Abstract
This project proposes a DDS Routing Service extension for the OMG DDS standard [1]. This ex-
tension is aimed to spatially decouple DDS entities in the context of a WAN (Wide Area Net-
work), thereby enabling the communication of DDS entities in a transparent manner (i.e. with-
out modifications in any DDS application source code). In this way, the proposed DDS Routing
Service drastically eases the scaling and integration of real-time systems across Wide Area Net-
works.
The DDS Routing Service introduces a set of innovative concepts as “Domain Route”, “Ses-
sion”, “Topic Route”, “Auto Topic Route”, “Transformation Class Li-
brary”, “Transformation Class” and “Transformation” which makes possible the
previously described spatial decoupling. For the implementation of these concepts, the DDS
Routing Service takes advantage of several pre published (RFP) and published OMG specifica-
tions [2].
The DDS Routing Service means a first step to the integration of DDS systems to the WAN, and
opens a set of new issues for further research.
D. Juan Manuel López Soler, Profesor Titular de Ingeniería Telemática del
departamento de Teoría de la Señal, Telemática y Comunicaciones de la
Universidad de Granada, como director del Proyecto Fin de Máster de D.
José María López Vega.
Informa:
Que el presente trabajo, titulado:
“DDS on the WAN: The DDS Routing Service”
Ha sido realizado y redactado por el mencionado alumno bajo mi dirección,
y con esta fecha autorizo a su presentación.
Granada, a 11 de Diciembre de 2009
Fdo.
Agradecimientos
En primer lugar, querría dar las gracias a mi familia, en especial a mis padres, por su apoyo in-
condicional, sin el cual no estaría ahora escribiendo estas líneas.
En segundo lugar, me gustaría agradecer a Adela el estar siempre a mi lado. Concretamente,
este último año ha estado lleno de cambios, idas y venidas; gracias a ella todo ha sido mucho
más sencillo.
No me olvido tampoco de David, compañero de aventuras, ya sea por las calles de Arkham, por
el camino de Santiago, o por esta aventura que es la vida.
Quiero agradecer a RTI el haberme permitido realizar una estancia de seis meses en California, la
cual ha supuesto una experiencia irremplazable tanto a nivel profesional como personal. En es-
pecial, quiero agradecer a Gerardo, Fernando y Alex el haber hecho posible el proyecto aquí
presentado. Además, quiero agradecer a Alex (Pepo) todo su apoyo durante mi estancia en Cali-
fornia, y por ser, más que un compañero de trabajo o piso, un amigo.
Asimismo, agradecer a Juanma el mimo que ha puesto en este proyecto y, lo que es más impor-
tante, su calidad humana.
Quizá me esté extendiendo demasiado, pero no quiero dejar fuera de esta sección a mis compis
de comedor (Rubén, Gori y Pepe), ni a mis compañeros de máster (Carlos, David, Miguel, Pablo,
Rafa, Rosa y Santi), que de un modo u otro han sufrido este “PFM”.
Por último y no menos importante, quiero dar las gracias a Rafa, compañero de despacho y ami-
go, por enseñarme día a día las “siete verdades fundamentales de la vida”.
Sinceramente, gracias.
I
Contents
Chapter 1. Introduction .................................................................................................................... 1
1.1 Introduction ............................................................................................................................ 1
1.2 DDS Routing Service Objectives and Restrictions .................................................................. 2
1.3 Background and Related Work ............................................................................................... 4
1.3.1 DDS Interoperability Protocol ......................................................................................... 4
1.3.2 RTPS Support for Different Scenarios .............................................................................. 5
1.3.3 DURABILITY QoS. DDS Persistence Service ...................................................................... 6
1.3.4 Dynamic Topic Types ....................................................................................................... 7
1.3.5 Data Batching .................................................................................................................. 7
1.3.6 Data Security, Authentication and NAT Transversal ....................................................... 8
1.4 Conclusions ............................................................................................................................. 8
Chapter 2. Requirements Analysis ................................................................................................... 9
2.1 Functional Requirements ....................................................................................................... 9
2.1.1 serviceApp ................................................................................................................. 9
2.1.2 service ...................................................................................................................... 11
2.1.3 config ......................................................................................................................... 19
2.2 Non-functional Requirements .............................................................................................. 21
2.3 Conclusions ........................................................................................................................... 22
Chapter 3. Design ........................................................................................................................... 23
3.1 Basic Concepts of DDS Routing Service ................................................................................ 23
3.1.1 Domain Route .......................................................................................................... 25
3.1.2 Session ...................................................................................................................... 25
3.1.3 Topic Route ............................................................................................................. 26
3.1.4 Auto Topic Route .................................................................................................. 27
DDS on the WAN: The DDS Routing Service
II
3.1.5 Content Filtered Topic .................................................................................. 28
3.1.6 Transformation Class ....................................................................................... 28
3.1.7 Transformation ..................................................................................................... 28
3.2 Package and Class Diagrams ................................................................................................ 29
3.2.1 serviceApp Package ................................................................................................ 30
3.2.2 service Package ........................................................................................................ 30
3.2.3 config Package .......................................................................................................... 37
3.2.4 test Package ............................................................................................................... 44
3.3 Sequence Diagrams .............................................................................................................. 44
3.3.1 Discover DDS Entity ....................................................................................................... 44
3.3.2 Route Data Sample........................................................................................................ 48
3.4 Conclusions .......................................................................................................................... 51
Chapter 4. Implementation ............................................................................................................ 53
4.1 RTI Data Distribution Service 4.4d ....................................................................................... 53
4.2. Dynamic Types for DDS ....................................................................................................... 53
4.2.1 Introduction to RTI Dynamic Topic Types API ............................................................... 53
4.2.2 Interacting Dynamically with User Data Types ............................................................. 54
4.3 Object Oriented Programming in C ...................................................................................... 57
4.4 WaitSets .......................................................................................................................... 58
4.5 Linked Lists. Skip Lists. ......................................................................................................... 59
Skip lists .................................................................................................................................. 60
4.6 XML Configuration Format. XSD Schemas. .......................................................................... 61
4.7 Example use of RTI DDS Routing Service ............................................................................. 61
R1. DOMAIN_BRIDGING ......................................................................................................... 62
R2. TOPIC_BRIDGING ............................................................................................................. 63
R3 – R5. TRANSFORMATIONS ................................................................................................ 64
R6 – R11. RTI DDS XML Configuration .................................................................................... 65
4.8 Conclusions .......................................................................................................................... 68
Chapter 5. Conclusions .................................................................................................................. 69
5.1 Main Project Contributions .................................................................................................. 69
5.2 Conclusions .......................................................................................................................... 69
5.3 Future Work ......................................................................................................................... 70
5.3.1 RELIABILITY DDS QoS policy ................................................................................... 70
5.3.2 Discovery Protocol based on Bloom Filters .................................................................. 70
Contents
III
Bibliography .................................................................................................................................... 71
Annex A. RTI DDS Routing Service XML Configuration Format ...................................................... 75
Glossary .......................................................................................................................................... 85
V
List of Figures
Figure 1.1: RTI DDS Routing Service [11]. ......................................................................................... 2
Figure 2.1: serviceApp use case diagram. ................................................................................ 11
Figure 2.2: service use case diagram. ....................................................................................... 19
Figure 2.3: config use case diagram. .......................................................................................... 21
Figure 3.1: DDS Routing Service Entities: Domain Route, Topic Route, and Auto
Topic Route. ............................................................................................................................. 24
Figure 3.2: DDS Routing Service Entities: Domain Route, Session, dataThread, and
dataWaitset. ............................................................................................................................. 25
Figure 3.3: Package diagram for the RTI DDS Routing Service. ...................................................... 29
Figure 3.4: Class diagram for the serviceApp package. ............................................................ 30
Figure 3.5: Class diagram for the service package. ................................................................... 31
Figure 3.6: ROUTERService class diagram. ............................................................................... 32
Figure 3.7: ROUTERDomainRoute class diagram. ...................................................................... 32
Figure 3.8: ROUTERDomainRouteParticipant class diagram. ........................................... 33
Figure 3.9: ROUTERSession class diagram. ............................................................................... 33
Figure 3.10: ROUTERTopicRoute class diagram. ...................................................................... 35
Figure 3.11: ROUTERAutoTopicRoute class diagram. ............................................................ 35
Figure 3.12: ROUTERDiscoveredEntity class diagram. ........................................................ 36
Figure 3.13: ROUTERDiscoveredTopic class diagram. .......................................................... 36
Figure 3.14: ROUTERDiscoveredTypeInfo class diagram. ................................................... 36
Figure 3.15: ROUTERTransformationClassManager class diagram. ................................ 37
Figure 3.16: ROUTERTransformationClass class diagram. ................................................ 37
Figure 3.17: ROUTERTransformation class diagram. ............................................................ 37
Figure 3.18: Class diagram for the config package. ................................................................... 38
Figure 3.19: ROUTERCfgFileParser class diagram. ............................................................... 39
Figure 3.20: ROUTERCfgFileService class diagram. ............................................................ 39
Figure 3.21: ROUTERCfgFileDomainRoute class diagram. ................................................. 40
Figure 3.22: ROUTERCfgFileSession class diagram. ............................................................ 40
DDS on the WAN: The DDS Routing Service
VI
Figure 3.23: ROUTERCfgFileTopicRoute class diagram. ..................................................... 41
Figure 3.24: ROUTERCfgFileAutoTopicRoute class diagram. ........................................... 42
Figure 3.25: ROUTERCfgFileTransformationCassLibrary class diagram. ................. 42
Figure 3.26: ROUTERCfgFileTransformationClass class diagram. ............................... 43
Figure 3.27: ROUTERCfgFileTransformationSequence class diagram. ........................ 43
Figure 3.28: ROUTERCfgFileTransformation class diagram. ........................................... 43
Figure 3.29: ROUTERParameterManager class diagram. ....................................................... 44
Figure 3.30: ROUTERParameterTester class diagram. ......................................................... 44
Figure 3.31: Received new discovery information sequence diagram. ......................................... 45
Figure 3.32: On(Publication/Subscription)Discovered sequence diagram. ......... 46
Figure 3.33: On(Publication/Subscription)Disposed sequence diagram. ............ 47
Figure 3.34: OnParticipantDiscovered sequence diagram. ............................................. 47
Figure 3.35: OnParticipantUnregistered sequence diagram. ........................................ 48
Figure 3.36: Received new data sequence diagram. ..................................................................... 49
Figure 3.37: Route data sequence diagram. .................................................................................. 50
Figure 4.1: TCKind enumeration [29]. ......................................................................................... 55
Figure 4.2: Example of static type [29]. ......................................................................................... 55
Figure 4.3: Code example for defining a static type [29]. .............................................................. 55
Figure 4.4: Code example for registering a type with a Participant [29]. ............................. 56
Figure 4.5: Example of how to implement a class using C structs ........................................... 58
Figure 4.6: Example of linked list ................................................................................................... 60
Figure 4.7: Example of skip list....................................................................................................... 60
Figure 4.8: Example test architecture ............................................................................................ 61
Figure 4.9: Example of XML configuration file for Domain Bridging ............................................. 62
Figure 4.10: Example of Domain Bridging with RTI Shapes Demo................................................. 62
Figure 4.11: Example of XML configuration file for Topic Bridging ............................................... 63
Figure 4.12: Example of Topic Bridging with RTI Shapes Demo .................................................... 63
Figure 4.13: Example of XML configuration file for Topic Bridging with data transformation ...... 65
Figure 4.14: Example of Topic Bridging and data transforming with RTI Shapes Demo ............... 65
Figure 4.15: Example of XML configuration file for Domain Bridging with Content
Filtering .................................................................................................................................. 66
Figure 4.16: Example of Domain Bridging with Content Filtering .................................... 66
Figure 4.17: Example of XML configuration file for using the RTI WAN Transport Service ........... 67
Figure 4.18: Example of XML configuration file for Leaky Bucket Traffic Shaping ........................ 68
VII
List of Tables
Table 2.1: Start DDS Routing Service use case. .............................................................................. 10
Table 2.2: Stop DDS Routing Service use case. ............................................................................... 11
Table 2.3: Create DDS Routing Service use case. ........................................................................... 12
Table 2.4: Start DDS Routing Service use case. .............................................................................. 13
Table 2.5: Create Domain Route use case. ............................................................................... 13
Table 2.6: Create Participant use case. .................................................................................. 14
Table 2.7: Create Session use case. ........................................................................................... 15
Table 2.8: Stop DDS Routing Service use case. ............................................................................... 15
Table 2.9: Delete Domain Route use case. ............................................................................... 15
Table 2.10: Delete Session use case. ......................................................................................... 16
Table 2.11: Delete Participant use case. ................................................................................ 16
Table 2.12: Delete DDS Routing Service use case. ......................................................................... 16
Table 2.13: Discover DDS entity use case. ...................................................................................... 17
Table 2.14: Route data sample use case. ....................................................................................... 18
Table 2.15: Process command line input parameters use case. .................................................... 20
Table 2.16: Load configuration file use case. ................................................................................. 20
1
Chapter 1. Introduction
1.1 Introduction DDS (Data Distribution Service) [1] is an OMG (Object Management Group) [2] specification for
data sharing in distributed systems. DDS is designed for working on scenarios with ultra-high
real-time requisites, in which other classical solutions (e.g. CORBA [3]) do not suffice. For com-
municating remote entities, DDS adopts a data-centric PS (Publish/Subscribe) approach. The
simple and intuitive PS model is an alternative to the traditional client-server paradigm [4]. The
DDS data-centric middleware decouples temporally and spatially the entities that generate and
send data (publishers) from the entities which receive and consume data (subscribers). In this
way, publishers just publish data for delivering information to the subscribers, and information
consumers (subscribers) just express their wish and receive data, independently of their spatial
and temporal locations.
DDS aims to ease the job of application programmers, as well as to alleviate the application it-
self, regarding transmission reliability in distributed environments with real-time requirements.
In this sense, the OMG-DDS standard specifies two different layers:
The lower level DCPS (Data Centric Publish Subscribe) [1]. It delivers the information to
the destinations in a very efficient way [5]. DCPS is an OMG standard API for the pub-
lish/subscribe model.
An optional level called Data Local Reconstruction Layer (DLRL) [1]. This layer acts as an
interface between the application layer and the DCPS layer. DLRL is object oriented and
was specified for easing the integration of DCPS in user applications.
Many real-time and near real-time systems rely on DDS to manage their real-time and high-
performance information dissemination needs [6] [7]. Within a LAN, DDS can directly address
every participant to operate on a highly-scalable, peer-to-peer fashion using multicast. However,
more and more these systems are being integrated in WAN aiming to extend the real-time pub-
lish/subscribe data-distribution benefits to the GIG (Global Information Grid) [8]. The WAN inte-
gration must deal, among others, with the following deployment issues:
Massive scalability. System feasibility with over 850 nodes accessing the DDS Global Da-
ta Space has already been demonstrated [9]. However, DDS based WAN deployments
DDS on the WAN: The DDS Routing Service
2
could involve 10000 or even more nodes. These massive scenarios will likely exceed the
exiting DDS implementations capabilities.
Bridging between Global Data Spaces. In some cases, data-spaces may require
maintaining certain information contained within. Different services -or coalition mem-
bers- may demand their own private Topics and Global Data Spaces. It points out to
the need for deploying multiple bridged Global Data Spaces with total control over the
information flowing between them.
Firewall and NAT Traversal. For security reasons, network infrastructures may be parti-
tioned and protected -militarized zones- by firewalls. Similarly, for accessing private ad-
dress spaces NAT is required. DDS Global Data Spaces within firewalls and NATs demand
mechanism that allows controlled data to flow between these network segments.
Lack of multicast support on WAN. Multicast is relied upon by DDS for discovery and
scalability. However, using multicast in the WAN is just not possible. Therefore, it is ne-
cessary to use tunneling mechanisms in order to communicate two remote multicast
LANs through the WAN.
In this work we propose the DDS Routing Service [10] [11], a project which is being developed in
collaboration with Real-Time Innovations Inc. (RTI) [12]. The DDS Routing Service aims to spatial-
ly decouple DDS entities in the context of a WAN scenario, thereby enabling the previously de-
scribed issues to be resolved in a transparent manner (i.e. without modifying any existing DDS
application).
The document is organized as follows. This chapter briefly defines the objectives of the proposed
DDS Routing Service. It also provides background information and identifies relevant related
issues. In Chapters 2 and 3, the requirements analysis and system design are respectively in-
cluded. Chapter 4 explains the service implementation. Finally, Chapter 5 summarizes the main
contributions and conclusions of the project and addresses future research directions.
1.2 DDS Routing Service Objectives and Restrictions A correct identification of the project objectives is basic for a successful design and implementa-
tion. Therefore, in this section the main objectives of the project are precisely established.
Figure 1.1: RTI DDS Routing Service [11].
The goal of this project is to design and implement the so called DDS Routing Service. This new
service can be considered as an extension for DDS middleware. This extension will allow data
communication between DDS applications located in remote sites (Figure 1.1), even connected
across WAN. The innovative proposed DDS Routing Service will make possible to communicate
Chapter 1. Introduction
3
different Domain Participants and/or Topics [11], even optionally performing some
data transformations.
The DDS Routing Service design must fulfill the following functionality (denoted by R1 to R11).
R1. DOMAIN_BRIDGING
Until now, no DDS implementation enables an application running in a certain data-space to
access (communicate) to a different data-space. DDS Routing Service must allow communi-
cation between DataWriters and DataReaders in two different domains, i.e. in different
data-spaces.
R2. TOPIC_BRIDGING
In DDS, to share the data types knowledge is a requirement for different applications to commu-
nicate with DCPS. Data (of any data type) are uniquely identified by means of a name called
Topic. DDS Topics interconnect DataWriters and DataReaders that exchange data of
the same type. Consequently, the communication between Topics of different names or data
types is up to now not possible.
The proposed DDS Routing Service should overcome these limitations. It must achieve Topics
interoperation, even if these Topics have different data types or Topic names.
R3. DATA_TRANSFORMATION
In order to communicate Topics, the DDS Routing Service will transform the data in a given
Topic A before sending them to a Topic B. Furthermore, the DDS Routing Service must be
able to filter the Topic data before republishing them. This feature can be useful for preventing
private data from being published through the WAN.
R4. PLUGGABLE_DATA_TRANSFORMATION
The user should be able to configure the DDS Routing Service for using custom transformations.
In this way, the user will be able to load dynamically linked libraries [13] (also known as “shared
objects”) containing user’s transforming functions.
From now on, we will refer to dynamically linked libraries as “DLL”, including both Windows
“Dynamic Linkable Libraries” and Unix “Shared Objects”.
R5. BUILTIN_DATA_TRANSFORMATION
DDS Routing Service will allow performing some basic transformations, e.g. replacing a Topic
field with a given value or performing simple arithmetical operations with Topic data.
R6. XML_CONFIGURATION
The behavior of DDS Routing Service must be configured using XML (Extensible Markup Lan-
guage) [14] files.
R7. CONTENT_FILTERED_TOPICS_SUPPORT
DDS Routing Service should be compatible with Content Filtered Topics. A Content
Filtered Topic is a Topic with data filtering properties. It makes it possible to subscribe
to Topics and at the same time to specify that only a subset of the Topic data is of interest.
DDS on the WAN: The DDS Routing Service
4
R8. TRANSPORT_CONFIGURATION
The transport protocol of the DDS Routing Service must be customizable using DDS QoS (Quality
of Service) policies.
This requirement is critic for resolving the DDS WAN integration issues described in Section 1.1,
because it allows the DDS Routing Service to use secure protocols (e.g. TLS, Transport Layer Se-
curity [15]) for data privacy and to use external services (like the RTI WAN Transport Service [16])
for NAT transversal.
R9. FULL_QOS_CONFIGURATION
The DDS Routing Service QoS policies must be also totally configurable through XML configura-
tion files.
R11. FLOW_CONTROL
DDS Routing Service must have a flow controller. The flow controller will be implemented using a
leaky bucket traffic shaper [17]. It will allow controlling the rate at which data is injected to the
output. This feature will be configurable using DDS QoS policies.
1.3 Background and Related Work As it was previously stated in Section 1.1, many real-time and near real-time systems rely on DDS
middleware to communicate their data. Within a LAN, DDS can directly address every participant
to operate on a highly-scalable, peer-to-peer fashion using multicast. However, more and more
these systems are being integrated in WAN aiming to extend the real-time publish/subscribe
data-distribution benefits to the GIG (Global Information Grid) [8]. In this section we discuss
relevant and related features that are necessary and directly involved to accomplish the DDS
WAN integration.
1.3.1 DDS Interoperability Protocol
DDS specification does not indicate the protocol used by the implementation to exchange mes-
sages. As a result, different DDS implementations would not interoperate unless vendor-specific
“bridges” will be provided.
With the increasing adoption of DDS, it was considered necessary to define a standard “wire
protocol” that would allow interoperating different DDS implementations. The desired “DDS
wire protocol” should be capable of taking advantage of the QoS DDS facilities to optimize the
underlying transport capabilities. In particular, the desired wire protocol should be capable of
exploiting the multicast, best-effort, and connectionless nature of many of the DDS QoS settings.
In this context, the OMG published the “DDS Interoperability Protocol” (DDSI) [18], a supplement
to the OMG DDS specification [1]. DDSI aims to interoperate different DDS implementations by
using the RTPS (Real-Time Publish Subscribe) protocol.
The RTPS protocol was originally developed in industrial automation context and was in fact
approved by the IEC as part of the Real-Time Industrial Ethernet Suite IEC-PAS-62030 [19]. No-
wadays, it is a field proven technology that is currently adopted worldwide in thousands of ap-
plications.
Chapter 1. Introduction
5
RTPS was specifically developed to support the unique requirements of real-time data-
distribution systems [18]:
Performance and quality-of-service properties to enable best-effort and reliable publish-
subscribe communications for real-time applications over standard IP networks.
Fault tolerance to allow the creation of networks without single points of failure.
Extensibility to allow the protocol to be enhanced with new services without breaking
backwards compatibility and interoperability.
Plug-and-play connectivity so that new applications and services are automatically dis-
covered and applications can join and leave the network at any time without the need
for reconfiguration.
Configurability to allow balancing the requirements for reliability and timeliness for each
data delivery.
Modularity to allow simple devices implementing a subset of the protocol and still par-
ticipating in the network.
Scalability to enable systems to potentially scale to very large networks.
Type-safety to prevent application programming errors from compromising the opera-
tion of remote nodes.
As one of the application domains targeted by DDS, the industrial automation community de-
fined requirements for a standard publish-subscribe wire-protocol that closely match those of
DDS. As a direct result, a close synergy exists between DDS and the RTPS wire-protocol, both in
terms of the underlying architecture and RTPS features [18].
1.3.2 RTPS Support for Different Scenarios
One of the main features of RTPS is the discovery. RTPS discovery allows RTPS upper layer to
know about the presence of other RTPS entities, thereby enabling them to communicate. The
RTPS specification splits up the discovery protocol into two independent protocols [18]:
1. Participant Discovery Protocol (PDP)
2. Endpoint Discovery Protocol (EDP)
A Participant Discovery Protocol (PDP) specifies how Participants discover each other in
the network. Once two Participants have discovered each other, they exchange informa-
tion on the Endpoints they contain using an Endpoint Discovery Protocol (EDP). Apart from this
causality relationship, both protocols can be considered independent.
Implementations may choose to support multiple PDPs and EDPs, possibly vendor-specific. As
long as two Participants have at least one PDP and EDP in common, they can exchange the
required discovery information. For the purpose of interoperability, all RTPS implementations
must provide at least the following discovery protocols, both based in SDP (Simple Discovery
Protocol) [20]:
1. Simple Participant Discovery Protocol (SPDP)
2. Simple Endpoint Discovery Protocol (SEDP)
DDS on the WAN: The DDS Routing Service
6
Both are basic discovery protocols that suffice for small to medium scale networks. Additional
PDPs and EDPs that are geared towards larger networks may be added to future versions of the
specification.
The requirements on the Participant and Endpoint Discovery Protocols may vary depending on
the deployment scenario. For example, a protocol optimized for speed and simplicity (such as a
protocol that would be deployed in embedded devices on a LAN) may not scale well to large
systems in a WAN environment. For this reason, the RTPS specification [18] allows implementa-
tions to support multiple PDPs and EDPs. The only requirement imposed by RTPS for the purpose
of interoperability is that all RTPS implementations support at least the SPDP and SEDP.
If an implementation supports multiple PDPs, each PDP may be initialized differently and addi-
tionally it can discover a different set of remote Participants. Remote Participants
using different vendor’s RTPS implementations must be connected using at least the SPDP to
ensure interoperability.
Even when the SPDP is used by all Participants, remote Participants may still use
different EDPs. The list of supported EDP by given Participant is included in the information
exchanged by the SPDP. All Participants must support at least the SEDP, so they always
have at least one EDP in common. However, if two Participants both support different
EDPs, this alternative protocol can be used instead. In that case, there is no need to create the
SEDP built-in Endpoints, or if they already exist, it is not necessary to configure them to match
the new remote Participant. This approach enables a vendor to customize the EDP if de-
sired without compromising interoperability.
1.3.3 DURABILITY QoS. DDS Persistence Service
The DataReader and DataWriter decoupling achieved by the DDS data-centric Pub-
lish/Subscribe paradigm allows an application writing data even if there are no current readers
on the network. Moreover, a DataReader that joins the network after some data has been
written could be interested in accessing the most current values of the data as well as some
history. This feature is known as the DDS Persistence Service [1], a part of the OMG DDS standard
which is controlled through the DURABILITY QoS policy. DURABILITY controls whether the
DDS Persistence Service will actually make data available to late-joining readers. Note that al-
though related, this policy does not strictly control what data the DDS Persistence Service will
maintain internally. That is, the DDS Persistence Service may choose to maintain some data for
its own purposes (e.g., flow control) and yet not make it available to late-joining readers if the
DURABILITY QoS policy is set to VOLATILE.
The defined DURABILITY QoS values are ordered according to this precedence
VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT
Therefore, the DURABILITY offered value is considered compatible with the requested one if
and only if
offered DURABILITY kind ≥ requested DURABILITY kind
Chapter 1. Introduction
7
For any Topic with DURABILITY equal to TRANSIENT or PERSISTENT, the DDS Persis-
tence Service will behave as if there was a corresponding “built-in” DataReader and Data-
Writer configured with the same DURABILITY value. In other words, it works as if some-
where in the system (possibly on a remote node) there were a “built-in DataReader” sub-
scribed to that Topic and a “built-in DataWriter” publishing that Topic for the new sub-
scribers that join the system.
For each Topic, the built-in fictitious “persistence service” DataReader and DataWriter
get their QoS values from the DURABILITY QoS of the real Topic. So, it can be seen as if the
service first calls find_topic function to get the real Topic QoS, and accordingly assign it
to the fictitious built-in entities.
The data persistence is an important feature for DDS WAN scenarios. In a WAN, the data deli-
very is not guaranteed. Consequently, DDS has to assure that data are delivered to all the sub-
scribers, even if connection between the subscribers is temporally lost.
1.3.4 Dynamic Topic Types
Until now, any DDS Topic had a static type associated to it. Consequently, before publishing or
subscribing information the type of the data associated to any Topic should be declared. In
order to increase DDS flexibility, the OMG is working on the “Extensible and Dynamic Topic Types
for DDS” specification [21], currently in the Request for Proposals (RFC) phase. The RFP looks for
responses to extend the DDS standard with the following features:
1. Extensible Topic Type System. Responses to this RFP are expected to specify an abstract
type definition for DDS Topic Type. It should provide built-in support for extensibility,
as well as support for complex types such as object maps, and sparse data.
2. Dynamic DDS API. Responses to this RFP are expected to define a Dynamic DDS API to
be used as an alternative to the current API. It will allow defining, reading, taking, ac-
cessing, and writing Topics with types that will not be known at compile time.
3. Data Encapsulation Format. Responses to this RFP shall define new data encapsulation
format, or extend the currently defined, such that it supports extensible and dynamic
types.
The proposed DDS Routing Service makes an extensive use of Dynamic Topic Types for accessing
to arbitrary Topic types. More information about Dynamic Topic Types and its application in
the DDS Routing Service can be found in Chapters 2, 3 and 4.
1.3.5 Data Batching
One reason that may hinder DDS system scalability in WAN, even though it works efficiently in a
LAN environments, is related to information packaging. Note that in a LAN it is possible to send a
new message for each new published data. However, this approximation could cause an exces-
sive overhead that cannot be afforded in a WAN scenario.
This problem can be alleviated by adopting data batching, i.e. to gather data before sending it
through the WAN. This approach can be useful not only for the actual data, but also for discov-
ery information. However, it can introduce new problems: in some cases, the CPU use will be
DDS on the WAN: The DDS Routing Service
8
increased and, additionally the incurred delay for data delivering (or discovery information) will
also be increased. Thus, an optimal network usage versus data delay trade-off must be reached.
Currently, up to the author´s knowledge the RTI implementation [22] is the only DDS distribution
which supports data batching. [22]According to RTI performance analysis, the use of data batch-
ing doubles the number of messages that DDS middleware can handle (Measured over Gigabit
Ethernet between single-threaded applications running on 2.0 GHz Opteron processors with 32-
bit Red Hat Enterprise Linux 4.0 using 8-byte messages) [23].
1.3.6 Data Security, Authentication and NAT Transversal
Deployment of DDS applications yields security challenges that require severe protection meas-
ures for corporate networks. Until now, DDS systems are deployed in local and controlled envi-
ronments (LANs) which are generally populated by trusted nodes. However, shared data with a
remote node across WAN will be unfortunately exposed to distrusted nodes. It requires includ-
ing data authentication and encryption. Current DDS implementations provide secure data dis-
tribution using different techniques. For example, RTI provides data security and authentication
using DTLS (Datagram Transport Layer Security) [24], an extension of SSL/TLS security protocol.
To integrate PS systems on the WAN is also necessary to apply techniques for firewalling and
Network Address Translator (NAT) traversal. In this sense, the RTI DDS implementation uses
STUN [25] (Simple Traversal of UDP through NATs) protocol to address these problems. STUN is
a lightweight protocol that allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet. It also provides the ability for applications to
determine the public Internet Protocol (IP) addresses allocated to them by the NAT server.
STUN works with many existing NATs, and does not require any special behavior from them. As a
result, it allows DDS applications to work through existing NAT infrastructure.
1.4 Conclusions In this chapter we have introduced the DDS Routing Service extension to DDS middleware. In
particular, main service objectives and requirements have been established.
The proposed DDS Routing Service will extend the spatial decoupling concept of DDS to the
WAN. This new facility will enable DDS applications to communicate across WAN scenarios with-
out requiring any modification to their source code. For achieve this objective, the DDS Routing
Service will take advantage of several pre published (RFP) and published OMG specifications.
In Chapter 2 the functional and non functional requirements of the proposed service are studied
in detail.
9
Chapter 2. Requirements Analysis
Requirements Analysis is the process of understanding the customer needs and expectations
from a proposed system or application. Requirements are a description of how a system should
behave and a description of system properties or attributes as well. It can alternatively be a
statement of ‘what’ an application is expected to do. This chapter aims to identify the DDS
Routing Service requirements.
For any service design, two types of requisites can be identified:
Functional requirements: They describe the interaction between the system and its en-
vironment. They also identify the provided services and characterize the expected sys-
tem reactions to a set of envisaged stimulus.
Non-functional requirements: They describe qualities or restrictions of the system that
are not directly related with its functional behavior.
2.1 Functional Requirements In order to achieve the objectives described in Chapter 1, we adopt a modular design approach.
This approach aims to improve the system extensibility and reusability. Specifically, we define
the following subsystems:
serviceApp: This subsystem is the entry point to the application, and contains the
necessary files to launch the service with a set of input configuration parameters.
service: This module is the core of the system, and contains the required files to
create all the entities that are necessary to provide the DDS Routing Service.
config: It loads the configuration from an XML file. This file describes the routes to be
created and the associated QoS policies.
transformationDLL: This external module defines the actions to be performed be-
fore re-publishing the data.
In next sections we explain the requirements of the previously described subsystems.
2.1.1 serviceApp
As has been introduced in the previous section, the serviceApp subsystem is the entry point
to the DDS Routing Service. In this section we describe the functional requirements for this sub-
system.
DDS on the WAN: The DDS Routing Service
10
Actor Descriptions
In serviceApp subsystem the following actors are defined.
User: She will control the system, initializing it or stopping it through the console.
service: This secondary actor is initialized or finalized by serviceApp.
config: This actor processes User’s command line input parameters.
DDS: This actor is the module for accessing to the OS API in a platform independent way.
Moreover, it provides access to DDS entities.
Use Cases by Actors
User
For the User primary actor two use cases are considered:
Start DDS Routing Service: The service is created and started, using command line input
parameters. See Table 2.1.
Stop DDS Routing Service: The subsystem sends the termination signals to the ser-
vice and DDS actors. After that, the system finalizes its execution. See Table 2.2.
Name Start DDS Routing Service
Summary The service is created and started, using command line input para-meters.
Dependencies
Actors User (primary), service (secondary), config (secondary), DDS (secondary)
Preconditions The service is not started.
Postconditions The service is started and running.
Basic course of events 1. The user initializes the system. 2. A signal handler is installed through DDS. 3. The command line input parameters are processed through
the config module.
4. The basic QoS policies are configured for DDS. 5. The DDS Routing Service is created and started through the
service actor. 6. The system remains waiting for a finalization signal.
Table 2.1: Start DDS Routing Service use case.
Name Stop DDS Routing Service
Summary The subsystem sends the termination signals to the service and DDS actors. After that, the system finalizes its execution.
Dependencies
Actors User (primary), service (secondary), DDS (secondary).
Preconditions The service is started.
Postconditions The service is stopped.
Basic course of events 1. The user sends the finalization signals. 2. The existing DDS Routing Service is stopped and deleted
through the service actor.
Chapter 2. Requirements Analysis
11
3. The existing DDS entities are removed. 4. The system exits.
Table 2.2: Stop DDS Routing Service use case.
Use Case Diagram
In Figure 2.1 the serviceApp use case diagram is depicted.
User
Start DDS Routing
Service
Stop DDS Routing
Service
serviceApp
config
service
DDS
Figure 2.1: serviceApp use case diagram.
2.1.2 service
The service subsystem is the core of our scheme. It contains the required files to create all
the entities that are necessary to provide the DDS Routing Service.
Actor Descriptions
In service the following actors are considered.
serviceApp: It will send the signals for creating and starting or stopping and deleting
the DDS Routing Service.
discoveryWaitset: This actor will notify the subsystem that a new DDS entity has
been discovered.
dataWaitset: This actor will notify the subsystem that a new data sample is availa-
ble.
transformationDLL: This actor represents an external DLL which contains the re-
quired functions to perform data transformations.
DDS: This actor is the module for accessing to the OS API in a platform independent way.
Moreover, it provides access to DDS entities.
config: This actor provides information about the DDS Routing Service configu-
ration.
DDS on the WAN: The DDS Routing Service
12
Use Cases by Actors
serviceApp
In Tables 2.3-2.12 the following serviceApp use cases are detailed.
Create DDS Routing Service: The subsystem allocates the resources that are necessary
to run the service.
Start DDS Routing Service: The subsystem creates all the entities that are necessary to
run the service and starts the discovery thread and Domain Routes.
Create Domain Route: A Domain Route is initialized and associated threads and
entities are created and started.
Create Participant: A Participant is initialized and its associated Builtin-
Subscriber is configured.
Create Session: Publisher, Subscriber, dataWaitset and routes associated
to a Session are created and started.
Stop DDS Routing Service: The DDS routing service is stopped and all the existing Do-
main Routes are deleted.
Delete Domain Route: A Domain Route is stopped and deleted.
Delete Session: A Session is stopped and deleted.
Delete Participant: A Participant and its associated entities are deleted.
Delete DDS Routing Service: It frees all the remaining allocated resources.
discoveryWaitset
Table 2.13 shows the discoveryWaitset use case.
Discover DDS entity: The subsystem reacts to changes in DDS discovery, creating or de-
leting Topic Routes, publications, subscriptions or Participants.
dataWaitset
Table 2.14 shows the dataWaitset use case.
Route data sample: The dataWaitset notifies the subsystem that a new sample is
waiting to be routed.
Name
Create DDS Routing Service
Summary The subsystem allocates the resources that are necessary to run the service.
Dependencies
Actors serviceApp (primary), config (secondary), DDS (secondary).
Preconditions The routing service does not exist.
Postconditions The service has been created using given configuration parameters.
Basic course of events 1. serviceApp requests the creation of the service. 2. The subsystem allocates the necessary resources for pro-
viding de service through DDS. 3. The service is initialized using a set of configuration para-
meters provided by the config module. Table 2.3: Create DDS Routing Service use case.
Chapter 2. Requirements Analysis
13
Name Start DDS Routing Service
Summary The subsystem creates all the entities that are necessary to run the service and starts the discovery thread and Domain Routes.
Dependencies Create Domain Route.
Actors serviceApp (primary), discoveryWaitset (secondary), DDS (secondary), transformationDLL (secondary).
Preconditions The routing service is created, but not started.
Postconditions The routing service has been started.
Basic course of events 1. serviceApp requests to start the service. 2. The discoveryWaitset is created and started. 3. The transformationClassManager and all its asso-
ciated transformationClasses are created and as-sociated to an external transformationDLL.
4. According to loaded configuration, the required Domain Routes are created (Create Domain Route use case).
5. The discoveryThread is created for managing discov-ered DDS entities.
Table 2.4: Start DDS Routing Service use case.
Name Create Domain Route
Summary A Domain Route is initialized and the associated threads and entities are created and started.
Dependencies Create Participant Create Session
Actors discoveryWaitset (secondary), DDS (secondary).
Preconditions This Domain Route does not exist.
Postconditions A new Domain Route has been started.
Basic course of events 1. The subsystem allocates the required memory for the Do-
main Route. 2. The subsystem associates a transformationClass-
Manager to the Domain Route. 3. The QoS policies for the new Domain Route are initia-
lized. 4. The automatic registration of builtin types is disabled. 5. Two Participants are created and initialized (Create
Participant use case).
6. The Session data structures are created and started ac-cording to loaded configuration (Create Session use
case). 7. For each Participant, the subsystem attaches three
conditions (associated to Publisher, Subscriber and Participant BuiltinDataReaders) to the dis-coveryWaitset.
Table 2.5: Create Domain Route use case.
DDS on the WAN: The DDS Routing Service
14
Name Create Participant
Summary A Participant is initialized and its associated BuiltinSub-
scribers are configured.
Dependencies
Actors DDS (secondary).
Preconditions The Participant does not exist.
Postconditions The Participant has been created with DDS_DATA_AVAILABLE status condition enabled for each BuiltinDataReader.
Basic course of events 1. The subsystem disables auto enabling of DDS entities. 2. The subsystem creates lists for discovered topics, types,
DataWriters and DataReaders. 3. The Participant entity is created using DDS (but is not
yet enabled). 4. The subsystem gets the BuiltinSubscriber asso-
ciated to the created Participant. 5. The subsystem gets the BuiltinDataReaders asso-
ciated to the ”DDS_PUBLICATION_TOPIC_NAME”, “DDS_SUBSCRIPTION_TOPIC_NAME” and “DDS_PARTICIPANT_TOPIC_NAME” builtin Top-ics.
6. The subsystem enables
“DDS_DATA_AVAILABLE_STATUS” status condition for
each BuiltinDataReader .
7. The subsystem enables the Participant. 8. The subsystem restores initial “auto-enable-created-
entities” behavior to DDS. Table 2.6: Create Participant use case.
Name Create Session
Summary Publisher, Subscriber, dataWaitset and routes asso-ciated to a Session are created and started.
Dependencies
Actors DDS (secondary), dataWaitset (secondary).
Preconditions The Session does not exist.
Postconditions The Session has been created and has been started.
Basic course of events 1. The required resources are allocated. 2. A transformationClassManager is associated to
the Session. 3. The subsystem creates lists for AutoTopicRoutes and
TopicRoutes. 4. dataWaitset is created and exit condition is attached. 5. The Publisher and the Subscriber associated to
each Participant are created. 6. According to service configuration, AutoTopicRoutes
and TopicRoutes are created and associated to transformationClasses.
Chapter 2. Requirements Analysis
15
7. AutoTopicRoutes and TopicRoutes are added to the appropriated lists.
8. The created Session is added to a Session list.
9. The sessionThread is created. 10. The TopicRoutes are started (a status condition asso-
ciated to each route is attached to the dataWaitset) and their associated DataWriters and DataReaders are created.
Table 2.7: Create Session use case.
Name Stop DDS Routing Service
Summary The routing service is stopped and all the existing Domain Routes are deleted.
Dependencies Delete Domain Route
Actors serviceApp (primary), DDS (secondary), discoveryWaitset (secondary).
Preconditions The routing service is started.
Postconditions The routing service has been stopped.
Basic course of events 1. serviceApp requests to end the service. 2. The subsystem sends the finalization signal to discove-
ryThread and frees the associated resources.
3. The subsystem notifies all the Session threads that they have to finish.
4. The subsystem stops and deletes existing Domain
Routes (Delete Domain Route use case).
5. The subsystem deletes the existing discoveryWait-set.
Table 2.8: Stop DDS Routing Service use case.
Name Delete Domain Route
Summary A Domain Route is stopped and deleted.
Dependencies Delete Session
Delete Participant
Actors discoveryWaitset (secondary), DDS (secondary).
Preconditions This Domain Route is started.
Postconditions A new Domain Route has been deleted.
Basic course of events 1. The subsystem detaches the six conditions from the dis-coveryWaitset .
2. The associated Sessions are stopped and deleted (De-lete Session use case).
3. The associated Participants are stopped and deleted (Delete Participant use case).
4. The subsystem frees the memory associated to the Do-main Route.
Table 2.9: Delete Domain Route use case.
DDS on the WAN: The DDS Routing Service
16
Name Delete Session
Summary A Session is stopped and deleted.
Dependencies
Actors DDS (secondary), dataWaitset (secondary).
Preconditions This Session is started.
Postconditions The Session has been deleted.
Basic course of events 1. The sessionThread is stopped and deleted.
2. The associated Topic Routes are stopped (associated status condition is detached from the dataWaitset).
3. The associated Auto Topic Routes are deleted.
4. The associated Topic Routes are deleted. 5. Publisher and Subscribers are deleted. 6. The dataWaitset is deleted.
Table 2.10: Delete Session use case.
Name Delete Participant
Summary A Participant and its associated entities are deleted.
Dependencies
Actors DDS (secondary).
Preconditions This Participant is started.
Postconditions The Participant has been deleted.
Basic course of events 1. The subsystem deletes all the discovered topics, types, DataWriters and DataReaders associated to the Participant.
2. The Participant is deleted. Table 2.11: Delete Participant use case.
Name Delete DDS Routing Rervice
Summary It frees all the remaining allocated resources.
Dependencies
Actors serviceApp (primary), DDS (secondary).
Preconditions The routing service is stopped.
Postconditions The routing service has been deleted.
Basic course of events 1. It frees the remaining allocated resources. 2. The routing service is deleted.
Table 2.12: Delete DDS Routing Service use case.
Name Discover DDS entity
Summary The subsystem reacts to changes in DDS discovery, creating or de-leting Topic Routes, publications, subscriptions or Partici-pants.
Dependencies
Chapter 2. Requirements Analysis
17
Actors discoveryWaitset (primary), DDS (secondary).
Preconditions The service associated to the discoveryWaitset is started.
Postconditions The subsystem has informed to the Topic Routes and Auto Top-ic Routes about the discovered entity.
Basic course of events 1. The discoveryWaitset notifies the subsystem that there are changes in the discovery information of an entity.
2. Depending on the identified entity, a different action is performed for each active DomainRoute.
a. Subscriber BuiltinDataReader: The sub-system processes the information contained in each received simple. A different action is per-formed depending on the state of the instance as-sociated to the sample:
i. If the instance is alive and there is not a subscription to the discovered type, the
subsystem iterates through all the Topic Routes and Auto Topic Routes to let them know about the new discovered subscription.
ii. If the instance is not alive, the associated subscription and topic are removed.
b. Publisher BuiltinDataReader: The sub-system processes the information contained in each received simple. A different action is per-formed depending on the state of the instance as-sociated to the sample:
i. If the instance is alive and there is not a publication to the discovered type, the
subsystem iterates through all the Topic Routes and Auto Topic Routes to let them know about the new discovered publication.
ii. If the instance is not alive, the associated publication and topic are removed.
c. Participant BuiltinDataReader: The subsystem processes the information contained in each received simple. A different action is per-formed depending on the state of the instance as-sociated to the sample:
i. If the instance is alive and the discovered Participant belongs to the same rou-ter group than the service does, the new Participant is ignored.
ii. If the instance is not alive, all the asso-ciated publications, subscriptions and Topics are removed.
Table 2.13: Discover DDS entity use case.
DDS on the WAN: The DDS Routing Service
18
Name Route data sample
Summary The dataWaitset notifies the subsystem that a new sample is waiting to be routed.
Dependencies
Actors dataWaitset (primary), DDS (secondary), transforma-
tionDLL (secondary).
Preconditions The Session associated to the dataWaitset is started.
Postconditions The subsystem has routed the received data sample.
Basic course of events 1. The dataWaitset notifies the subsystem that a new sample has arrived.
2. Using a DDS_DynamicDataReader, the subsystem re-trieves all available samples.
3. The samples are pushed into different routes depending on which DataReader they are associated to.
4. If received data are valid: a. If data transformation is enabled for a certain
route, data samples are transformed using transformationDLL functions.
b. Samples are published according to the parameters of their associated route.
5. If received data are not valid (i.e. the subsystem has re-ceived signaling information), the subsystem publish the received signaling information.
Table 2.14: Route data sample use case.
Use Case Diagram
In Figure 2.2 the service use case diagram is depicted.
Chapter 2. Requirements Analysis
19
serviceApp
Create routing
service
Start routing
service
Create domain route
Stop routing
service
Delete routing
service
config
Create session
Create participant
Delete domain route
Delete session
Delete participant
discoveryWaitset
dataWaitset
«uses»
«uses»«uses»
«uses»
«uses»
«uses»
DDS
service
Discover DDS entity
Route data sample
transformationDLL
Figure 2.2: service use case diagram.
2.1.3 config
In this section we describe the functional requirements for the subsystem config. It is used to
load the configuration of the service from an XML file.
Actor Descriptions
In this case two actors are included.
serviceApp: This actor will require to process command line input parameters.
DDS on the WAN: The DDS Routing Service
20
service: It will require to load a configuration file according some input parameters.
Use Cases by Actors
serviceApp
Table 2.15 shows the designed serviceApp use case.
Process command line input parameters: The subsystem processes user command line
input parameters and stores them.
service
Table 2.16 shows the service use case.
Load configuration file: The subsystem loads the configuration of the service from an
XML configuration file.
Name Process command line input parameters
Summary The subsystem processes user command line input parameters and stores them.
Dependencies
Actors serviceApp (primary)
Preconditions serviceApp has a string to be processed.
Postconditions A struct with the processed parameters has been returned to serviceApp.
Basic course of events 1. serviceApp requests the subsystem to process a string which contains command line parameters.
2. The subsystem returns to serviceApp a struct with the processed parameters.
Table 2.15: Process command line input parameters use case.
Name Load configuration file
Summary The subsystem loads the configuration of the service from an XML configuration file.
Dependencies
Actors service (primary).
Preconditions service has an XML file to be processed.
Postconditions A struct with the service configuration has been returned to service module.
Basic course of events 1. service requests the subsystem to process an XML con-figuration file.
2. The subsystem returns to service a struct with the DDS Routing Service configuration.
Table 2.16: Load configuration file use case.
Chapter 2. Requirements Analysis
21
Use Case Diagram
Finally, in Figure 2.3 the config use case diagram is depicted.
service
serviceApp
Process command line
input parameters
Load configuration
file
config
Figure 2.3: config use case diagram.
2.2 Non-functional Requirements
Implementation
The system will be implemented in C.
A set of unit test will be implemented for checking if the service works properly.
The system will be developed using the RTI Data Distribution Service 4.4d DDS middle-
ware.
Interface
Each subsystem will be prepared to communicate with the rest of subsystems.
Reliability
Any designed function which can fail will return a boolean variable. It will provide in-
formation about the operation success or failure.
The system and all its entities will can be created or deleted at any time.
Changes in discovered entities will be gracefully handled, propagating the discovery in-
formation through the existing routes when necessary.
Usability
The DDS Routing service should be configured through XML (Extensible Markup Lan-
guage) configuration files.
In order to ease the creation of XML configuration files, the DDS Routing Service pro-
vides both XSD (XML Schema Definition) [26] and DTD (Document Type Definition) [14]
schemas.
The final product should include a “Quick Start Guide” and an “User’s Guide”
DDS on the WAN: The DDS Routing Service
22
The final product should include some example XML configuration files.
The system would be controlled through the command console.
Operations
The system requires that the user provides certain configuration parameters at service
start up. Once the system is started, it is self-sufficient.
Performance
The system has to route and transforms the samples introducing the minimum possible
delay.
Support
During the development process UML will be used.
The system has to allow the inclusion of new modular elements (e.g. remote configura-
tion).
Packaging
The developed system must not require installation.
The system will require to have RTI Data Distribution Service 4.4d installed in the host
system.
2.3 Conclusions In this chapter we have identified both the functional and non-functional requirements for the
proposed DDS Routing Service. Firstly, we have studied each of the modules which constitute
the system. After that, we have identified the functional requirements for each subsystem
adopting the use case modeling approach. Finally, we have defined the non-functional require-
ments for the DDS Routing Service. In the next chapter we will focus on the system design that
should fulfills all the identified requirements.
23
Chapter 3. Design
This chapter contains the major contribution of our work. It consists of the design for the DDS
Routing Service. Our proposal will enable Data Distribution Service to communicate different
domains and Topics, transforming the data if necessary.
In the context of a WAN, the DDS Routing Service provides a spatial decoupling between DDS
entities. This is a key feature for the deployment of DDS systems, since it enables DDS entities to
communicate through the WAN in a transparent manner. In this way, a pair of DDS Routing Ser-
vice servers can establish a secure tunnel or apply NAT traversal techniques between two re-
mote LANs without requiring any modifications to the existing DDS applications.
This chapter is organized as follows. In section 3.1 the basic concepts of DDS Routing Service are
introduced. Section 3.2 contains the package and the class diagrams of the system. Finally, Sec-
tion 3.3 studies the main use cases of the DDS Routing Service by means of sequence diagrams.
3.1 Basic Concepts of DDS Routing Service The DDS Routing Service, as we mentioned in Chapter 1, aims to improve the DDS scalability. To
do that, the main goal of the service is to communicate different topics or/and domains in a
transparent manner. In addition, DDS Routing Service will also be able to perform external DLL
transformations.
The proposed DDS Routing Service includes the following concepts:
Discovery Thread and Waitset: These elements manage the discovery of DDS
entities in each interconnected domain. When a change in the discovery information oc-
curs, the Discovery Waitset notifies the Discovery Thread. The mission of
the Discovery Thread is to create DDS and DDS Routing Service entities according
to the service configuration. For more information about the concept of waitset, see
Chapter 4.
Domain Route: The service can contain one or more Domain Routes. Each Do-
main Route defines a mapping between two different Domain Participants by
means of several Topic Routes. A Domain Route contains two Participants
and one or more Sessions.
Session: Defines the execution unit for a Domain Route. A Session has asso-
ciated a read/write thread (from now, dataThread), a waitset (from now, da-
DDS on the WAN: The DDS Routing Service
24
taWaitset), one or more Publishers, one or more Subscribers, one or more
Topic Routes, and one or more Auto Topic Routes.
Topic Route: Represents a mapping between an input and an output Topic. The
type of the input and the output is defined using the DDS XML Description Type format.
Additionally, a Topic Route can have associated a QoS profile and a Transforma-
tion.
Auto Topic Route: Represents a generic Topic Route which is able to bridge
different Domain Participants. In this case, data are bridged between Topics
with the same name and data type, but associated to different Participants. An
Auto Topic Route can have associated a QoS profile and several Transforma-
tions.
Transformation Class Library: It defines a set of Transformation
Classes.
Transformation Class: This element specifies the kind of a data transformation.
It is loaded from an external DLL. In order to achieve that, this element should contain
the path to the DLL and the proper function names for performing data transformations.
Transformation: This is an instance of the Transformation class. It trans-
forms input data before publishing them to the output. In order to be able to process
data of any type, Transformations uses DDS Dynamic Topic Types (see Chapters 1
and 5). Any transformation needs an expression to describe it. Optionally, it could
include some additional parameters.
Content Filtered Topic: This is a Topic with associated filtering properties. It
makes it possible to subscribe to Topics with imposed conditions (filter). There-
fore, it provides to the application a subset of Topic data.
The defined Domain Route, Topic Route, and Auto Topic Route concepts are
shown in Figure 3.1. Similarly Session, dataThread, dataWaitset, and Transfor-
mation concepts are depicted in Figure 3.2. More precise definitions and explanations are
provided in following subsections (from 3.1.1 to 3.1.7).
Domain Route
Part
icip
an
t A
Partic
ipan
t B
Topic Route
Auto Topic Route
To
pic
A1
To
pic
B
To
pic
C T
op
ic C
To
pic B
T
op
ic A2
Figure 3.1: DDS Routing Service Entities: Domain Route, Topic Route, and
Auto Topic Route.
Chapter 3. Design
25
3.1.1 Domain Route
This element defines a mapping between two different Domain Participants and allows
configuring their associated QoS profiles.
A Domain Route is characterized by:
Name: It indentifies univocally the Domain Route.
Enabled: It establishes if the Domain Route is active.
Participant_1 and Participant_2: These elements identify and configure the
two Participants associated to the Domain Route. It is possible to assign a do-
main id and a QoS profile to each Participant.
Session: Defines the execution unit for a Domain Route. A Session has asso-
ciated a read/write dataThread, a dataWaitset, a Publisher, a Subscriber,
one or more Topic Routes, and one or more Auto Topic Routes.
3.1.2 Session
A Session defines the execution unit for a Domain Route. It routes data through the de-
fined Topic Routes and Auto Topic Routes. A Session has associated a dataTh-
read, a dataWaitset, one or more Publishers, one or more Subscribers, one or
more Topic Routes, and one or more Auto Topic Routes. A Session is characterized
by:
Name: It indentifies univocally the Session.
dataThread: This associated thread takes the received data from a Subscriber,
executes the transformations (if any), and puts the results in the corresponding Pub-
lisher. dataThread is the main element of a Session because of it controls how
data are mapped from the input Topic to the output Topic. In order to configure its
behavior, the following dataThread properties should set:
Domain Route
Part
icip
an
t A
Partic
ipan
t B
Session
data-
Waitset
Tran
sfo
rmat
ion
Su
bsc
rib
er
A
Part
icip
an
t B
Su
bsc
rib
er
B P
artic
ipan
t A
Pu
blis
he
r B
Pu
blis
he
r A
dat
aTh
read
Figure 3.2: DDS Routing Service Entities: Domain Route, Session, dataTh-
read, and dataWaitset.
DDS on the WAN: The DDS Routing Service
26
priority: It sets the priority of the thread. Possible defined values for this
property are THREAD_PRIORITY_DEFAULT,
THREAD_PRIORITY_BELOW_NORMAL, THREAD_PRIORITY_LOW,
THREAD_PRIORITY_NORMAL, THREAD_PRIORITY_ABOVE_NORMAL,
THREAD_PRIORITY_HIGH. Alternatively, it can be set equal to any integer
value.
mask: It describes the type of thread. Possible values are STDIO, FLOAT-
ING_POINT, REALTIME_PRIORITY and PRIORITY_ENFORCE. This prop-
erty can be multi valued, that is, the thread can have more than one type.
stack_size: This integer value defines the thread stack size.
dataWaitset: This element makes the thread to wait until DDS has received new
data or alternatively until a user-specified timeout expires. Data Distribution Service [1]
defines conditions and waitsets to provide another way for communicating
changes in the status of DDS entities. While a Listener is used to provide a callback
for asynchronous access, conditions and waitsets provide synchronous data
access. In other words, Listeners are notification-based and conditions are wait-
based.. As waitset, the dataWaitset is characterized by:
max_event_count: Maximum number of trigger events to cause the wait-
set to wake up.
max_event_delay: Maximum delay since the first trigger event to cause a
waitset to wake up.
condition: The condition that will wake up the waitset. Waitset con-
ditions can be classified in three different families: Guard, Status or
Read.
Topic Routes and Auto Topic Routes: These elements define how data are
mapped between Topics.
3.1.3 Topic Route
This element represents a mapping between an input and an output Topic. A Topic Route
allows configuring the QoS profiles associated to those Topics and performing certain trans-
formations or data filtering. A Topic Route is characterized by:
Name: It indentifies univocally the Topic Route.
Enabled: It establishes if the Topic Route is active.
Publish with original info property: This property defines whether the
data published by the Topic Route will be published with the information of its orig-
inal DataWriter (default value is false).
Propagate dispose: If activated, when an instance is disposed on the source do-
main, it will be accordingly disposed on the destination (it is by default true).
Propagate unregister: If activated, when an instance is unregistered on the
source domain, it be will accordingly unregistered on the destination (default value is
true).
Input: This element is used to configure the input of a Topic Route. In particular, it
is possible to set the name of the input Topic, the DataReader QoS, the type of in-
Chapter 3. Design
27
put data and a content filtered topic as well. It is also possible to configure
the creation mode which is used to define when the input of this Topic Route
(the DataReader) will be created. Possible creation mode values are:
o IMMEDIATE: The DataReader will be created immediately as soon as the
type code is available.
o ON_DOMAIN_MATCH: The DataReader will not be created until a corres-
ponding DataWriter on its domain is present.
o ON_ROUTE_MATCH: The DataReader is not created until the output (Data-
Writer) of the route had been created.
o ON_DOMAIN_OR_ROUTE_MATCH: The DataReader is not created until ei-
ther a corresponding DataWriter on its domain will be present or until the
output of the route had been created.
o ON_DOMAIN_AND_ROUTE_MATCH: The DataReader is not created until
both a corresponding DataWriter on its domain will present and the output
of the route had been created.
Output: This element is used to configure the output of a Topic Route. It is possi-
ble to set the name of the output Topic, the DataWriter QoS and the type of out-
put data. As in the Input element, it is possible to define the creation mode. The
creation mode possible values for Output elements are the same as the previously
defined for Input elements.
Transformation: This element will be described in Section 3.1.7.
On a separate note, regarding implementation observe that a Topic Route involves two
different Topics: one for receiving data and another one for sending data. Therefore, a Topic
Route has a DataWriter and a DataReader associated to the input and output Topics.
3.1.4 Auto Topic Route
Auto Topic Route makes it possible to easily configure the communication between two
different domains. When data are bridged, the input and output Topics must have the same
name and the same data-type. An Auto Topic Route is characterized by:
Name: It indentifies univocally the Auto Topic Route.
Enabled: It establishes if the Auto Topic Route is active.
Publish with original info property: This property defines whether the
data published by the Auto Topic Route will be published with the information of
its original DataWriter (default value is false).
Propagate dispose: If activated, when an instance is disposed on the source do-
main, it will be accordingly disposed on the destination (it is by default true).
Propagate unregister: If activated, when an instance is unregistered on the
source domain, it be will accordingly unregistered on the destination (default value is
true).
Input: It is associated to one of the Domain Route Participants and is used to
configure which data types and Topics are bridged to the output. It is possible to con-
figure the rules for Topic matching, a content filtered topic, the Data-
DDS on the WAN: The DDS Routing Service
28
Reader QoS and the creation mode (possible values are the same as for Topic
Route input values, defined in Section 3.1.3).
Output: This element is used to configure which data types and Topics are discov-
ered in the output. It is possible to configure the rules for Topic matching, a content
filtered topic, the DataWriter QoS and the creation mode (possible val-
ues have been defined in Section 3.1.3).
Transformation: This element will be described in Section 3.1.7.
Finally, regarding implementation observe that an Auto Topic Route involves only one
Topic, but two domains: one for receiving data and another one for sending data. Therefore, a
Auto Topic Route has a DataWriter and a DataReader associated to the input and
output Domain Participants.
3.1.5 Content Filtered Topic
A Content Filtered Topic is a Topic with associated filtering properties. It makes it
possible to subscribe to Topics and to specify the interest in just a subset of the Topic data.
A Content Filtered Topic is characterized by:
expression: It defines the filter.
parameter: This set configures the filter behavior.
3.1.6 Transformation Class
This element states the data transformation nature. It must define a path to the DLL which con-
tains the transforming functions as well as the names of those functions. A Transformation
class element is characterized by:
dll: Path to the transforming DLL.
load_function: Function that loads the transformation class. This function is called
when the DDS Routing Service parses the transformation_class element.
unload_function: Function that unload the transformation class. This function is
called when the DDS Routing Service ends.
create_transformation_function: This function is called when the DDS Routing
Service parses the transformation element (defined in Section 3.1.7) and creates an
instance with the given parameters.
transform_function: This function performs the transformation, and it is called af-
ter create_transformation_function.
modify_function: This function modifies the transformation, and it is called after
create_transformation_function.
delete_transformation_function: This function is called when a route is de-
leted. It removes the associated Transformation instance.
3.1.7 Transformation
This element is an instance of a Transformation Class. It transforms the input data be-
fore publishing them to the output by means of DDS Dynamic Topic Types. To perform a trans-
formation, an expression which describes the desired transformation must be provided. Option-
ally, it supports some transformation parameters. A Transformation is characterized by:
Chapter 3. Design
29
expression: It holds the expression to evaluate and defines the transformation to be
done.
parameter: This set defines the transformation behavior.
input_type_name: Identification of the input data to be transformed.
output_type_name: Identification of the transformed output data.
3.2 Package and Class Diagrams In this section the overall system architecture is described. For the sake of flexibility and mod-
ularity, the DDS Routing Service has been divided in five packages with different functionality:
serviceApp: This package is entry point of the DDS Routing Service and allows the
User to interact with the service.
service: This package is the core of the system, and contains all the classes that are
required for providing the service.
config: This package groups all the classes related to the configuration of the DDS
Routing Service.
test: One of the non-functional requirements of the system (see Chapter 2) was the
implementation of a set of unit tests for checking if the service works properly. All those
tests are contained in this package.
DDS: This package represents the DDS middleware, which is used for accessing to DDS
data-spaces and for interacting with OS API.
Figure 3.3 includes the package diagram corresponding to the previously described packages. In
the following subsections (from 3.2.1 to 3.2.4), we will explain the class diagrams associated to
each one of designed packages.
serviceApp
service
config
DDS
test
Figure 3.3: Package diagram for the RTI DDS Routing Service.
DDS on the WAN: The DDS Routing Service
30
3.2.1 serviceApp Package
The serviceApp package constitutes the entry point of the system and is the responsible for
starting or stopping the DDS Routing Service according to the user’s requests. serviceApp
contains only one class (Figure 3.4) which is detailed below.
ROUTERMain: This class is the entry point of the system. ROUTERMain allows the user
to start the service. It uses a set of provided parameters. ROUTERMain can also stop
the service through a system stop signal. Additionally, ROUTERMain can load an XML
configuration file with the DDS Routing Service configuration parameters.
+setSignalHandler(in sig : int, inout ROUTERMain_sigHandler) : int
+getCommandLineParameters(in argc : int, in argv : char) : ROUTERServiceProperty
+main(in argc : int, in argv : char) : int
ROUTERMain
Figure 3.4: Class diagram for the serviceApp package.
3.2.2 service Package
The service package constitutes the core of the designed system. It provides the routing be-
tween different Topics and Domains. This package contains all the classes that are necessary
for discovering new DDS entities and for transforming and routing data. For the sake of simplici-
ty, the service package class diagram depicted in Figure 3.5 only contains class and data
member names.
In following paragraphs the service package classes are detailed.
ROUTERService
ROUTERService (Figure 3.6) creates (and destroys) all the necessary entities for providing the
DDS Routing Service. It is the main class of the service package. This class also contains dis-
coveryThread associated to the discoveryWaitset. This thread manages the DDS dis-
covery according to the service configuration. When an expected DDS entity is discovered, the
discoveryThread requests ROUTERDomainRoute to create the DDS elements that are
necessary to route the information the discovered entity will later generate.
ROUTERDomainRoute
ROUTERDomainRoute class (Figure 3.7) stands for a route between two different Partici-
pants. It is responsible for the creation of both Participants and its associated Ses-
sion. When discoveryThread notifies this class about changes in discovery information,
ROUTERDomainRoute will create or remove the necessary entities associated to the two ex-
isting ROUTERDomainRouteParticipants.
Chapter 3. Design
31
«uses»
«uses»
«uses» «uses»
«uses»
«uses»
«uses»
«uses»
-_node
-_autoTopicRouteCfg
-_session
+topicRouteCounter
+topicRouteListDescInit
+topicRouteListInit
+topicRouteListDesc
+topicRouteList
ROUTERAutoTopicRoute
+participantKey
+instance_handle
+topic
ROUTERDiscoveredEntity
-_ownsTypeInfo
+topicName
+registeredTypeName
+type
+entityCount
ROUTERDiscoveredTopic
-_node
-_domainRouteCfg
-_sessionList
-_transfManager
+participant1
+participant2
+started
ROUTERDomainRoute
-_pubTopicList
-_subTopicList
-_dataWriterList
-_dataReaderList
-_typeList
-_topicListDesc
-_topicListDescInit
-_pubTopicListInit
-_subTopicListInit
-_dataWriterListInit
-_dataReaderListInit
-_typeListInit
+ddsParticipant
+ddsPubBuiltinReader
+ddsSubBuiltinReader
+ddsParBuiltinReader
+pubStatusCond
+subStatusCond
+parStatusCond
ROUTERDomainRouteParticipant
-_status
-_domainRouteList
-_discoveryWaitset
-_threadId
-_exitCondition
+serviceCfg
+transfManager
+property
ROUTERService
+cfgFile
+serviceName
+srvVerbosity
+ddsVerbosity
+domainIdBase
+executablePath
+transformationSearchPath
ROUTERServiceProperty
-_node
-_sessionCfg
-_status
-_transfManager
-topicRouteList
-autoTopicRouteList
-_dataWaitSet
-_threadId
-_exitCondition
+participant1
+participant2
+publisher1
+publisher2
+subscriber1
+subscriber2
ROUTERSession
-_node
-_topicRouteCfg
-_transfManager
-_subscriber
-_publisher
-_gotReaderType
-_gotWriterType
-_xmlReaderTopicInfo
-_xmlWriterTopicInfo
-_tmpKeyHolder
-_status
+statusCond
+reader
+writer
+transformationsEnabled
+transformationsReady
+inputWriterMatch
+outputReaderMatch
+started
ROUTERTopicRoute
+enabled
+inputCreated
+outputCreated
+inputTypeAvailable
+outputTypeAvailable
+inputMatchingPublication
+outputMatchingSubscription
+transformationsReady
ROUTERTopicRouteStatus
-_parser
-_transformationClassList
-_transformationClassListInit
-_transformationClassListDesc
-_transformationClassListDescInit
ROUTERTransformClassMngr
-_node
-_transformationCfg
-_userData
+transformationClass
+inputTypeCode
+outputTypeCode
+outputsample
ROUTERTransformation
-_transformationClassCfg
-_libhandle
+fullName
+path
+userData
+lazyLoad
+loadFnc
+unloadFnc
+createFnc
+deleteFnc
+modifyFnc
+transformFnc
ROUTERTransformationClass
+typeName
+typeSupport
+typeCode
ROUTERTypeInfo
«uses» «uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
Figure 3.5: Class diagram for the service package.
DDS on the WAN: The DDS Routing Service
32
+takeMutex() : bool
+giveMutex() : bool
+discoveryRun(in threadParam : void *) : void *
+deleteDomainRoute(in domainRoute : ROUTERDomainRoute) : bool
+stopDomainRoute(inout domainRoute : ROUTERDomainRoute) : bool
+startDomainRoute(inout domainRoute : ROUTERDomainRoute) : bool
+createDomainRoute(in domainRouteCfg : ROUTERCfgFileDomainRoute) : ROUTERDomainRoute
+stop() : bool
+start() : bool
+finalize() : bool
+delete() : void
+initialize(in property : ROUTERServiceProperty) : bool
+new(in property : ROUTERServiceProperty) : ROUTERService
-_status : ROUTERServiceStatus
-_domainRouteList : REDA_InlineList
-_discoveryWaitset : DDS_Waitset
-_threadId : RTIOsapiThread
-_exitCondition : DDS_GuardCondition
+serviceCfg : ROUTERCfgFileService
+transfManager : ROUTERTransformClassMngr
+property : ROUTERServiceProperty
ROUTERService
Figure 3.6: ROUTERService class diagram.
+onPublicationDiscovered(in participant : DDS_DomainParticipant, in pubData : DDS_PublicationBuiltinTopicData, in info : DDS_SampleInfo) : bool
+onSubscriptionDiscovered(in participant : DDS_DomainParticipant, in subData : DDS_SubscriptionBuiltinTopicData, in info : DDS_SampleInfo) : bool
+deleteDiscoveredTopic(in drParticipant : ROUTERDomainRouteParticipant, in topic : ROUTERDiscoveredTopic, in isPublication : bool) : void
+onPublicationDisposed(in participant : DDS_DomainParticipant, in info : DDS_SampleInfo) : bool
+onSubscriptionDisposed(in participant : DDS_DomainParticipant, in info : DDS_SampleInfo) : bool
+onParticipantDiscovered(in participant : DDS_DomainParticipant, in parData : DDS_ParticipantBuiltinTopicData, in info : DDS_SampleInfo) : bool
+onParticipantUnregistered(in participant : DDS_DomainParticipant, in participantKey : DDS_BuiltinTopicKey_t, in info : DDS_SampleInfo) : bool
+createSession(in sessionCfg : ROUTERCfgFileSession) : ROUTERSession
+startSessions() : bool
+notifyStopSessions() : bool
+stopSessions() : bool
+deleteSession(in session : ROUTERSession) : bool
+deleteSessions() : void
+stop() : bool
+finalize() : void
+delete() : void
+initialize(in cfg : ROUTERCfgFileDomainRoute, in thisRouterGroupName : char *, in tcm : ROUTERTransformClassMngr) : bool
+start() : bool
+new(in cfg : ROUTERCfgFileDomainRoute, in routerGroupName : char *, in tcm : ROUTERTransformClassMngr) : ROUTERDomainRoute
-_node : REDAInlineListNode
-_domainRouteCfg : ROUTERCfgFileDomainRoute
-_sessionList : REDA_InlineList
-_transfManager : ROUTERTransformClassMngr
+participant1 : ROUTERDomainRouteParticipant
+participant2 : ROUTERDomainRouteParticipant
+started : bool
ROUTERDomainRoute
Figure 3.7: ROUTERDomainRoute class diagram.
ROUTERDomainRouteParticipant
ROUTERDomainRouteParticipant class (Figure 3.8) represents one of the two Par-
ticipants associated to a DomainRoute. Through this class the system is able to assert or
remove DDS entities to the Participant. In addition, this class exposes the necessary func-
tions to check if a Topic is already registered in the Participant.
Chapter 3. Design
33
+lookupDiscoveredTopic(in lst : REDASkiplist, in typeName : char *, in topicName : char *) : ROUTERDiscoveredTopic
+lookupDiscoveredPubTopic(in typeName : char *, in topicName : char *) : ROUTERDiscoveredTopic
+lookupDiscoveredSubTopic(in typeName : char *, in topicName : char *) : ROUTERDiscoveredTopic
+removeDiscoveredEntity(out outRemovedTopic : ROUTERDiscoveredTopic, inout lst : REDASkiplist, inout entityLst : REDASkiplist, in entity_handle :
DDS_InstanceHandle_t) : bool
+removeDiscoveredPublication(out outRemovedTopic : ROUTERDiscoveredTopic, in writer_handle : DDS_InstanceHandle_t) : bool
+removeDiscoveredSubscription(out outRemovedTopic : ROUTERDiscoveredTopic, in reader_handle : DDS_InstanceHandle_t) : bool
+assertDiscoveredEntity(inout topicAlreadyExists : bool *, inout topicList : REDASkiplist, inout entityList : REDASkiplist, in topicName : char, in registeredTypeName :
char, in typeCode : DDS_TypeCode, in entity_handle : DDS_InstanceHandle_t, in participantKey : DDS_BuiltinTopicKey_t) : ROUTERDiscoveredTopic
+assertDiscoveredPublication(inout topicAlreadyExists : bool, inout topicList : REDASkiplist, inout entityList : REDASkiplist, in topicName : char *, in
registeredTypeName : char *, in typeCode : DDS_TypeCode, in entity_handle : DDS_InstanceHandle_t, in participantKey : DDS_BuiltinTopicKey_t) :
ROUTERDiscoveredTopic
+assertDiscoveredSubscription(inout topicAlreadyExists : bool *, in topicName : char *, in registeredTypeName : char *, in typecode : DDS_TypeCode, in
reader_handle : DDS_InstanceHandle_t, in participantKey : DDS_BuiltinTopicKey_t) : ROUTERDiscoveredTopic
+enableDDSParticipant() : bool
+finalize() : bool
+initialize(in domainId : int, in participantQoS : DDS_DomainParticipantQos) : bool
+NOTHING()
+NOTHING()
-_pubTopicList : REDASkiplist
-_subTopicList : REDASkiplist
-_dataWriterList : REDASkiplist
-_dataReaderList : REDASkiplist
-_typeList : REDASkiplist
-_topicListDesc : REDASkiplistDescription
-_topicListDescInit : bool
-_pubTopicListInit : bool
-_subTopicListInit : bool
-_dataWriterListInit : bool
-_dataReaderListInit : bool
-_typeListInit : bool
+ddsParticipant : DDS_DomainParticipant
+ddsPubBuiltinReader : DDS_DataReader
+ddsSubBuiltinReader : DDS_DataReader
+ddsParBuiltinReader : DDS_DataReader
+pubStatusCond : DDS_StatusCondition
+subStatusCond : DDS_StatusCondition
+parStatusCond : DDS_StatusCondition
ROUTERDomainRouteParticipant
Figure 3.8: ROUTERDomainRouteParticipant class diagram.
+startTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+associateTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+addTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+addAutoTopicRoute(in topicRoute : ROUTERAutoTopicRoute) : bool
+stopTopicRouteI(in topicRoute : ROUTERTopicRoute, in deleteReader : bool, in deleteWriter : bool, in needsSync : bool) : bool
+attemptStopTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+run(in threadParam : void *) : void *
+notifyStop() : bool
+stop() : bool
+start() : bool
+deleteTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+deleteAutoTopicRoute(in topicRoute : ROUTERAutoTopicRoute) : bool
+createTopicRoute(in topicRouteCfg : ROUTERCfgFileTopicRoute) : ROUTERTopicRoute
+createAutoTopicRoute(in autoTopicRouteCfg : ROUTERCfgFileAutoTopicRoute) : ROUTERAutoTopicRoute
+finalize() : bool
+delete() : void
+initialize(in cfg : ROUTERCfgFileSession, in participant1 : DDS_DomainParticipant, in participant2 : DDS_DomainParticipant, in
tcm : ROUTERTransformClassMngr) : bool
+new(in cfg : ROUTERCfgFileSession, in participant1 : DDS_DomainParticipant, in participant2 : DDS_DomainParticipant, in tcm
: ROUTERTransformClassMngr) : ROUTERSession
+NOTHING()
+NOTHING()
-_node : REDAInlineListNode
-_sessionCfg : ROUTERCfgFileSession
-_status : ROUTERSessionStatus
-_transfManager : ROUTERTransformClassMngr
-topicRouteList : REDAInlineList
-autoTopicRouteList : REDAInlineList
-_dataWaitSet : DDS_Waitset
-_threadId : RTIOsapiThread
-_exitCondition : DDS_GuardCondition
-_safeToStopTopicRouteFlag : bool
-_waitingToStopTopicRouteFlag : bool
+participant1 : DDS_DomainParticipant
+participant2 : DDS_DomainParticipant
+publisher1 : DDS_Publisher
+publisher2 : DDS_Publisher
+subscriber1 : DDS_Subscriber
+subscriber2 : DDS_Subscriber
ROUTERSession
Figure 3.9: ROUTERSession class diagram.
DDS on the WAN: The DDS Routing Service
34
ROUTERSession
ROUTERSession class (Figure 3.9) contains all the Topic Routes and Auto Topic
Routes that are currently associated to a ROUTERDomainRoute. The main purpose of this
class is to take the data received in a Participant and to route them through the proper
(Auto) Topic Route. In order to perform this task, ROUTERSession has a dataThread
and a dataWaitset, which are the responsible for processing the data using the proper (Au-
to) Topic Route.
ROUTERTopicRoute
ROUTERTopicRoute class (Figure 3.10) takes the data delivered by the ROUTERSession, it
applies the proper transformations (if any) and publishes the resulting data to the output Top-
ic. ROUTERTopicRoute is responsible for a DataWriter and a DataReader for publish-
ing and receiving data.
ROUTERAutoTopicRoute
ROUTERAutoTopicRoute class (Figure 3.11) is a particularization of ROUTERTopicRoute.
It is used to route data between Topics with the same TypeInfo but associated to different
Participants.
ROUTERDiscoveredEntity
ROUTERDiscoveredEntity class (Figure 3.12) is used to store information about a discov-
ered DataWriter or DataReader. The information stored consists of the
DDS_BuiltinTopicKey_t, the DDS_InstanceHandle_t and, the ROUTERDiscove-
redTopic.
ROUTERDiscoveredTopic
ROUTERDiscoveredTopic class (Figure 3.13) is used to store information about discovered
Topics. Specifically, this class is prepared to store the Topic name, the Registered Type
name and the associated ROUTERTypeInfo.
Chapter 3. Design
35
+deleteDataReader() : bool
+createDataReader() : bool
+createDataWriter() : bool
+deleteDataWriter() : bool
+isReadyToCreateWriter(in supposeReaderIsReady : bool) : bool
+isReadyToCreateReader() : bool
+needToDeleteWriter(in supposeReaderIsDeleted : bool) : bool
+needToDeleteReader() : bool
+giveType(in info : ROUTERDiscoveredTopic, in srcParticipant : int) : bool
+setSubAndPub(in subscriber : DDS_Subscriber, in publisher : DDS_Publisher) : bool
+getSourceParticipant() : int
+isPublicationStarted() : bool
+isSubscriptionStarted() : bool
+isStarted() : bool
+setStarted(in started : bool) : void
+isReady() : bool
+route(in dataSeq : DDS_DynamicDataSeq, in infoSeq : DDS_SampleInfoSeq) : bool
+getSession() : ROUTERSession
+onPubTopicDiscovered(in topic : ROUTERDiscoveredTopic, in srcParticipantIndex : int) : bool
+onSubTopicDiscovered(in topic : ROUTERDiscoveredTopic, in srcParticipantIndex : int) : bool
+onPubTopicNotAlive(in topic : ROUTERDiscoveredTopic, in srcParticipantIndex : int) : bool
+onSubTopicNotAlive(in topic : ROUTERDiscoveredTopic, in srcParticipantIndex : int) : bool
+finalize() : bool
+delete() : void
+initialize(in cfg : ROUTERCfgFileTopicRoute, in tcm : ROUTERTransformClassMngr) : bool
+new(in cfg : ROUTERCfgFileTopicRoute, in tcm : ROUTERTransformClassMngr) : ROUTERTopicRoute
-_node : REDAInlineListNode
-_topicRouteCfg : ROUTERCfgFileTopicRoute
-_transfManager : ROUTERTransformClassMngr
-_subscriber : DDS_Subscriber
-_publisher : DDS_Publisher
-_gotReaderType : bool
-_gotWriterType : bool
-_xmlReaderTopicInfo : ROUTERDiscoveredTopic
-_xmlWriterTopicInfo : ROUTERDiscoveredTopic
-_tmpKeyHolder : DDS_DynamicData *
-_status : ROUTERTopicRouteStatus
+statusCond : DDS_StatusCondition
+reader : DDS_DataReader
+writer : DDS_DataWriter
+transformationsEnabled : bool
+transformationsReady : bool
+inputWriterMatch : bool
+outputReaderMatch : bool
+started : bool
ROUTERTopicRoute
Figure 3.10: ROUTERTopicRoute class diagram.
+removeTopicRoute(in topicRoute : ROUTERTopicRoute) : bool
+getSourceParticipant() : int
+createTopicRoute() : ROUTERTopicRoute
+matchTopic(in topic : ROUTERDiscoveredTopic, in comesFromInput : bool) : ROUTERTopicRoute
+compareTopicRoute(in left : void *, in right : void *) : int
+finalize() : bool
+initialize(in cfg : ROUTERCfgFileAutoTopicRoute) : bool
+getSession() : ROUTERSession
+delete() : void
+new(in cfg : ROUTERCfgFileAutoTopicRoute) : ROUTERAutoTopicRoute
-_node : REDAInlineListNode
-_autoTopicRouteCfg : ROUTERCfgFileAutoTopicRoute
-_session : ROUTERSession
+topicRouteCounter : int
+topicRouteListDescInit : bool
+topicRouteListInit : bool
+topicRouteListDesc : REDASkiplistDescription
+topicRouteList : REDASkiplist
ROUTERAutoTopicRoute
Figure 3.11: ROUTERAutoTopicRoute class diagram.
DDS on the WAN: The DDS Routing Service
36
+compare(in left : void *, in right : void *) : int
+finalize() : bool
+delete() : void
+initialize(in participantKey : DDS_BuiltinTopicKey_t, in handle : DDS_InstanceHandle_t, in topic : ROUTERDiscoveredTopic) : bool
+new(in participantKey : DDS_BuiltinTopicKey_t, in handle : DDS_InstanceHandle_t, in topic : ROUTERDiscoveredTopic) : ROUTERDiscoveredEntity
+participantKey : DDS_BuiltinTopicKey_t
+instance_handle : DDS_InstanceHandle_t
+topic : ROUTERDiscoveredTopic
ROUTERDiscoveredEntity
Figure 3.12: ROUTERDiscoveredEntity class diagram.
+compare(in left : void *, in right : void *) : int
+finalize() : bool
+delete() : void
+initialize(in topicName : char *, in registeredTypeName : char *, in type : ROUTERTypeInfo) : bool
+new(in topicName : char *, in registeredTypeName : char *, in type : ROUTERTypeInfo) : ROUTERDiscoveredTopic
+new_w_typeCode(in registeredTypeName : char *, in typeCode : DDS_TypeCode) : ROUTERDiscoveredTopic
-_ownsTypeInfo : bool
+topicName : char *
+registeredTypeName : char *
+type : ROUTERTypeInfo
+entityCount : int
ROUTERDiscoveredTopic
Figure 3.13: ROUTERDiscoveredTopic class diagram.
+compare(in left : void *, in right : void *) : int
+finalize() : bool
+delete() : void
+initialize(in typeCode : DDS_TypeCode) : bool
+new(in typeCode : DDS_TypeCode) : ROUTERTypeInfo
+typeName : char
+typeSupport : DDS_DynamicDataTypeSupport
+typeCode : DDS_TypeCode
ROUTERTypeInfo
Figure 3.14: ROUTERDiscoveredTypeInfo class diagram.
ROUTERTypeInfo
The purpose of this class (Figure 3.14) is to store information about a Type. This class store in-
formation about the Type name, the DDS_DynamicDataTypeSupport and the
DDS_TypeCode.
ROUTERTransformationClassManager
ROUTERTransformationClassManager (Figure 3.15) is a container of ROUTERTrans-
formationClass.
ROUTERTransformationClass
ROUTERTransformationClass (Figure 3.16) represents a family of Transformations.
It loads a shared library with the functions needed by all the Transformations that belong
to this class.
ROUTERTransformation
ROUTERTransformation (Figure 3.17) represents a Transformation belonging to a
ROUTERTransformationClass family and with specific configuration parameters.
Chapter 3. Design
37
+lookup(in name : char *) : ROUTERTransformationClass
+finalize() : bool
+initialize(in parser : ROUTERCfgFileParser, in pathToDll : char *) : bool
+delete() : void
+new(in parser : ROUTERCfgFileParser, in pathToDll : char *) : ROUTERTransformClassMngr
-_parser : ROUTERCfgFileParser
-_transformationClassList : REDASkiplist
-_transformationClassListInit : bool
-_transformationClassListDesc : REDASkiplistDescription
-_transformationClassListDescInit : bool
ROUTERTransformClassMngr
Figure 3.15: ROUTERTransformationClassManager class diagram.
+load() : bool
+createInstance() : void *
+deleteInstance(in instance : void *) : DDS_ReturnCode_t
+finalize() : bool
+getDllPath(in pathToDll : char *, in pathInCfgFile : char *) : char *
+initialize(in cfg : ROUTERCfgFileTransformationClass, in fullName : char, in pathToDll : char) : bool
+delete() : void
+new(in cfg : ROUTERTransformationClass, in fullName : char *, in pathToDll : char *) : ROUTERTransformationClass
+compare(in left : void *, in right : void *) : int
-_transformationClassCfg : ROUTERCfgFileTransformationClass
-_libhandle : void *
+fullName : char *
+path : char *
+userData : void *
+lazyLoad : bool
+loadFnc : RTITransformationClass_loadFnc
+unloadFnc : RTITransformationClass_unloadFnc
+createFnc : RTITransformationClass_createFnc
+deleteFnc : RTITransformationClass_deleteFnc
+modifyFnc : RTITransformationClass_modifyFnc
+transformFnc : RTITransformationClass_transformFnc
ROUTERTransformationClass
Figure 3.16: ROUTERTransformationClass class diagram.
+transform(in action : RTITransformationAction, in input : DDS_DynamicData, in inputInfo : DDS_SampleInfo) : DDS_ReturnCode_t
+setInputTypeCode(in typeCode : DDS_TypeCode) : DDS_ReturnCode_t
+setOutputTypeCode(in typeCode : DDS_TypeCode) : DDS_ReturnCode_t
+finalize() : bool
+initialize(in cfg : ROUTERCfgFileTransformation, in transfClass : ROUTERTransformationClass) : bool
+delete() : void
+new(in cfg : ROUTERCfgFileTransformation, in transfClass : ROUTERTransformationClass) : ROUTERTransformation
-_node : REDAInlineListNode
-_transformationCfg : ROUTERCfgFileTransformation
-_userData : void *
+transformationClass : ROUTERTransformationClass
+inputTypeCode : DDS_TypeCode
+outputTypeCode : DDS_TypeCode
+outputsample : DDS_DynamicData *
ROUTERTransformation
Figure 3.17: ROUTERTransformation class diagram.
3.2.3 config Package
The package config has two different purposes. Firstly, it has to obtain the service configura-
tion from a valid XML file. The second objective of config package is to process the configura-
tion parameters that the user introduces during the service startup: this functionality is carried
out by ROUTERParameterManager class. A simplified class diagram (it only contains class
and data member names) is showed in Figure 3.18.
DDS on the WAN: The DDS Routing Service
38
«uses»
«uses»«uses»
«uses»
«uses»
«uses»
«uses»
«uses»«uses»
«uses»
«uses» «uses»
«uses»
-_init
-_xmlRoot
+parser
+routerService
+domainIdBase
ROUTERCfgFileParser
+base
+name
+groupName
+enabled
+guid
ROUTERCfgFileService
+base
+name
+fullName
+enabled
+inputParticipantQos
+outputParticipantQos
+inputParticipantQosIsDefault
+inputXmlParticipantQos
+outputXmlParticipantQos
+outputParticipantQosIsDefault
+inputDomainId
+outputDomainId
+domainIdBase
+inputRegisteredTypes
+outputRegisteredTypes
+parser
+object
ROUTERCfgFileDomainRoute
+base
+name
+enabled
+subscriberQos
+xmlSubscriberQos
+subscriberQosIsDefault
+publisherQos
+xmlPublisherQos
+publisherQosIsDefault
+thread
+wait_set
+waitSetTimeout
+parser
+object
ROUTERCfgFileSession
+base
+name
+enabled
+inputParticipant
+dataReaderQos
+xmlDataReaderQos
+dataReaderQosIsDefault
+contentFilter
+routeTypes
+publishWithOriginalInfo
+propagateDispose
+propagateUnregister
+inputCreationMode
+outputCreationMode
+inputTopicName
+outputTopicName
+inputTypeCode
+outputTypeCode
+inputTypeCodeName
+outputTypeCodeName
+inputRegisteredTypeName
+outputRegisteredTypeName
+dataWriterQos
+xmlDataWriterQos
+dataWriterQosIsDefault
+fullName
+loadedFromXML
+parser
+domainRoute
ROUTERCfgFileTopicRoute
+base
+name
+enabled
+inputParticipant
+dataReaderQos
+xmlDataReaderQos
+dataReaderQosIsDefault
+contentFilter
+publishWithOriginalInfo
+propagateDispose
+propagateUnregister
+inputAllowTopicNameFilter
+inputAllowTypeNameFilter
+outputAllowTopicNameFilter
+outputAllowTypeNameFilter
+inputDenyTopicNameFilter
+inputDenyTypeNameFilter
+outputDenyTopicNameFilter
+outputDenyTypeNameFilter
+dataWriterQos
+xmlDataWriterQos
+dataWriterQosIsDefault
+fullName
+inputCreationMode
+outputCreationMode
+parser
+object
ROUTERCfgFileAutoTopicRoute
+base
+name
ROUTERCfgFileTransformationClassLibrary
+base
+name
+dll
+loadFunction
+unloadFunction
+createTransformationFunction
+deleteTransformationFunction
+modifyTransformationFunction
+transformFunction
+inputTypeName
+outputTypeName
ROUTERCfgFileTransformationClass
-_init
-_parameterValues
ROUTERParameterManager
+base
+name
+enabled
ROUTERCfgFileTransformationSequence
+base
+name
+className
+enabled
+expression
+parameterSeq
+inputTypeName
+outputTypeName
+inputTypeCode
+outputTypeCode
ROUTERCfgFileTransformation
«uses»«uses»
«uses»
«uses» «uses»
«uses»
«uses»
Figure 3.18: Class diagram for the config package.
In following paragraphs the config package classes are detailed.
ROUTERCfgFileParser
ROUTERCfgFileParser (Figure 3.19) provides functions to parse the DDS Routing Service
XML configuration file. It uses the functions provided by ROUTERCfgFileService and ROU-
TERCfgFileTransformationClassLibrary classes.
Chapter 3. Design
39
+deleteObject(in objectName : char *) : bool
+changeServiceName(in service : ROUTERCfgFileService, in newName : char *) : bool
+loadService_ex(in result : ROUTERCfgFileService, in routerServiceName : char *, in root : DDS_XMLObject) : bool
+loadService(in routerServiceName : char *) : bool
+load_profiles_from_url_group(in newRoot : DDS_XMLObject , out fileExist : bool *, in xmlUrl : char *, in root : DDS_XMLObject, in
reportErrorIfFileDoesNotExist : bool) : DDS_ReturnCode_t
+load_profiles_from_url_list(in newRoot : DDS_XMLObject, in urlList : char *, in root : DDS_XMLObject) : DDS_ReturnCode_t
+loadStandardQosFiles(in root : DDS_XMLObject) : DDS_XMLObject
+loadHardCodedDefaultCfgFile(in root : DDS_XMLObject) : DDS_XMLObject
+loadDefaultCfgFile(in executablePath : char *, in root : DDS_XMLObject) : DDS_XMLObject
+parseXmlFile(in file : char *, in executablePath : char *, in incorporateToExistingDom : bool) : DDS_XMLObject
+parseXmlString(in xmlString : char *, in executablePath : char *, in incorporateToExistingDom : bool) : DDS_XMLObject
+loadCfgString(in routerServiceName : char *, in xmlString : char *, in executablePath : char *) : bool
+loadCfgFile(in routerServiceName : char, in fileName : char, in executablePath : char) : bool
+getFirstTransformationClassLibrary() : ROUTERCfgFileTransformationClassLibrary
+getNextTransformationClassLibrary(in transformationClassLibrary : ROUTERCfgFileTransformationClassLibrary) :
ROUTERCfgFileTransformationClassLibrary
+finalize() : void
+initialize(in domainIdBase : int) : bool
+delete() : void
+new(in domainIdBase : int) : ROUTERCfgFileParser
+NOTHING()
+NOTHING()
-_init : int
-_xmlRoot : DDS_XMLObject
+parser : DDS_XMLParser
+routerService : ROUTERCfgFileService
+domainIdBase : int
ROUTERCfgFileParser
Figure 3.19: ROUTERCfgFileParser class diagram.
ROUTERCfgFileService
ROUTERCfgFileService class (Figure 3.20) is used to parse “<routing_service>” XML
tag, which contains the configuration of the DDS Routing Service. This class is also used to access
to the service parameters and to its contained entities (Sessions, Auto Topic Routes,
Topic Routes, and Domain Routes).
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+getFirstDomainRoute() : ROUTERCfgFileDomainRoute
+getNextDomainRoute(in domainRoute : ROUTERCfgFileDomainRoute) : ROUTERCfgFileDomainRoute
+finalize() : void
+getDefaultServiceName(out output : char *, in maxLength : int) : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name :
char *, in groupName : char *, in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in
context : DDS_XMLContext) : DDS_XMLObject
+findAutoTopicRoute(in fullName : char *) : ROUTERCfgFileAutoTopicRoute
+findSession(in fullName : char *) : ROUTERCfgFileSession
+findDomainRoute(in fullName : char *) : ROUTERCfgFileDomainRoute
+findTopicRoute(in fullName : char *) : ROUTERCfgFileTopicRoute
+findEntity(in entityKind : ROUTEREntityKind_t, in fullName : char *) : DDS_XMLObject
+NOTHING()
+NOTHING()
+base : DDS_XMLObject
+name : char *
+groupName : char *
+enabled : bool
+guid : char[]
ROUTERCfgFileService
Figure 3.20: ROUTERCfgFileService class diagram.
ROUTERCfgFileDomainRoute
ROUTERCfgFileDomainRoute class (Figure 3.21) parses “<domain_route>” XML tag
and stores the information about a specific Domain Route, its associated entities (input and
output Participants and a Session), and its associated QoS policies. This class also pro-
vides a function to get a data Type that is registered in the Domain Route.
DDS on the WAN: The DDS Routing Service
40
+createDefaultQos(in participantId : int) : bool
+getQos(in inputTag : bool) : bool
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+setParticipantName(in qos : DDS_DomainParticipantQos, in participantId : char *) : bool
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+getFirstSession() : ROUTERCfgFileSession
+getNextSession(in session : ROUTERCfgFileSession) : ROUTERCfgFileSession
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext)
: DDS_XMLObject
+findRegisteredType(in domainParticipantIndex : int, in registeredType : char *) : ROUTERCfgFileRegisteredType
+NOTHING()
+base : DDS_XMLObject
+name : char *
+fullName : char *
+enabled : bool
+inputParticipantQos : DDS_DomainParticipantQos
+outputParticipantQos : DDS_DomainParticipantQos
+inputParticipantQosIsDefault : bool
+inputXmlParticipantQos : DDS_XMLParticipantQos
+outputXmlParticipantQos : DDS_XMLParticipantQos
+outputParticipantQosIsDefault : bool
+inputDomainId : int
+outputDomainId : int
+domainIdBase : int
+inputRegisteredTypes : ROUTERCfgFileRegisteredTypeSeq
+outputRegisteredTypes : ROUTERCfgFileRegisteredTypeSeq
+parser : ROUTERCfgFileParser
+object : void *
ROUTERCfgFileDomainRoute
Figure 3.21: ROUTERCfgFileDomainRoute class diagram.
ROUTERCfgFileSession
ROUTERCfgFileSession class (Figure 3.22) parses “<session>” XML tag. It stores the
information of a specific Session, all its associated entities (Publisher, Subscriber,
Thread, Waitset, Auto Topic Routes, and Topic Routes), and its associated QoS
policies.
+getQos() : bool
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+getFirstAutoTopicRoute() : ROUTERCfgFileAutoTopicRoute
+getNextAutoTopicRoute(in autoTopicRoute : ROUTERCfgFileAutoTopicRoute) : ROUTERCfgFileAutoTopicRoute
+getFirstTopicRoute() : ROUTERCfgFileTopicRoute
+getNextTopicRoute(in topicRoute : ROUTERCfgFileTopicRoute) : ROUTERCfgFileTopicRoute
+getDomainRoute() : ROUTERCfgFileDomainRoute
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext) :
DDS_XMLObject
+getQos() : bool
+______()
+base : DDS_XMLObject
+name : char
+enabled : bool
+subscriberQos : DDS_SubscriberQos
+xmlSubscriberQos : DDS_XMLSubscriberQos
+subscriberQosIsDefault : bool
+publisherQos : DDS_PublisherQos
+xmlPublisherQos : DDS_XMLPublisherQos
+publisherQosIsDefault : bool
+thread : DDS_ThreadSettings_t
+wait_set : DDS_WaitSetProperty_t
+waitSetTimeout : DDS_Duration_t
+parser : ROUTERCfgFileParser
+object : void *
ROUTERCfgFileSession
Figure 3.22: ROUTERCfgFileSession class diagram.
ROUTERCfgFileTopicRoute
ROUTERCfgFileTopicRoute class (Figure 3.23) parses “<topic_route>” XML tag. It
stores the information of a specific Topic Route, and all its associated entities and QoS poli-
cies. This class also provides functions for obtaining all the Transformations that are asso-
ciated to the Topic Route.
Chapter 3. Design
41
+getQos(in readerTag : bool) : bool
+getDomainRoute()
+getFromString() : ROUTERCfgFileDomainRoute
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+getFirstTransformation() : ROUTERCfgFileTransformation
+getNextTransformation(in transformation : ROUTERCfgFileTransformation) : ROUTERCfgFileTransformation
+getFirstTransformationSequence() : ROUTERCfgFileTransformationSequence
+getNextTransformationSequence(in transformationSequence : ROUTERCfgFileTransformationSequence) :
ROUTERCfgFileTransformationSequence
+getSession() : ROUTERCfgFileSession
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in enabled : bool, in context :
DDS_XMLContext) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext) :
DDS_XMLObject
+_____()
+_____()
+_____()
+base : DDS_XMLObject
+name : char *
+enabled : bool
+inputParticipant : int
+dataReaderQos : DDS_DataReaderQos
+xmlDataReaderQos : DDS_XMLDataReaderQos
+dataReaderQosIsDefault : bool
+contentFilter : ROUTERCfgFileTopicRouteContentFilter
+routeTypes : bool
+publishWithOriginalInfo : bool
+propagateDispose : bool
+propagateUnregister : bool
+inputCreationMode : ROUTERCfgFileRouteCreationMode
+outputCreationMode : ROUTERCfgFileRouteCreationMode
+inputTopicName : char *
+outputTopicName : char *
+inputTypeCode : DDS_TypeCode
+outputTypeCode : DDS_TypeCode
+inputTypeCodeName : char *
+outputTypeCodeName : char *
+inputRegisteredTypeName : char *
+outputRegisteredTypeName : char *
+dataWriterQos : DDS_DataWriterQos
+xmlDataWriterQos : DDS_XMLDataWriterQos
+dataWriterQosIsDefault : bool
+fullName : char *
+loadedFromXML : bool
+parser : ROUTERCfgFileParser
+domainRoute : ROUTERCfgFileDomainRoute
ROUTERCfgFileTopicRoute
Figure 3.23: ROUTERCfgFileTopicRoute class diagram.
ROUTERCfgFileAutoTopicRoute
ROUTERCfgFileAutoTopicRoute class (Figure 3.24) parses “<auto_topic_route>”
XML tag. It stores the information of a specific Auto Topic Route and all its associated enti-
ties and the QoS policies. Similarly to the ROUTERCfgFileTopicRoute, this class contains
the necessary functions to obtain the Transformations associated to the current Auto
Topic Route.
ROUTERCfgFileTransformationClassLibrary
ROUTERCfgFileTransformationClassLibrary class (Figure 3.25) parses the
“<transformation_class_library>” XML. It stores the information of a group of ROU-
TERCfgFileTransformationClass classes.
DDS on the WAN: The DDS Routing Service
42
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+getQos(in readerTag : bool) : bool
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : bool
+getFirstTransformation() : ROUTERCfgFileTransformation
+getNextTransformation(in transformation : ROUTERCfgFileTransformation) : ROUTERCfgFileTransformation
+getFirstTransformationSequence() : ROUTERCfgFileTransformationSequence
+getNextTransformationSequence(in transformationSequence : ROUTERCfgFileTransformationSequence) :
ROUTERCfgFileTransformationSequence
+getDomainRoute() : ROUTERCfgFileDomainRoute
+getSession() : ROUTERCfgFileSession
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext)
: DDS_XMLObject
+_______()
+_______()
+base : DDS_XMLObject
+name : char *
+enabled : bool
+inputParticipant : int
+dataReaderQos : DDS_DataReaderQos
+xmlDataReaderQos : DDS_XMLDataReaderQos
+dataReaderQosIsDefault : bool
+contentFilter : ROUTERCfgFileAutoTopicRouteContentFilter
+publishWithOriginalInfo : bool
+propagateDispose : bool
+propagateUnregister : bool
+inputAllowTopicNameFilter : char *
+inputAllowTypeNameFilter : char *
+outputAllowTopicNameFilter : char *
+outputAllowTypeNameFilter : char *
+inputDenyTopicNameFilter : char *
+inputDenyTypeNameFilter : char *
+outputDenyTopicNameFilter : char *
+outputDenyTypeNameFilter : char *
+dataWriterQos : DDS_DataWriterQos
+xmlDataWriterQos : DDS_XMLDataWriterQos
+dataWriterQosIsDefault : bool
+fullName : char *
+inputCreationMode : ROUTERCfgFileRouteCreationMode
+outputCreationMode : ROUTERCfgFileRouteCreationMode
+parser : ROUTERCfgFileParser
+object : DDS_XMLObject
ROUTERCfgFileAutoTopicRoute
Figure 3.24: ROUTERCfgFileAutoTopicRoute class diagram.
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+getFirstTransformationClass() : ROUTERCfgFileTransformationClass
+getNextTransformationClass(in transformationClass : ROUTERCfgFileTransformationClass) :
ROUTERCfgFileTransformationClass
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context :
DDS_XMLContext) : DDS_XMLObject
+_______()
+_______()
+base : DDS_XMLObject
+name : char *
ROUTERCfgFileTransformationClassLibrary
Figure 3.25: ROUTERCfgFileTransformationCassLibrary class diagram.
ROUTERCfgFileTransformationClass
ROUTERCfgFileTransformationClass class (Figure 3.26) parses the “<transforma-
tion_class>” XML tag. It stores the information of a specific TransformationClass and
all its associated entities.
ROUTERCfgFileTransformationClassSequence
ROUTERCfgFileTransformationClassSequence class (Figure 3.27) parses the
“<transformation_class_sequence>” XML tag. It stores the information of a specific
TransformationClassSequence, which is composed by a sequence of ROUTERCfgFi-
leTransformations.
Chapter 3. Design
43
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context :
DDS_XMLContext) : DDS_XMLObject
+____()
+base : DDS_XMLObject
+name : char *
+dll : char *
+loadFunction : char *
+unloadFunction : char *
+createTransformationFunction : char *
+deleteTransformationFunction : char *
+modifyTransformationFunction : char *
+transformFunction : char *
+inputTypeName : char *
+outputTypeName : char *
ROUTERCfgFileTransformationClass
Figure 3.26: ROUTERCfgFileTransformationClass class diagram.
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+getFirstTransformation() : ROUTERCfgFileTransformation
+getNextTransformation(in transformation : ROUTERCfgFileTransformation) : ROUTERCfgFileTransformation
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context :
DDS_XMLContext *) : DDS_XMLObject
+_____()
+base : DDS_XMLObject
+name : char *
+enabled : bool
ROUTERCfgFileTransformationSequence
Figure 3.27: ROUTERCfgFileTransformationSequence class diagram.
ROUTERCfgFileTransformation
ROUTERCfgFileTransformation class (Figure 3.28) stores the information of a specific
Transformation and all its associated entities (input and output TypeCode).
+onStartElement(in tag_name : char *, in attr : char *, in context : DDS_XMLContext) : void
+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : void
+checkTypeConsistency(in context : DDS_XMLContext) : void
+finalize() : void
+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *, in className : char *,
in enabled : bool) : bool
+delete() : void
+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context :
DDS_XMLContext) : DDS_XMLObject
+_____()
+_____()
+base : DDS_XMLObject
+name : char *
+className : char *
+enabled : bool *
+expression : char *
+parameterSeq
+inputTypeName : char *
+outputTypeName : char *
+inputTypeCode : DDS_TypeCode
+outputTypeCode : DDS_TypeCode
ROUTERCfgFileTransformation
Figure 3.28: ROUTERCfgFileTransformation class diagram.
DDS on the WAN: The DDS Routing Service
44
ROUTERParameterManager
ROUTERParameterManager class (Figure 3.29) objective is to process the configuration pa-
rameters (configuration file, server name, base domain id) that the user introduces during ser-
vice startup. This class also provides information about which configuration parameters are al-
lowed by the system.
+printHelp() : void
+printVersion() : void
+getParameter(out value : void *, out exist : bool *, in parameterId : int, in parameterType : ROUTERParameterType) : bool
+finalize() : void
+initialize(in argc : int *, in argv : char *) : bool
+delete() : void
+new(in argc : int *, in argv : char *) : ROUTERParameterManager
-_init : int
-_parameterValues : ROUTERParameterValue
ROUTERParameterManager
Figure 3.29: ROUTERParameterManager class diagram.
3.2.4 test Package
The test package is aimed to check if DDS Routing Service works properly. This checking is di-
vided in several unit tests that are carried out by the class ROUTERTester (Figure 3.30). This
class provides functions for executing a specific unit test or the whole bunch of tests.
+run() : bool
+start(in testId : int) : int
+startALL() : bool
+main(in argc : int, in argv : char *) : int
ROUTERTester
Figure 3.30: ROUTERParameterTester class diagram.
3.3 Sequence Diagrams In order to clarify how the DDS Routing Service works, sequence diagrams of the main use cases
of the system are provided. Instead of including all the possible diagrams, for the sake of simplic-
ity only the most relevant diagrams are studied.
3.3.1 Discover DDS Entity
In this use case the discoveryWaitset notifies existing Topic Routes and Auto Top-
ic Routes about changes in discovered DDS entities. The overall sequence diagram has been
divided in five sub-diagrams in order to make it more readable.
Received New Discovery Information
This sequence diagram (Figure 3.31) shows how ROUTERService notifies ROUTERDomai-
nRoute about changes in discovery information using “on (Publica-
tion/Subscription/Participant) Discovered” and ”on (Publica-
tion/Subscription/Participant) (Disposed/Unregistered)” functions. In
the figure, “Publication/Subscription/Participant” has been replaced by the
more generic term “ENTITY”.
Chapter 3. Design
45
discoveryWaitset DDSROUTERService
[DDS_RETCODE_OK] Get WaitSet Conditions
DDS_DataReader:= Get Reader
DDS_DomainParticipant:= Get Participant
*[!lastDomainRoute] ROUTERDomainRoute:= Get Domain Route
Take samples
Samples
*[!lastCondition && !_exitCondition] Process condition
[!DDS_RETCODE_NO_DATA && DDS_RETCODE_OK] Get samples lenght
*[!lastSample] Process a sample
[!valid_data && DDS_NOT_ALIVE_INSTANCE_STATE] onENTITYDisposed(ddsENTITY, info)
Ok
Ok
New discovery information
[valid_data] onENTITYDiscovered(ddsENTITY, ENTITYData, info)
DDS_ENTITYBuiltinTopicDataDataReader_return_loan(reader, &ENTITYSeq, &infoSeq)
[pubSeqTaken] DDS_PublicationBuiltinTopicDataDataReader_return_loan(reader, &pubSeq, &infoSeq)
[subSeqTaken] DDS_SubscriptionBuiltinTopicDataDataReader_return_loan(reader, &subSeq, &infoSeq)
[parSeqTaken] DDS_ParticipantBuiltinTopicDataDataReader_return_loan(reader, &parSeq, &infoSeq)
*[Reader is "ENTITY" BuiltinReader] Process discovery info with proper BuiltinReader
Figure 3.31: Received new discovery information sequence diagram.
DDS on the WAN: The DDS Routing Service
46
On(Publication/Subscription)Discovered
This sequence diagram (Figure 3.32) shows the actions that the system takes when a new Pub-
lication (or Subscription) is discovered. For simplicity, the terms “Publica-
tion/Subscription” have been substituted by “ENTITY” (for current entity) and “OPPO-
SEDENTITY” (referring to he opposed entity of ENTITY).
ROUTERDomainRoute
ROUTERService
bool:=onENTITYDiscovered)
Identify participants
ROUTERDiscoveredTopic
[Participant!=NULL && ENTITYData!=NULL] ROUTERDiscoveredTopic:=assertDiscoveredENTITY()
ROUTERDomainRouteParticipant
ROUTERSession
bool:=isStarted()
ROUTERAutoTopicRoute
TopicRoute:=matchTopic()
[lookupOK] onOPPOSITEENTITYTopicDiscovered
onENTITYTopicDiscovered
bool:=isStarted
[sessionStarted]
*[!lastAutoTopicRoute] AutoTopicRoute:=Get AutoTopicRoute
[!topicRouteStarted] startTopicRoute()
OK
[matched && !topicRoute] <<create>>
ROUTERTopicRoute
*[!lastTopicRoute] TopicRoute:=Get TopicRoute
lookupDiscoveredOPPOSITEENTITYTopic()
[topicRoute!=NULL] addTopicRoute(topicRoute)
ROUTERTopicRoute
ROUTERDiscoveredEntity
<<create>>
[topic!=NULL && !ENTITYalreadyExists]
*[!lastSession] ROUTERSession:=Get a session
<<create>>
Figure 3.32: On(Publication/Subscription)Discovered sequence diagram.
Chapter 3. Design
47
On(Publication/Subscription)Disposed
This sequence diagram (Figure 3.33) shows the actions that the system takes when a Publica-
tion (or Subscription) is not alive anymore.
ROUTERService ROUTERDomainRoute ROUTERDomainRouteParticipant
onENTITYDisposed()
removeDiscoveredENTITY()
[drParticipant!=NULL]
ROUTERDiscoveredTopic
Identify participants
[noReferencesToTopic] <<destroy>>
ROUTERDiscoveredEntity
EmptyAssociatedLists
<<destroy>>
Figure 3.33: On(Publication/Subscription)Disposed sequence diagram.
OnParticipantDiscovered
This sequence diagram (Figure 3.34) shows the actions that the system takes when a Partici-
pant is discovered. The only performed action is to ignore the new Participant if it is con-
tained in the current ROUTERGroup.
ROUTERService ROUTERDomainRoute
onParticipantDiscovered()
Identify participants
[drParticipant!=NULL]
ROUTERDomainRouteParticipant
[drParticipantIsInCurrentRouterGroup] ignore_participant()
Figure 3.34: OnParticipantDiscovered sequence diagram.
DDS on the WAN: The DDS Routing Service
48
OnParticipantUnregistered
This sequence diagram (Figure 3.35) shows the actions that the system takes when a Partici-
pant is not alive anymore.
ROUTERService ROUTERDomainRoute
onParticipantUnregistered()
Identify participants
[drParticipant!=NULL]
*[!lastDataWriter] ROUTERDiscoveredEntity:=Get DataWriter
ROUTERDomainRouteParticipant
removeDiscoveredPublication()
ROUTERDiscoveredTopic ROUTERDiscoveredEntity
[noReferencesToTopic] <<destroy>>
EmptyAssociatedLists
<<destroy>>
*[!lastDataReader] ROUTERDiscoveredEntity:=Get DataReader
removeDiscoveredSubscription()
[noReferencesToTopic] <<destroy>>
EmptyAssociatedLists
<<destroy>>
ROUTERDiscoveredTopic ROUTERDiscoveredEntity
Figure 3.35: OnParticipantUnregistered sequence diagram.
3.3.2 Route Data Sample
This use case illustrates how the dataWaitset notifies its associated session about the
presence of new data to be routed. For the sake of simplicity, this sequence diagram has been
divided in two sub-diagrams.
Chapter 3. Design
49
Received New Data
This sequence diagram (Figure 3.36) shows the actions that the system takes on the arrival of
new data to a Topic Route DataReader.
dataWaitset ROUTERSession
Received new data
[!_waitingToStopTopicRouteFlag && DDS_RETCODE_OK] Get Waitset conditions
*[!lastCondition && !_exitCondition] Process condition
DDS_DataReader:= Get Reader
ROUTERTopicRoute:= Get DataReader Topic Route
DDS
DDS_DynamicDataReader_take
Samples
ROUTERTopicRoute
[!DDS_RETCODE_NO_DATA && DDS_RETCODE_OK] bool:=isStarted()
route(DDS_DynamicDataSeq,DDS_SampleInfoSeq)
DDS_DynamicDataReader_return_loan()
[errorStopTopicRoute] stop()
Figure 3.36: Received new data sequence diagram.
DDS on the WAN: The DDS Routing Service
50
Route Data
This sequence diagram (Figure 3.37) shows how a TopicRoute routes data upon a Session
request. This routing is executed after applying data transformation according to the service
configuration.
ROUTERSession ROUTERTopicRoute
route(DDS_DynamicDataSeq,DDS_SampleInfoSeq)
*[!lastSample] Process a sample
[validData] DDS_DynamicData:=DDS_DynamicDataSeq_get_reference()
DDS ROUTERTransformation
*[!lastTransformation] Transform samples
[transformationsEnabled]
Transformed samples
[!validData && propagateDispose/Unreg && DISPOSED/UNREG_INSTANCE] DDS_DynamicData:=DDS_DataReader_get_key_value_untypedI()
[validData || (propagateDispose && DISPOSED_INSTANCE)]
[publishWithOriginalInfo] Copy publication info
[!RTI_TRANSFORMATION_REJECT]
[validData] DDS_DataWriter_write_untyped_generalI()
[!validData]
[DISPOSED_INSTANCE] DDS_DataWriter_dispose_untyped_generalI()
[NO_WRITERS_INSTANCE] DDS_DataWriter_unregister_instance_untyped_generalI()
OK
Figure 3.37: Route data sequence diagram.
Chapter 3. Design
51
3.4 Conclusions In this chapter we have discussed the design of the proposed DDS Routing Service. To give a
general picture of the proposed system design we have introduced the service entities and their
relationships. We have also studied the static model of the system using package and class dia-
grams. Finally, we have studied the logic flow of the main use cases of the system by means of
the most relevant sequence diagrams.
Besides of the system design, the proposed DDS Routing Service has been implemented. In fol-
lowing chapters we will discuss some implementation details, lesson learned, and main contribu-
tions and conclusions of the proposed DDS Routing Service.
53
Chapter 4. Implementation
Besides of the system design, a preliminary prototype of the DDS Routing Service has been im-
plemented. This prototype has been further developed by RTI as the “RTI DDS Routing Service”
[11]. In this chapter we will study the most relevant implementation details of the developed
system.
Specifically, in this chapter we will discuss the following points:
RTI Data Distribution Service 4.4d
Dynamic Types for DDS
Object oriented programming in C
Waitsets
Linked lists and skip lists
XML configuration file format. RTI XML Parser.
This chapter will end by including several examples of how to use the implemented RTI DDS
Routing Service.
4.1 RTI Data Distribution Service 4.4d The proposed RTI DDS Routing Service has been implemented using the RTI version of DDS mid-
dleware. This decision is based on the fact that RTI DDS 4.4d is the only implementation which
currently supports Dynamic Topic Types. This extension is part of an in-progress OMG specifica-
tion (see Section 4.2). Therefore, we expect that in the future the DDS Routing Service will be
feasible using other implementations of DDS middleware.
Furthermore, as RTI DDS complies with the DDSI OMG specification [18], the implemented RTI
DDS Routing Service should be able to interoperate with any DDSI-compliant DDS middleware.
4.2. Dynamic Types for DDS
4.2.1 Introduction to RTI Dynamic Topic Types API
The OMG DDS standard has been initially designed to support statically defined data models. In
this approach, the application must know the Topic data types at compile time. Similarly, it is
required that any DDS global data space member agrees precisely on the same Topic-type
association. These associations are captured by either DLRL class inheritance, or by DCPS IS-A
DDS on the WAN: The DDS Routing Service
54
relations. Although this model has certain benefits like static type checking and a simpler and
efficient implementation with low-overhead, it also suffers some drawbacks. Namely, it is hard
to cope with data models evolving over time unless all the elements of the system are upgraded
consistently. And it is also complex to deal with dynamically defined Topics, although in some
cases it is achievable by means of proprietary APIs.
All these limitations are currently being addressed in the OMG RFP “Extensible and Dynamic
Topic Types for DDS” [21] [27] [28], which has been introduced in Chapter 1.
For the current implementation of the RTI DDS Routing Service, the RTI version of Dynamic Types
API has been used. However, once the standard is published, it should not be necessary to im-
plement too many changes to the service code, since RTI is one of the members of the “Extensi-
ble and Dynamic Topic Types for DDS” specification committee and its Dynamic Types API is very
similar to the one that is going to be standardized by the OMG.
In the next sections we will explain how to use the RTI Dynamic Topic Types API.
4.2.2 Interacting Dynamically with User Data Types
In the previous section, the drawbacks of the Static Topic Types were discussed. This section
studies how to use the RTI DDS Dynamic Topic Types API [29] for using custom types without
defining them at compilation time. This feature is basic for implementing the RTI DDS Routing
Service, because this service has to be able to take input data with any Topic type and repub-
lish those data to the output, maybe after applying some transformations. Obviously it is not
desirable and feasible to re-compile the whole service each time that a new Topic type will be
discovered.
Introduction to TypeCode
In DDS, Type schemas (the names and definitions of a type and its fields) are represented by
TypeCode objects. A type code value consists of a type code kind (Figure 4.1) and a list of
members. For compound types like structs and arrays, this list will recursively include one or
more type code values.
enum TCKind {
TK_NULL,
TK_SHORT,
TK_LONG,
TK_USHORT,
TK_ULONG,
TK_FLOAT,
TK_DOUBLE,
TK_BOOLEAN,
TK_CHAR,
TK_OCTET,
TK_STRUCT,
TK_UNION,
TK_ENUM,
TK_STRING,
TK_SEQUENCE,
TK_ARRAY,
TK_ALIAS,
TK_LONGLONG,
TK_ULONGLONG,
TK_LONGDOUBLE,
Chapter 4. Implementation
55
TK_WCHAR,
TK_WSTRING,
TK_VALUE,
TK_SPARSE
}
Figure 4.1: TCKind enumeration [29].
TypeCodes unambiguously match type representations and provide a more reliable test than
comparing the string type names. The TypeCode class, modeled after the corresponding COR-
BA API, provides access to TypeCode information.
Defining New Types
According to the Static Topic Types API, a DDS application can access the TypeCode for a type
“Foo” by calling the Foo_get_typecode() operation. However, this operation is only avail-
able if it has been included at compilation time. On the other hand, the Dynamic Topic Types API
allows creating TypeCodes at run time without any code generation.
Creating a TypeCode is parallel to the way of defining the type statically: the application has to
define the type itself with some name, and then add members to it, each with its own name and
type. For example, let MyType be the statically type of Figure 4.2.
struct MyType {
long my_integer;
float my_float;
bool my_bool;
string<128> my_string; // @key
};
Figure 4.2: Example of static type [29].
The C++ code for defining the same type at run time is shown in Figure 4.3.
DDS_ExceptionCode_t ex = DDS_NO_EXCEPTION_CODE;
DDS_StructMemberSeq structMembers; // ignore for now
DDS_TypeCodeFactory* factory =
DDS_TypeCodeFactory::get_instance();
DDS_TypeCode* structTc = factory->create_struct_tc(
"MyType", structMembers, ex);
// If structTc is NULL, check 'ex' for more information.
structTc->add_member("my_integer",
DDS_TYPECODE_MEMBER_ID_INVALID,
factory->get_primitive_tc(DDS_TK_LONG),
DDS_TYPECODE_NONKEY_MEMBER, ex);
structTc->add_member("my_float",
DDS_TYPECODE_MEMBER_ID_INVALID,
factory->get_primitive_tc(DDS_TK_FLOAT),
DDS_TYPECODE_NONKEY_MEMBER, ex);
structTc->add_member("my_bool",
DDS_TYPECODE_MEMBER_ID_INVALID,
factory->get_primitive_tc(DDS_TK_BOOLEAN),
DDS_TYPECODE_NONKEY_MEMBER, ex);
structTc->add_member("my_string",
DDS_TYPECODE_MEMBER_ID_INVALID,
factory->create_string_tc(128),
DDS_TYPECODE_KEY_MEMBER, ex);
Figure 4.3: Code example for defining a static type [29].
DDS on the WAN: The DDS Routing Service
56
After defining the TypeCode, it has to be registered with a Participant using a logical
name (Figure 4.4). This name will be used later in order to create a Topic.
DDSDynamicDataTypeSupport* type_support =
new DDSDynamicDataTypeSupport(
structTc, DDS_DYNAMIC_DATA_TYPE_PROPERTY_DEFAULT);
DDS_ReturnCode_t retcode = type_support->register_type(
participant,"My Logical Type Name");
Figure 4.4: Code example for registering a type with a Participant [29].
Sending TypeCodes on the Network
Besides using serialized type codes locally, they are typically published automatically during dis-
covery as part of the Builtin Topics for Publications and Subscriptions. This
approach allows applications to publish or subscribe to Topics of arbitrary types. This functio-
nality is useful for generic system monitoring tools like the rtiddsspy debug [29] tool and for
the proposed RTI DDS Routing Service.
The RTI DDS Routing Service processes the information of three specific Builtin Topics:
Participant Builtin Topic: It provides information about discovered and un-
registered DDS Domain Participants. The only field of interest for the proposed
service is property, which is described below:
o property: Pairs of names/values to be stored with the Participant. The
service will use this field for recognizing redundant RTI DDS Routing Service
servers.
Publication Builtin Topic: This Topic provides information about discov-
ered and disposed DDS Publications. The proposed RTI DDS Routing Service has to
process the following fields:
o topic_name: Topic name of the discovered DataWriter.
o type_name: Type name attached to the topic of the discovered DataWri-
ter.
o type_code: TypeCode information about this Topic.
o participant_key: DDS key to distinguish the Participant to which the
discovered DataWriter belongs to.
Subscription Builtin Topic: This Topic provides information about discov-
ered and disposed DDS Subscriptions. The proposed RTI DDS Routing Service has to
process the following fields:
o topic_name: Topic name of the discovered DataReader.
o type_name: Type name attached to the Topic of the discovered Data-
Reader.
o type_code: TypeCode information about this Topic.
o participant_key: DDS key to distinguish the Participant to which the
discovered DataReader belongs to.
Chapter 4. Implementation
57
Using the previous Builtin Topics, the proposed RTI DDS Routing Service is able to publish
or to subscribe to Topics of arbitrary types. As previously mentioned, it is a key feature for
establishing the desired Topic Routes.
4.3 Object Oriented Programming in C In previous chapters we have made an extensive use of Object-Oriented Programming (OOP)
paradigm concepts [30]. Object-oriented programming (OOP) is a programming paradigm that
uses "objects" (data structures consisting of datafields and methods together with their interac-
tions) to design applications and computer programs. This section explains the rules and metho-
dology that we have applied in order to program in C using the object-oriented paradigm (OOP).
The understanding of this section is critic for the correct assimilation of the RTI DDS Routing
Service source code.
Before discussing the methodology and rules for using the OOP paradigm in C, we are going to
explain the reasons that justify using OOP with a structured oriented language as C:
Modern software programming techniques as “The Unified Software Development
Process” [31] have been conceived for being applied using OOP languages.
The code can be easily structured in a functional manner by using OOP methodologies,
which is critic as the code complexity increases.
Using OOP paradigm allows the use of UML diagrams during the design phase of the
project. These diagrams not only facilitate the implementation of the system, but simpli-
fy future revisions of the source code.
The rules and methodology for using the OOP paradigm in C are detailed below:
1. Class representation: In object-oriented programming, a class is a construct that is used
as a blueprint to create objects of that class. In the proposed system, every class has
been implemented using a C struct, where each element of the struct represents a
class data member (see Figure 4.5).
struct ROUTERDomainRoute {
struct REDAInlineListNode _node;
/*i @brief Domain route configuration */
struct ROUTERCfgFileDomainRoute * _domainRouteCfg;
/*i @brief List of sessions associated to this route */
struct REDAInlineList _sessionList;
/*i @brief Reference to the transformation class manager
that all the transformations inside topic routes in
this domain route will use to build their
transformations objects */
struct ROUTERTransformationClassManager * _transfManager;
/*i @brief The group name of the router service this object
belongs to */
const char * routerGroupName;
/*i @brief The source participant, where the data comes
from */
struct ROUTERDomainRouteParticipant participant1;
/*i @brief The destination participant, where the data is
republished */
struct ROUTERDomainRouteParticipant participant2;
RTIBool started;
DDS on the WAN: The DDS Routing Service
58
};
Figure 4.5: Example of how to implement a class using C structs
2. Namespaces: In order to avoid conflicts in the implemented code, structs and func-
tions have been prefixed with their corresponding namespace. A namespace is an ab-
stract container providing context for the items it holds and allowing disambiguation of
homonym items having the same name (residing in different namespaces). For example,
all the classes contained in our system belong to the “ROUTER” namespace.
3. Class methods: In object-oriented programming, a method is a function that is exclu-
sively associated either with a class or with an object. In the proposed system, the link
between a class and its associated functions is represented through the name of the
functions. Consequently, a function called “route” that belongs to the class “ROU-
TERTopicRoute” would be called “ROUTERTopicRoute_route”.
4. Function parameters: In OOP, a method associated to an object has access to all the da-
ta members of that object. In the implementation of our system this association is
represented through the first function parameter, called self. The parameter self is
used to reference the struct containing all the data members of the virtual object, so
the function can access to all those data members.
5. “new” and “delete” functions: In the implemented system, all classes have been
added functions for allocating (new) and freeing the resources (delete) of an existing
object.
The application of the previous rules allows programming in C taking advantage of the benefits
that the OOP paradigm offers.
4.4 WaitSets
Listeners and Conditions (in conjunction with WaitSets) are two alternative mechan-
isms that allow the application to be made aware of changes in the DCPS communication status
[1] [29]. While a Listener is used to provide a callback for asynchronous access, Condi-
tions and WaitSets provide synchronous data access. In other words, Listeners are
notification-based and Conditions are wait-based. In RTI DDS Routing Service, the communi-
cation between the service and DDS middleware has been implemented using WaitSets (i.e.
synchronous access).
In order to enable a WaitSet is necessary to attach at least one Condition to it and call to
the function wait(). Once the wait() function has been called, the WaitSet will block the
application until one or more of the WaitSet attached Conditions becomes true (or else
until a timeout expires).
A Condition has a trigger_value that can be true or false. There are three kinds of Con-
ditions. Condition is a root class for all the conditions that may be attached to a Wait-
Set. This basic class is specialized in three classes:
StatusConditions: These Conditions are created automatically by DDS mid-
dleware, one for each existing Entity. A StatusCondition is triggered by DDS
when there is a change to any of the enabled statuses of that Entity.
Chapter 4. Implementation
59
ReadConditions: These Conditions can be created by any application, but they
are triggered by DDS middleware. ReadConditions provide a way to specify the data
samples that an application should wait for, by indicating the desired sample-states,
view-states, and instance-states.
GuardConditions: These Conditions are created and controlled at application
level. Each GuardCondition has a single, user-settable, boolean trig-
ger_value. This value has to be trigged by the application by calling
set_trigger_value() function.
A WaitSet can be associated with more than one Entity (including multiple DomainPar-
ticipants). It can be used to wait on Conditions associated with different DomainPar-
ticipants. However, a WaitSet can only be in use by one application thread at a time.
For the implementation of the proposed RTI DDS Routing Service two kinds of Conditions
have been used: StatusConditions (for notifying changes in discovery and Topic data
information) and GuardConditions (for notifying user’s halt signal).
4.5 Linked Lists. Skip Lists. Some of RTI DDS Routing Service entities have to manage a large number of associated elements
(e.g. a ROUTERSession may contain several ROUTERTopicRoutes). In order to maintain
the relationship between a parent entity and its children, the implemented system uses a special
data structure called linked list [32].
A linked list is a data structure that consists of a sequence of data records such that in each
record there is a field that contains a reference (i.e., a link) to the next record in the sequence.
Linked lists are among the simplest and most common data structures, and are used to imple-
ment many important abstract data structures, such as stacks, queues, hash tables, symbolic
expressions, skip lists, and many more.
The principal benefit of a linked list over a conventional array is that the order of the linked
items may be different from the order that the data items are stored in memory or on disk. For
that reason, linked lists allow insertion and removal of nodes at any point in the list, with a con-
stant number of operations. The first item of the list, or head, is accessed from a fixed location,
called “head pointer”. For accessing the rest of items, it is necessary to iterate from the head to
the item scanning all the nodes in-between (Figure 4.6). Scanning the whole list in order to find
a specific element is not efficient enough in some circumstances, and it is necessary to use alter-
native solutions as using skip lists.
DDS on the WAN: The DDS Routing Service
60
Figure 4.6: Example of linked list
Skip lists
A skip list [33] is a data structure for storing a sorted list of items, using a hierarchy of linked lists
that connect increasingly sparse subsequences of the items. These auxiliary lists allow item loo-
kup with efficiency comparable to balanced binary search trees (that is, with number of probes
proportional to log n instead of n).
A skip list is built in layers (Figure 4.7). The bottom layer is an ordinary ordered linked list. Each
higher layer acts as an "express lane" for the lists below, where an element in layer i appears in
layer i+1 with some fixed probability p (two commonly-used values for p are 1/2 or 1/4). On
average, each element appears in 1/(1-p) lists, and the tallest element (usually a special head
element at the front of the skip list) in log1/p n lists.
Figure 4.7: Example of skip list
A search for a target element begins at the head element in the top list, and proceeds horizon-
tally until the current element is greater than or equal to the target. If the current element is
equal to the target, it has been found. If the current element is greater than the target, the pro-
cedure is repeated after returning to the previous element and dropping down vertically to the
next lower list. The expected number of steps in each linked list is at most 1/p, which can be
seen by tracing the search path backwards from the target until reaching an element that ap-
pears in the next higher list or reaching the beginning of the current list. Therefore, the total
expected cost of a search is (log1/p n)/p, which is O(log n), when p is a constant. By choosing dif-
ferent values of p, it is possible to trade search costs against storage costs.
We have used skip list for implementing lists of publications, subscriptions, DataWriters,
DataReaders and discovered types that are associated to a Topic Route. As has been said
before, element searching relies in a comparison function. For the implementation of this func-
tion, the Topic names and the Type names associated to the compared elements has been
compared by means of strcmp() function.
Chapter 4. Implementation
61
4.6 XML Configuration Format. XSD Schemas. For loading the configuration of RTI DDS Routing Service, XML files have been used. XML (Extens-
ible Markup Language) is a set of rules for encoding documents. These rules are defined in the
XML 1.0 Specification produced by the W3C [14].
In order to parse XML configuration files, we have taken advantage of the existing RTI Data Dis-
tribution Service 4.4d XML Parser. In this way, the config package classes of the RTI DDS
Routing Service (see Chapter 3) have been implemented as children of the RTI
DDS_XMLObject class. Moreover, we have adopted the description of data types from RTI
DDS XML Description Type format [29]. An advantage of this approximation is that it enables the
RTI DDS Routing Service to access to the whole set of RTI DDS QoS policies and features in a
transparent manner (i.e. using the same RTI DDS Routing Service XML configuration file for con-
figuring the behavior of the middleware).
The rules for creating RTI DDS Routing Service configuration files have been specified through
XML Schemas (XSD) files. XSD files provide a means for defining the structure, content and se-
mantics of XML documents. XML Schema was approved as a W3C Recommendation on 2 May
2001 and a second edition incorporating many errata was published on 28 October 2004 [26].
For more information about the RTI DDS Routing Service XML configuration format, please refer
to Annex A.
4.7 Example use of RTI DDS Routing Service In this section, an example use of RTI DDS Routing Service is shown. To that end, we will revise
each one of the restrictions studied in Chapter 1.
For the purpose of this example, we will configure the following test architecture (see Figure
4.8):
RTI ShapesDemo RTI ShapesDemo
DOMAIN 0 DOMAIN 1
RTI DDS Routing
Service
Virtual
Machine
Host
Figure 4.8: Example test architecture
DDS on the WAN: The DDS Routing Service
62
The RTI DDS Routing Service [11] will be run in a Linux Host.
Two instances of the RTI Shapes Demo application [34] will be executed in a VirtualBox
[35] Windows Machine. These applications will be associated to Domains 0 and 1 re-
spectively.
The virtual machine and the host will be connected to the same virtual LAN.
R1. DOMAIN_BRIDGING
In this example we configure the RTI DDS Routing Service for bridging data published in a Do-
main 0 to a Domain 1. The used XML configuration file is shown in Figure 4.9.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/rti_routing_service.xsd">
<!-- ***************************************************** -->
<!-- Default configuration file for the rtiroutingservice -->
<!-- ***************************************************** -->
<routing_service>
<domain_route name="DefaultDomainRoute" enabled="true">
<participant_1>
<domain_id>0</domain_id>
</participant_1>
<participant_2>
<domain_id>1</domain_id>
</participant_2>
<session name="DefaultSession" enabled="true">
<auto_topic_route name="All" enabled="true">
<publish_with_original_info>
true
</publish_with_original_info>
<input participant="1"></input>
<output></output>
</auto_topic_route>
</session>
</domain_route>
</routing_service>
</dds>
Figure 4.9: Example of XML configuration file for Domain Bridging
As it is shown in Figure 4.10, while running the RTI DDS Routing Service in the Linux host, the
Subscribers in Domain 1 are able to receive data samples from Publishers in Domain 0.
Figure 4.10: Example of Domain Bridging with RTI Shapes Demo
Chapter 4. Implementation
63
R2. TOPIC_BRIDGING
In this example the RTI DDS Routing Service is used for republish data from the Topic “Square”
in Domain 0 to the Topic "Triangle” in Domain 1, both Topics of the same type “Shape-
Type”. The used XML configuration file is shown in Figure 4.11.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/rti_routing_service.xsd">
<routing_service>
<domain_route name="DefaultDomainRoute" enabled="true">
<participant_1>
<domain_id>0</domain_id>
</participant_1>
<participant_2>
<domain_id>1</domain_id>
</participant_2>
<session name="DefaultSession" enabled="true">
<topic_route name="SquaresToTriangles">
<input participant="1">
<registered_type_name>
ShapeType
</registered_type_name>
<topic_name>Square</topic_name>
</input>
<output>
<registered_type_name>
ShapeType
</registered_type_name>
<topic_name>Triangle</topic_name>
</output>
</topic_route>
</session>
</domain_route>
</routing_service>
</dds>
Figure 4.11: Example of XML configuration file for Topic Bridging
Figure 4.12: Example of Topic Bridging with RTI Shapes Demo
As it is shown in Figure 4.12, while the DDS Routing Service is running in the Linux host, the
Subscribers associated to Topic “Triangle” in Domain 1 are able to receive data samples
from Publishers associated to Topic “Square” in Domain 0.
DDS on the WAN: The DDS Routing Service
64
R3 – R5. TRANSFORMATIONS
In this example we study how to load an external transformation DLL file. The functions of this
DLL are used for transforming the samples of a Topic before republish them to another Top-
ic. Specifically, the DLL containing the mapping built-in transformations of the RTI DDS Routing
Service is used. The XML configuration file associated to this example is shown in Figure 4.13.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/rti_routing_service.xsd">
<transformation_class_library
name="TestTransformationLib">
<!--
This transformation is implemented in that shared library.
It allows copying fields from one dynamic data sample to
other dynamic data sample
-->
<transformation_class name="FieldMapping">
<dll>librtiroutingservice_transformations</dll>
<load_function>
ROUTERMapFieldsTransf_load
</load_function>
<unload_function>
ROUTERMapFieldsTransf_unload
</unload_function>
<create_transformation_function>
ROUTERMapFieldsTransf_create
</create_transformation_function>
<delete_transformation_function>
ROUTERMapFieldsTransf_delete
</delete_transformation_function>
<modify_transformation_function>
ROUTERMapFieldsTransf_modify
</modify_transformation_function>
<transform_function>
ROUTERMapFieldsTransf_transform
</transform_function>
</transformation_class>
</transformation_class_library>
<routing_service>
<domain_route name="DefaultDomainRoute" enabled="true">
<participant_1>
<domain_id>0</domain_id>
</participant_1>
<participant_2>
<domain_id>1</domain_id>
</participant_2>
<session name="DefaultSession" enabled="true">
<topic_route name="SquareTransformations">
<input participant="1">
<registered_type_name>
ShapeType
</registered_type_name>
<topic_name>Square</topic_name>
</input>
<output>
<registered_type_name>
ShapeType
</registered_type_name>
<topic_name>Square</topic_name>
</output>
<transformation
className=
"TestTransformationLib::FieldMapping">
<expression></expression>
Chapter 4. Implementation
65
<!-- Output square x = Input square x -->
<parameter>x=x</parameter>
<!-- Output square y = Input square x -->
<parameter>y=x</parameter>
<!-- Output shapesize = Input square y -->
<parameter>shapesize=y</parameter>
</transformation>
</topic_route>
</session>
</domain_route>
</routing_service>
</dds>
Figure 4.13: Example of XML configuration file for Topic Bridging with data transformation
While the RTI DDS Routing Service is running with the above configuration the Subscribers
associated to Topic “Square” in Domain 1 received a transformed version of data samples in
Topic “Square” of Domain 0 (see Figure 4.14). Specifically, the RTI DDS Routing Service pub-
lishes the output x and y coordinates using the value in the input x coordinate. The service also
publishes the output shapesize using the value in the input y coordinate.
Figure 4.14: Example of Topic Bridging and data transforming with RTI Shapes Demo
R6 – R11. RTI DDS XML Configuration
As we have studied in Sections 4.1 and 4.6, the RTI DDS Routing Service uses an extended ver-
sion of the RTI DDS XML Parser. In this way, the RTI DDS Routing Service is able to access to the
whole set of RTI DDS QoS policies and features in a transparent manner, thereby taking advan-
tage of the potential of RTI DDS middleware.
In this section we will study some of the RTI DDS QoS policies and features which are useful for
deploying DDS in the WAN.
Content_Filtered_Topics
Content Filtered Topics are Topics with filtering properties. In Figure 4.15 an exam-
ple of use of Content Filtered Topics is shown.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/rti_routing_service.xsd">
<!-- ***************************************************** -->
DDS on the WAN: The DDS Routing Service
66
<!-- Default configuration file for the rtiroutingservice -->
<!-- ***************************************************** -->
<routing_service>
<domain_route name="DefaultDomainRoute" enabled="true">
<participant_1>
<domain_id>0</domain_id>
</participant_1>
<participant_2>
<domain_id>1</domain_id>
</participant_2>
<session name="DefaultSession" enabled="true">
<auto_topic_route name="All" enabled="true">
<publish_with_original_info>
true
</publish_with_original_info>
<input participant="1">
<content_filter>
<expression>shapesize>40</expression>
<parameter></parameter>
<parameter></parameter>
</content_filter>
</input>
<output></output>
</auto_topic_route>
</session>
</domain_route>
</routing_service>
</dds>
Figure 4.15: Example of XML configuration file for Domain Bridging with Content Filtering
In this example the RTI DDS Routing Service provides the same Domain Bridging as in the first
example. However, only the samples with shapesize>40 are bridged from Domain 0 to Do-
main 1, as is shown in Figure 4.16.
Figure 4.16: Example of Domain Bridging with Content Filtering
Transport Configuration
As the RTI DDS Route Service decouples remote Publishers and Subscribers spatially, is
possible to change the underlying transport protocol (e.g. using TCP instead UDP) for the sake of
security and scalability, without any changes to the DDS applications. The RTI DDS Routing Ser-
vice can also takes advantage NAT traversal protocols (e.g. STUN [25]), for communicating re-
mote DDS entities that are located behind a NAT.
Chapter 4. Implementation
67
RTI WAN Transport Service [16] is a plug-in for RTI DDS for providing both security (using DTLS
[24]) and NAT traversal (by means of STUN protocol [25]). Once the RTI WAN Transport Service
plug-in is installed in the same system than the RTI DDS Routing Service, it can be used adding
the following lines to the RTI DDS Routing Service XML configuration file, inside the <partici-
pant_2> tag (see Figure 4.17).
<participant_qos name="WANParticipant">
<transport_builtin>
<mask>MASK_NONE</mask>
</transport_builtin>
<property>
<value>
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.wan_plugin.wan</value>
<propagate>false</propagate>
</element>
<element>
<name>dds.transport.wan_plugin.wan.library</name>
<value>libnddstransportwan.so</value>
<propagate>false</propagate>
</element>
<element>
<name>
dds.transport.wan_plugin.wan.create_function
</name>
<value>NDDS_Transport_WAN_create</value>
<propagate>false</propagate>
</element>
<element>
<name>dds.transport.wan_plugin.wan.server</name>
<value>192.168.1.1</value>
<propagate>false</propagate>
</element>
<element>
<name>
dds.transport.wan_plugin.wan.transport_instance_id
</name>
<value>1</value>
<propagate>false</propagate>
</element>
</value>
</property>
</participant_qos>
Figure 4.17: Example of XML configuration file for using the RTI WAN Transport Service
Flow Control
In RTI DDS, A FlowController is the object responsible for shaping the network traffic. This
traffic shaping is done by determining when attached asynchronous DataWriters are allowed
to write data [29]. This feature is interesting for our RTI DDS Routing Service, as it enables the
service to control its throughput according to available bandwidth resources.
An example of how to configure the RTI DDS Routing Service for using one of the built-in RTI flow
controllers is shown in Figure 4.18. Specifically, this flow controller shapes the network traffic by
DDS on the WAN: The DDS Routing Service
68
allowing data to be sent only once every second and discarding the intermediate samples (i.e.
applying leaky bucket traffic shaping).
<datawriter_qos name=”FlowControllerDW”>
<publish_mode>
<kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
<flow_controller_name>
DDS_FIXED_RATE_FLOW_CONTROLLER_NAME
</flow_controller_name>
</publish_mode>
</datawriter_qos>
Figure 4.18: Example of XML configuration file for Leaky Bucket Traffic Shaping
4.8 Conclusions In this chapter the most relevant RTI DDS Routing Service implementation details have been
presented. Firstly, we have justified the adoption of the RTI DDS implementation. Secondly, we
have explained how to program in C using an OOP paradigm and the nomenclature that we have
followed during RTI DDS Routing Service implementation. We have also presented Waitsets
as a way to implement synchronous callbacks in order to communicate an application with the
DDS middleware. This chapter has also explained two kinds of data structures, linked and skip
lists, which are useful for implementing dynamic lists of elements. The RTI DDS Routing Service
XML configuration file format has also been introduced. Finally, several examples on how to use
the RTI DDS Routing Service have been presented.
In the next chapter, the implemented system and the DDS achieved improvements will be ana-
lyzed.
69
Chapter 5. Conclusions
In this chapter we summarize the main contributions and conclusions of the proposed DDS
Routing Service. The chapter also includes some DDS Routing Service future research directions.
5.1 Main Project Contributions This project has been developed in the collaboration framework between the University of Gra-
nada and Real-Time Innovations Inc. This collaboration is developed in the context of the RTI
University Program [36]. The project was partially developed during a six month internship in RTI
headquarter at Sunnyvale, CA (USA) from July 2008 to January 2009.
Specifically, our main project contributions are:
The study of the state of the art relative to the integration of DDS in the WAN (see Chap-
ter 1).
The identification of the objectives of the DDS Routing Service and its functional and
non-functional requirements (see Chapters 1 and 2).
The DDS Routing Service design. This includes the introduction of innovative concepts as
“Domain Route”, “Session”, “Topic Route”, “Auto Topic Route”,
“Transformation Class Library”, “Transformation Class” and
“Transformation” (see Chapter 3).
The definition of the XML configuration format for the DDS Routing Service (see Chapter
4 and Annex A) and the implementation of the DDS Routing Service XML parser.
The implementation of the DDS Routing Service initial prototype.
5.2 Conclusions Preliminary results of this project have been presented in July 2009 in the “X Workshop on Dis-
tributed Object Computing for Real-time and Embbebed Systems”, celebrated in Washington
(DC, USA) under the title “Deploying DDS on a WAN and the GIG: The DDS Router” [10]. This
workshop, organized by the OMG, is an international forum for software engineers and re-
searchers in real-time distributed systems. An extended version of this work is being submitted
to a journal.
The project has achieved its objectives with the following extracted conclusions:
DDS on the WAN: The DDS Routing Service
70
1. An architecture for the interconnection of different Domains has been proposed. The
DDS Routing Service allows different data-spaces to interoperate. This innovative
functionality is a new feature not included in the current DDS standard.
2. In addition to the interconnection of Domains, the DDS Routing Service enables Top-
ics with different names or types to interoperate. This feature is feasible thanks to
Dynamic Topic Types API.
3. The in-progress OMG Dynamic Topic Types for DDS specification [21] has a great poten-
tial as a mechanism for accessing to Topics of any data type. Once the standard is fi-
nished, it will reduce significantly the required time for develop applications which
access to arbitrary Topic types (e.g. a DDS monitor).
4. The proposed DDS Routing Service represents a big step towards the use of DDS over
the WAN. The DDS Routing Service connects remote data-spaces in a transparent man-
ner, i.e. it decouples spatially DDS entities in the context of a WAN. Thus allowing the
Publishers and Subscribers located in two remote LANs to interoperate with-
out requiring any modification to their source code.
5. The DDS Routing Service is able to filter and to transform data before transmitting them
through the WAN, thereby preventing the publication of private Topics.
6. The RTI DDS Routing Service takes advantage of existing RTI DDS QoS policies. For ex-
ample, it can use data batching for decreasing the required bandwidth. Another exam-
ple is the use of the RTI Secure WAN Transport plug-in for NAT traversal and privacy.
5.3 Future Work In this section some DDS Routing Service open issues are briefly studied that deserve future re-
search.
5.3.1 RELIABILITY DDS QoS policy
When RELIABILITY DDS QoS policy is set to RELIABLE, the acknowledgement of the recep-
tion of DDS samples is performed in a hop-by-hop basis. This situation is not always admissible,
and is required that a DataWriter receives ACK from the remote DataReader, not from the
DDS Routing Service DataReader. Therefore, a new open issue is the designing of end-to-end
ACKs for assuring REALIABILITY between remote entities when using the DDS Routing Ser-
vice.
5.3.2 Discovery Protocol based on Bloom Filters
As has been studied in Chapter 1, the RTPS specification [18] allows DDS implementations to
support multiple PDPs and EDPs for discovery.
One of the research interests of our group is related to improving the scalability of RTPS discov-
ery using Bloom Filters. Specifically, we have proposed SDPBloom as a feasible and highly scal-
able discovery protocol based in Bloom Filters. With SDPBloom the number of messages sent
over the network is closer to (Participants ∗ Participants) instead of (Participants ∗ Endpoints).
Additionally, both the spent network bandwidth consumption and nodes memory usage de-
crease [37] [38].
Therefore, an open issue is the integration of DDS Routing Service with SDPBloom and its eval-
uation in a WAN environment.
71
Bibliography
[1] OMG, “Data-distribution service for real-time systems (DDS).v1.2,” OMG, Tech. Rep.,
2006. [Online]. Available: http://www.omg.org/cgi-bin/doc?formal/07-01-01.pdf
[2] OMG, “Object management group,” 2009. *Online+. Available: http://www.omg.org/
[3] OMG, “Common object request broker architecture (CORBA/IIOP).v3.1,” OMG, Tech.
Rep., January 2008. [Online]. Available: http://www.omg.org/spec/CORBA/3.1/
[4] G. Pardo-Castellote, B. Farabaugh, and R. Warren, “An introduction to DDS and data-
centric communications,” 2005. *Online+. Available: http://www.omg.org/news/-
whitepapers/Intro_To_DDS.pdf
[5] G. Pardo-Castellote, “Omg data-distribution service: architectural overview,” in Distri-
buted Computing Systems Workshops, 2003. Proceedings. 23rd International Conference
on, May 2003, pp. 200–206. [Online]. Available: http://dx.doi.org/10.1109/-
ICDCSW.2003.1203555
[6] RTI, “Rti industry solutions,” 2009. *Online+. Available: http://www.rti.com/solutions/
[7] PRISMTECH, “Opensplice DDS industry solutions,” 2009. *Online+. Available: http://-
www.opensplice.com/section-item.asp?snum=2&sid=70
[8] E. de Jong, “RTI eases scaling and integration of real-time systems across WANs and sys-
tems of systems,” in Embedded Systems Conference, September 2009. [Online]. Availa-
ble: http://www.rti.com/company/news/dds-routing-service.html
[9] RTI, “Performance and scalability benchmarks: C++ on linux,” 2009. *Online+. Available:
http://www.rti.com/products/dds/benchmarks-cpp-linux.html
[10] G. Pardo-Castellote, F. Sanchez, and J. M. Lopez-Vega, “Deploying DDS on a WAN and
the GIG: The DDS Router,” in Real-time and Embedded Systems Workshop. OMG, July
2009. [Online]. Available: http://www.omg.org/news/meetings/GOV-WS/pr/rte.htm
[11] RTI, “RTI routing service for DDS,” 2009. *Online+. Available: http://www.rti.com/-
products/dds/routing-service.html
DDS on the WAN: The DDS Routing Service
72
[12] RTI, “Real-time innovations (RTI) - world leader in DDS - real-time application integration
and low-latency messaging,” 2009. *Online+. Available: http://www.rti.com/
[13] YoLinux, “Static, shared dynamic and loadable Linux libraries.” *Online+. Available:
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
[14] W3C, “Extensible markup language (XML) 1.0 (fifth edition),” W3C, Tech. Rep., Novem-
ber 2008. [Online]. Available: http://www.w3.org/TR/REC-xml/
[15] Network Working Group, “The transport layer security (TLS) protocol version 1.2,” IETF,
Tech. Rep., August 2008. [Online]. Available: http://tools.ietf.org/html/rfc5246
[16] RTI, “RTI secure WAN transport,” 2007. *Online+. Available: http://www.rti.com/docs/-
RTI_Secure_WAN_Transport.pdf
[17] J. Turner, “New directions in communications (or which way to the information age?),”
Communications Magazine, IEEE, vol. 24, no. 10, pp. 8–15, January 2003. [Online]. Avail-
able: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1092946
[18] OMG, “Real-time publish-subscribe (RTPS) wire protocol DDS interoperability wire pro-
tocol specification.v2.1,” OMG, Tech. Rep., 2008. *Online+. Available: http://-
www.omg.org/cgi-bin/doc?formal/09-01-05.pdf
[19] IEC, “IEC PAS 62030,” IEC, Tech. Rep., November 2004. *Online+. Available: http://-
webstore.iec.ch/p-preview/info_iecpas62030%7Bed1.0%7Den.pdf
[20] M. Hamilton and J. Knight, “A simple discovery protocol,” 1995. *Online+. Available:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3856
[21] OMG, “Extensible and dynamic topic types for DDS (RFP),” OMG, Tech. Rep., 2009. *On-
line]. Available: http://portals.omg.org/dds/SpecificationsInProgress
[22] RTI, “RTI eases integration of large-scale real-time applications with high-capacity net-
worked sensors,” in Embedded Systems Conference, August 2008. [Online]. Available:
http://www.rti.com/company/news/networked-sensors.html
[23] RTI, “Meeting real-time requirements in integrated defense systems,” 2007. *Online+.
Available: http://www.rti.com/whitepapers/Real-
Time_Integrated_Defense_Systems.pdf
[24] N. Modadugu and E. Rescorla, “The design and implementation of Datagram TLS,” in In
Proc. NDSS, 2004. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/-
summary?doi=10.1.1.74.6613
[25] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, “STUN - simple traversal of user
datagram protocol (UDP) through network address translators (NATS),” IETF, Tech. Rep.,
March 2003. [Online]. Available: http://www.ietf.org/rfc/rfc3489.txt
[26] W3C, “XML schema part 0: Primer second edition,” W3C, Tech. Rep., October 2004. *On-
line]. Available: http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/
Bibliography
73
[27] A. Corsaro, “Extensible and dynamic topic types for DDS,” May 2008. *Online+. Available:
http://dds4u.blogspot.com/2008/05/extensible-and-dynamic-topic-types-for.html
[28] R. Warren, “In progress at OMG: Extensible and dynamic types,” September 2009. *On-
line]. Available: http://blogs.rti.com/2009/09/01/omg-dds-extensible-and-dynamic-
types/
[29] RTI, Real-Time Innovations Inc. RTI Data Distribution Service. Users’ Manual (version 4.4),
2009.
[30] S. Schach, Object-Oriented and Classical Software Engineering, 7th ed. McGraw-Hill
Science/Engineering/Math, June 2006. [Online]. Available: http://www.worldcat.org/-
isbn/0073191264
[31] I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process.
Addison-Wesley Professional, February 1999. [Online]. Available: http://-
www.worldcat.org/isbn/0201571692
[32] P. E. Black, “linked list,” in Dictionary of Algorithms and Data Structures. U.S. National
Institute of Standards and Technology, August 2009. [Online]. Available: http://-
www.itl.nist.gov/div897/sqg/dads/HTML/linkedList.html
[33] W. Pugh, “Skip lists: a probabilistic alternative to balanced trees,” Commun. ACM,
vol. 33, no. 6, pp. 668–676, June 1990. [Online]. Available: http://dx.doi.org/10.1145/-
78973.78977
[34] RTI, “RTI shapes demo,” 2009. [Online]. Available: http://www.rti.com/mk/-
shapes_demo.html
[35] SUN, “VirtualBox,” 2009. *Online+. Available: http://www.virtualbox.org/
[36] RTI, “University Program,” 2009. *Online+. Available: http://www.rti.com/downloads/-
university.html
[37] J. Sanchez-Monedero, J. Povedano-Molina, and J. M. Lopez-Soler, “Scalable DDS discov-
ery protocols based on bloom filters,” in Real-time and Embedded Systems Workshop,
July 2007. [Online]. Available: http://www.omg.org/news/meetings/workshops/-
rt_2007.htm
[38] J. Sanchez-Monedero and J. M. Lopez-Soler, “A DDS discovery protocol based on bloom
filters,” Master’s thesis, University of Granada, September 2009.
75
Annex A. RTI DDS Routing Service
XML Configuration Format
In this Annex, the RTI DDS Routing Service XML configuration format is defined by means of its
corresponding XML Schema (XSD). For the sake of simplicity, we have omitted any previously
existing RTI XML type. In this way, only the new defined XML types have been included.
<?xml version="1.0" encoding="UTF-8" ?>
<!--
(c) Copyright, Real-Time Innovations, Inc. 2001. All rights reserved.
No duplications, whole or partial, manual or electronic, may be made
without prior written permission. Any such copies, or
revisions thereof, must display this notice unaltered.
This code contains trade secrets of Real-Time Innovations, Inc.
-->
<!-- ======================================================= -->
<!-- RTI DDS Routing Service XML Schema File -->
<!-- ======================================================= -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- ======================================================= -->
<!-- Main Elements -->
<!-- ======================================================= -->
<xs:element name="dds">
<xs:annotation>
<xs:documentation>Configuration of RTI DDS and RTI DDS Services.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="routing_service" />
<xs:element ref="transformation_class_library" />
<xs:element name="types" type="typesDecl" />
<xs:element name="qos_library" type="qosLibrary" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="routing_service">
<xs:annotation>
<xs:documentation> This element allows configuring the DDS Router Service.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="remote_access" minOccurs="0" maxOccurs="1" />
<xs:element ref="domain_route" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="name" use="optional" type="xs:NCName" />
<xs:attribute name="group_name" use="optional" type="xs:NCName">
<xs:annotation>
<xs:documentation>Includes this router service into a group of other potential
DDS on the WAN: The DDS Routing Service
76
router services with the same name. Routers in the same group will
ignore each other. </xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
</xs:element>
<xs:element name="transformation_class_library">
<xs:annotation>
<xs:documentation>A library of Transformation Classes.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="transformation_class" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="name" use="required" type="xs:NCName" />
</xs:complexType>
</xs:element>
<xs:element name="transformation_class">
<xs:annotation>
<xs:documentation>Specifies the kind of a data transformation, which is loaded from
an external DLL. In order to achieve that, this element should define a route to
the DLL and the proper functions for performing the transformation of the data.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="input_type_name" minOccurs="0" maxOccurs="1"
type="string_TRANSFCLASS_INPUT_TYPE_NAME" />
<xs:element name="output_type_name" minOccurs="0" maxOccurs="1"
type="string_TRANSFCLASS_OUTPUT_TYPE_NAME" />
<xs:element name="dll" minOccurs="1" maxOccurs="1" type="xs:string" />
<xs:element name="load_function" minOccurs="1" maxOccurs="1" type="xs:string" />
<xs:element name="unload_function" minOccurs="1" maxOccurs="1" type="xs:string" />
<xs:element name="create_transformation_function" minOccurs="1" maxOccurs="1"
type="xs:string" />
<xs:element name="delete_transformation_function" minOccurs="1" maxOccurs="1"
type="xs:string" />
<xs:element name="modify_transformation_function" minOccurs="1" maxOccurs="1"
type="xs:string" />
<xs:element name="transform_function" minOccurs="1" maxOccurs="1" type="xs:string"
/>
</xs:all>
<xs:attribute name="name" use="required" type="xs:NCName" />
</xs:complexType>
</xs:element>
<xs:element name="domain_route">
<xs:annotation>
<xs:documentation>This element defines a mapping between two different domain
participants using different routes with specific QoS profiles. Contains two
participants beetween which data can be routed and one or more sessions.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="participant_1" type="domain_route_participant" minOccurs="1"
maxOccurs="1" />
<xs:element name="participant_2" type="domain_route_participant" minOccurs="1"
maxOccurs="1" />
<xs:element name="session" type="session" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
</xs:element>
<!-- ======================================================= -->
<!-- Complex Types: Domain Route Elements -->
<!-- ======================================================= -->
<xs:complexType name="domain_route_participant">
<xs:annotation>
<xs:documentation>One of the two participants of a domain route. You can configure
Annex A. RTI DDS Routing Service XML Configuration Format
77
its domain id and its QoS. </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="domain_id" type="positiveInteger_DOMAIN_ID" minOccurs="1" maxOc-
curs="1" />
<xs:element name="participant_qos" type="domainparticipantQosProfileChild" minOc-
curs="0" maxOccurs="1" />
<xs:element name="registered_type" type="domainParticipantRegisteredType" minOc-
curs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="session">
<xs:annotation>
<xs:documentation>Defines the execution unit for a Domain Route. A Session has
associated a read/write thread, a waitset, a publisher, a subscriber and one
or more Topic and Auto Topic Routes.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="thread" type="thread" minOccurs="0" maxOccurs="1" />
<xs:element name="wait_set" type="wait_set" minOccurs="0" maxOccurs="1" />
<xs:element name="publisher_qos" type="publisherQosProfileChild" minOccurs="0" max-
Occurs="1" />
<xs:element name="subscriber_qos" type="subscriberQosProfileChild" minOccurs="0"
maxOccurs="1" />
<xs:choice maxOccurs="unbounded">
<xs:element name="auto_topic_route" type="auto_topic_route" />
<xs:element name="topic_route" type="topic_route" />
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
<!-- ======================================================= -->
<!-- Complex Types: Session Elements -->
<!-- ======================================================= -->
<xs:complexType name="auto_topic_route">
<xs:annotation>
<xs:documentation>Represents a generic Topic Route which is able to bridge different
domain participants. The data are bridged between topics with the same name, but
in different domain participants. </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="publish_with_original_info" type="boolean_PUBLISH_ORIGINAL" minOc-
curs="0" maxOccurs="1" />
<xs:element name="propagate_dispose" type="boolean_PROPAGATE_DISPOSE" minOccurs="0"
maxOccurs="1" />
<xs:element name="propagate_unregister" type="boolean_PROPAGATE_UNREGISTER" minOc-
curs="0" maxOccurs="1" />
<xs:element name="input" type="auto_topic_route_input" minOccurs="1" maxOccurs="1"
/>
<xs:element name="output" type="auto_topic_route_output" minOccurs="1" maxOccurs="1"
/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
<xs:complexType name="auto_topic_route_input">
<xs:annotation>
<xs:documentation>This element is used to configure which data types and topics are
bridged to the output. It is possible to configure a content filtered
topic. </xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="allow_topic_name_filter" type="string_TOPIC_NAME" minOccurs="0"
maxOccurs="1" />
<xs:element name="allow_registered_type_name_filter" type="string_TYPE_NAME" minOc-
curs="0" maxOccurs="1" />
<xs:element name="deny_topic_name_filter" type="string_TOPIC_NAME" minOccurs="0"
maxOccurs="1" />
<xs:element name="deny_registered_type_name_filter" type="string_TYPE_NAME" minOc-
curs="0" maxOccurs="1" />
<xs:element name="datareader_qos" type="datareaderQosProfileChild" minOccurs="0"
maxOccurs="1" />
DDS on the WAN: The DDS Routing Service
78
<xs:element name="content_filter" type="topic_route_input_content_filtered_topic"
minOccurs="0" maxOccurs="1" />
<xs:element name="creation_mode" type="string_ROUTE_INPUT_CREATION_MODE_ENUM" minOc-
curs="0" maxOccurs="1" default="IMMEDIATE" />
</xs:all>
<xs:attribute name="participant" use="required"
type="string_DOMAINROUTE_PARTICIPANT_ENUM">
<xs:annotation>
<xs:documentation>Choose the participant you want as the source for this auto
topic route. The output will be the other one. </xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="auto_topic_route_output">
<xs:annotation>
<xs:documentation>This element is used to configure which data types and topics are
discovered in the output. </xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="allow_topic_name_filter" type="string_TOPIC_NAME" minOccurs="0"
maxOccurs="1" />
<xs:element name="allow_registered_type_name_filter" type="string_TYPE_NAME" minOc-
curs="0" maxOccurs="1" />
<xs:element name="deny_topic_name_filter" type="string_TOPIC_NAME" minOccurs="0"
maxOccurs="1" />
<xs:element name="deny_registered_type_name_filter" type="string_TYPE_NAME" minOc-
curs="0" maxOccurs="1" />
<xs:element name="datawriter_qos" type="datawriterQosProfileChild" minOccurs="0"
maxOccurs="1" />
<xs:element name="creation_mode" type="string_ROUTE_OUTPUT_CREATION_MODE_ENUM" mi-
nOccurs="0" maxOccurs="1" default="IMMEDIATE" />
</xs:all>
</xs:complexType>
<xs:complexType name="topic_route">
<xs:annotation>
<xs:documentation>This element represents a mapping between an input and an output
topic. The type of the input and the output is defined using the name of a type
described with the RTI DDS XML format. In addition to the definition of the input
and the output, a Topic Route can have an associated transformation.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="route_types" type="boolean_ROUTE_TYPES" minOccurs="0" maxOc-
curs="1" />
<xs:element name="publish_with_original_info" type="boolean_PUBLISH_ORIGINAL" minOc-
curs="0" maxOccurs="1" />
<xs:element name="propagate_dispose" type="boolean_PROPAGATE_DISPOSE" minOccurs="0"
maxOccurs="1" />
<xs:element name="propagate_unregister" type="boolean_PROPAGATE_UNREGISTER" minOc-
curs="0" maxOccurs="1" />
<xs:element name="input" type="topic_route_input" minOccurs="1" maxOccurs="1" />
<xs:element name="output" type="topic_route_output" minOccurs="1" maxOccurs="1" />
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element name="transformation" type="transformation_enable" />
<xs:element name="transformation_sequence"
type="topic_route_transformation_sequence" />
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
<xs:complexType name="topic_route_input">
<xs:annotation>
<xs:documentation>This element is used to configure the input of a topic route. It
is possible to set the name of the input topic, an associated QoS profile, the
type of the input data and a content filtered topic. </xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="topic_name" type="string_TOPIC_NAME" minOccurs="1" maxOccurs="1"
/>
<xs:element name="datareader_qos" type="datareaderQosProfileChild" minOccurs="0"
maxOccurs="1" />
Annex A. RTI DDS Routing Service XML Configuration Format
79
<xs:element name="registered_type_name" type="string_TYPE_NAME" minOccurs="0" maxOc-
curs="1" />
<xs:element name="content_filter" type="topic_route_input_content_filtered_topic"
minOccurs="0" maxOccurs="1" />
<xs:element name="creation_mode" type="string_ROUTE_INPUT_CREATION_MODE_ENUM" minOc-
curs="0" maxOccurs="1" default="IMMEDIATE" />
</xs:all>
<xs:attribute name="participant" use="required"
type="string_DOMAINROUTE_PARTICIPANT_ENUM">
<xs:annotation>
<xs:documentation>Choose the participant you want as the source for this topic
route. The output will be the other one. </xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="domainParticipantRegisteredType">
<xs:attribute name="name" use="required" type="xs:string">
<xs:annotation>
<xs:documentation>The name this type will be registered with</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="type_name" use="required" type="xs:string">
<xs:annotation>
<xs:documentation>The actual name the definition (type code) of this type has
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="topic_route_input_content_filtered_topic">
<xs:annotation>
<xs:documentation>A Content Filtered Topic is a Topic with filtering properties. It
makes it possible to subscribe to topics and specify that we are only interested
in a subset of the topic’s data.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="expression" type="string_expression" minOccurs="1" maxOccurs="1"
/>
<xs:element name="parameter" type="string_parameter" minOccurs="1" maxOc-
curs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="topic_route_output">
<xs:annotation>
<xs:documentation>This element is used to configure the output of a topic route. It
is possible to set the name of the output topic, an associated QoS profile and the
type of the output data. </xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="topic_name" type="string_TOPIC_NAME" minOccurs="1" maxOccurs="1"
/>
<xs:element name="datawriter_qos" type="datawriterQosProfileChild" minOccurs="0"
maxOccurs="1" />
<xs:element name="registered_type_name" type="string_TYPE_NAME" minOccurs="0" maxOc-
curs="1" />
<xs:element name="creation_mode" type="string_ROUTE_OUTPUT_CREATION_MODE_ENUM" mi-
nOccurs="0" maxOccurs="1" default="IMMEDIATE" />
</xs:all>
</xs:complexType>
<xs:complexType name="topic_route_transformation_sequence">
<xs:annotation>
<xs:documentation>This element allow setting a sequence of transformations of the
data. </xs:documentation>
</xs:annotation>
<xs:sequence minOccurs="2" maxOccurs="unbounded">
<xs:element name="transformation" type="transformation" />
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:complexType>
<xs:complexType name="transformation">
<xs:annotation>
DDS on the WAN: The DDS Routing Service
80
<xs:documentation>This is an instance of Transformation class, which transforms an
input dynamic data into an output dynamic data. In order to perform a
transformation, we need an expression describing the desired transformation.
Optionally, it supports some transformation parameters. </xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="input_type_name" minOccurs="0" maxOccurs="1"
type="string_TRANSF_INPUT_TYPE_NAME" />
<xs:element name="output_type_name" minOccurs="0" maxOccurs="1"
type="string_TRANSF_OUTPUT_TYPE_NAME" />
<xs:element name="expression" type="string_expression" minOccurs="1" maxOccurs="1"
/>
<xs:element name="parameter" type="string_parameter" minOccurs="0" maxOc-
curs="unbounded" />
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="className" use="required" type="xs:string" />
</xs:complexType>
<xs:complexType name="transformation_enable">
<xs:complexContent>
<xs:extension base="transformation">
<xs:attribute name="enabled" default="true" type="xs:boolean" />
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="thread">
<xs:annotation>
<xs:documentation>The Thread is the main concept of a Session, because controls
how the data are mapped from the input route to the output route.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="mask" type="threadKindMask" minOccurs="0" />
<xs:element name="priority" type="positiveInteger_THREAD_PRIORITY_DEFAULT" minOc-
curs="0" />
<xs:element name="stack_size" type="positiveInteger_THREAD_STACK_SIZE_DEFAULT" mi-
nOccurs="0" />
</xs:all>
</xs:complexType>
<xs:complexType name="wait_set">
<xs:annotation>
<xs:documentation>Conditions and WaitSets provide another way for RTI Data
Distribution Service to communicate status changes (including the arrival of
data). While a Listener is used to provide a callback for synchronous access,
Conditions and WaitSets provide asynchronous data access. In other words,
Listeners are notification-based and Conditions are wait-based.</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="max_event_count" minOccurs="1" maxOccurs="1"
type="xs:positiveInteger" />
<xs:element name="max_event_delay" minOccurs="1" maxOccurs="1" type="duration" />
<xs:element name="timeout" minOccurs="0" maxOccurs="1" type="duration" />
</xs:all>
</xs:complexType>
<!-- ======================================================= -->
<!-- Simple Types -->
<!-- ======================================================= -->
<xs:simpleType name="positiveInteger_DOMAIN_ID">
<xs:annotation>
<xs:documentation>ID that univocally identifies a Domain.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:nonNegativeInteger" />
</xs:simpleType>
<xs:simpleType name="string_expression">
<xs:annotation>
<xs:documentation>String with a expression that describes the expected
behavior.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
Annex A. RTI DDS Routing Service XML Configuration Format
81
<xs:simpleType name="string_parameter">
<xs:annotation>
<xs:documentation>String with a parameter that modifies the behavior of the
expression.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_QOS_PROFILE_NAME">
<xs:annotation>
<xs:documentation>Name of a QoS profile.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TYPE_NAME">
<xs:annotation>
<xs:documentation>A Type name or a Type name pattern.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TRANSF_INPUT_TYPE_NAME">
<xs:annotation>
<xs:documentation>The type name of the samples that this transformation receives. It
is required unless the transformation class already defines an input type name or
if this is the first transformation in a topic route, as it will take the type of
the topic route's input. If it is specified though, it must be the same.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TRANSFCLASS_INPUT_TYPE_NAME">
<xs:annotation>
<xs:documentation>The type name of the samples that transformations belonging to
this class receive. To create generic transformation, this parameter is optional
and can be defined in every transformation instance.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TRANSF_OUTPUT_TYPE_NAME">
<xs:annotation>
<xs:documentation>The type name of the samples that this transformation creates. It
is required unless the transformation class already defines an output type name or
if this is the last transformation in a topic route, as it will take the type of
the topic route's output. If it is specified though, it must be the same.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TRANSFCLASS_OUTPUT_TYPE_NAME">
<xs:annotation>
<xs:documentation>The type name of the samples that transformations belonging to
this class create from the input they receive. To create generic transformation,
this parameter is ptional and can be defined in every transformation instance.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_TOPIC_NAME">
<xs:annotation>
<xs:documentation>A Topic name or a Topic name pattern.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string" />
</xs:simpleType>
<xs:simpleType name="string_DOMAINROUTE_PARTICIPANT_ENUM">
<xs:restriction base="xs:string">
<xs:enumeration value="1">
<xs:annotation>
<xs:documentation>participant_1 - the first participant of this domain
route</xs:documentation>
DDS on the WAN: The DDS Routing Service
82
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:documentation>participant_2 - the second participant of this domain
route</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="boolean_ROUTE_TYPES">
<xs:annotation>
<xs:documentation>Indicate whether one end of the topic route (the input or the
output) that is expecting a type definition from the discovery data will accept one
coming from the opposite domain (default value: true)</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean" />
</xs:simpleType>
<xs:simpleType name="boolean_PUBLISH_ORIGINAL">
<xs:annotation>
<xs:documentation>If the data published by this topic route will be published with
the information of its original data writer (default value:
false)</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean" />
</xs:simpleType>
<xs:simpleType name="boolean_PROPAGATE_DISPOSE">
<xs:annotation>
<xs:documentation>If activated, when an instance is disposed on the source domain,
so will it be on the destination (by default, true)</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean" />
</xs:simpleType>
<xs:simpleType name="boolean_PROPAGATE_UNREGISTER">
<xs:annotation>
<xs:documentation>If activated, when an instance is unregistered on the source
domain, so will it be on the destination (by default, true)</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean" />
</xs:simpleType>
<xs:simpleType name="string_ROUTE_INPUT_CREATION_MODE_ENUM">
<xs:annotation>
<xs:documentation>Defines when the input (the data reader) of this topic route is
created</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="IMMEDIATE">
<xs:annotation>
<xs:documentation>The data reader is created immediately as soon as the type
code is available</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_DOMAIN_MATCH">
<xs:annotation>
<xs:documentation>The data reader is not created until a corresponding data
writer on its domain is present</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data reader is not created until the output (data writer)
of the route has been created</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_DOMAIN_OR_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data reader is not created until either a corresponding
writer on its domain is present or the output of the route has been
created</xs:documentation>
</xs:annotation>
</xs:enumeration>
Annex A. RTI DDS Routing Service XML Configuration Format
83
<xs:enumeration value="ON_DOMAIN_AND_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data reader is not created until both a corresponding
writer on its domain is present and the output of the route has been
created</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="string_ROUTE_OUTPUT_CREATION_MODE_ENUM">
<xs:restriction base="xs:string">
<xs:annotation>
<xs:documentation>Defines when the output (the data writer) of this topic route is
created</xs:documentation>
</xs:annotation>
<xs:enumeration value="IMMEDIATE">
<xs:annotation>
<xs:documentation>The data writer is created immediately as soon as the type
code is available</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_DOMAIN_MATCH">
<xs:annotation>
<xs:documentation>The data writer is not created until a corresponding data
reader on its domain is present</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data writer is not created until the input (data reader)
of the route has been created</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_DOMAIN_OR_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data writer is not created until either a corresponding
reader on its domain is present or the input of the router has been
created</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ON_DOMAIN_AND_ROUTE_MATCH">
<xs:annotation>
<xs:documentation>The data writer is not created until both a corresponding
reader on its domain is present and the input of the router has been
created</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:schema>
85
Glossary
ACK ACKNOWLEDGEMENT
API Application Programming Interface
CA California
CORBA Common Object Request Broker Architecture
CPU Central Process Unit
DCPS Data Centric Publish-Subscribe
DDS Data Distribution Service
DDSI Data Distribution Service Interoperability
DLRL Data Local Reconstruction Layer
DLL Dynamic Linked Library
DTD Document Type Definition
DTLS Datagram Transport Layer Security
EDP Endpoint Discovery Protocol
GIG Global Information Grid
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
LAN Local Area Network
NAT Network Address Translation
OMG Object Management Group
OOP Object Oriented Programming
OS Operating System
PDP Participant Discovery Protocol
PS Publish/Subscribe
QoS Quality of Service
RFP Request for Proposal
RTI Real-Time Innovations
RTPS Real-Time Publish Subscribe
SDP Simple Discovery Protocol
SEDP Simple Endpoint Discovery Protocol
SPDP Simple Participant Discovery Protocol
STUN Simple Transversal of UDP over NATs
DDS on the WAN: The DDS Routing Service
86
TCP Transmission Control Protocol
UDP User Datagram Protocol
UML Unified Modeling Language
WAN Wide Area Network
XML Extensible Markup Language
XSD XML Schema Definition