dds on the wan: the dds routing service -...

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:


Author:


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:



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


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


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


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.


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.


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)


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


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


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


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”


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-


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.


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-


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.


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.


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 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) :


+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


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()


-_sessionCfg : ROUTERCfgFileSession

-_status : ROUTERSessionStatus


-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.


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 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 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 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


-_topicRouteCfg : ROUTERCfgFileTopicRoute


-_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


-_autoTopicRouteCfg : ROUTERCfgFileAutoTopicRoute

-_session : ROUTERSession

+topicRouteCounter : int

+topicRouteListDescInit : bool

+topicRouteListInit : bool

+topicRouteListDesc : REDASkiplistDescription

+topicRouteList : REDASkiplist


Figure 3.11: ROUTERAutoTopicRoute class diagram.


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


Figure 3.12: ROUTERDiscoveredEntity class diagram.


+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


Figure 3.13: ROUTERDiscoveredTopic class diagram.


+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 (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 (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


-_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


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


-_transformationCfg : ROUTERCfgFileTransformation

-_userData : void *

+transformationClass : ROUTERTransformationClass

+inputTypeCode : DDS_TypeCode

+outputTypeCode : DDS_TypeCode

+outputsample : DDS_DynamicData *


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.


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) :


+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 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[]


Figure 3.20: ROUTERCfgFileService class diagram.


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.


40

+createDefaultQos(in participantId : int) : bool

+getQos(in inputTag : bool) : bool


+setParticipantName(in qos : DDS_DomainParticipantQos, in participantId : char *) : bool


+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()


+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 *


Figure 3.21: ROUTERCfgFileDomainRoute class diagram.


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



+getFirstAutoTopicRoute() : ROUTERCfgFileAutoTopicRoute

+getNextAutoTopicRoute(in autoTopicRoute : ROUTERCfgFileAutoTopicRoute) : ROUTERCfgFileAutoTopicRoute

+getFirstTopicRoute() : ROUTERCfgFileTopicRoute

+getNextTopicRoute(in topicRoute : ROUTERCfgFileTopicRoute) : ROUTERCfgFileTopicRoute

+getDomainRoute() : ROUTERCfgFileDomainRoute

+finalize() : void


+delete() : void

+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext) :

DDS_XMLObject

+getQos() : bool

+______()


+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


+object : void *


Figure 3.22: ROUTERCfgFileSession class diagram.


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



+getFirstTransformation() : ROUTERCfgFileTransformation

+getNextTransformation(in transformation : ROUTERCfgFileTransformation) : ROUTERCfgFileTransformation

+getFirstTransformationSequence() : ROUTERCfgFileTransformationSequence

+getNextTransformationSequence(in transformationSequence : 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

+_____()

+_____()

+_____()


+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 *



+inputTypeCodeName : char *

+outputTypeCodeName : char *

+inputRegisteredTypeName : char *

+outputRegisteredTypeName : char *

+dataWriterQos : DDS_DataWriterQos

+xmlDataWriterQos : DDS_XMLDataWriterQos

+dataWriterQosIsDefault : bool

+fullName : char *

+loadedFromXML : bool


+domainRoute : ROUTERCfgFileDomainRoute


Figure 3.23: ROUTERCfgFileTopicRoute class diagram.


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 class (Figure 3.25) parses the

“<transformation_class_library>” XML. It stores the information of a group of ROU-

TERCfgFileTransformationClass classes.


42


+getQos(in readerTag : bool) : bool

+onEndElement(in tag_name : char *, in element_text : char *, in context : DDS_XMLContext) : bool



+getFirstTransformationSequence() : ROUTERCfgFileTransformationSequence

+getNextTransformationSequence(in transformationSequence : ROUTERCfgFileTransformationSequence) :


+getDomainRoute() : ROUTERCfgFileDomainRoute

+getSession() : ROUTERCfgFileSession

+finalize() : void


+delete() : void

+new(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in attr : char *, in context : DDS_XMLContext)

: 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


+object : DDS_XMLObject


Figure 3.24: ROUTERCfgFileAutoTopicRoute class diagram.



+getFirstTransformationClass() : ROUTERCfgFileTransformationClass

+getNextTransformationClass(in transformationClass : 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

+_______()

+_______()


+name : char *


Figure 3.25: ROUTERCfgFileTransformationCassLibrary class diagram.


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



+finalize() : void

+initialize(in extensionClass : DDS_XMLExtensionClass, in parentObject : DDS_XMLObject, in name : char *) : bool

+delete() : void



+____()


+name : char *

+dll : char *

+loadFunction : char *

+unloadFunction : char *

+createTransformationFunction : char *

+deleteTransformationFunction : char *

+modifyTransformationFunction : char *

+transformFunction : char *

+inputTypeName : char *

+outputTypeName : char *


Figure 3.26: ROUTERCfgFileTransformationClass class diagram.





+finalize() : void


+delete() : void


DDS_XMLContext *) : DDS_XMLObject

+_____()


+name : char *

+enabled : bool


Figure 3.27: ROUTERCfgFileTransformationSequence class diagram.


ROUTERCfgFileTransformation class (Figure 3.28) stores the information of a specific

Transformation and all its associated entities (input and output TypeCode).



+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



+_____()

+_____()


+name : char *

+className : char *

+enabled : bool *

+expression : char *

+parameterSeq

+inputTypeName : char *

+outputTypeName : char *




Figure 3.28: ROUTERCfgFileTransformation class diagram.


44


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


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.


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


[Participant!=NULL && ENTITYData!=NULL] ROUTERDiscoveredTopic:=assertDiscoveredENTITY()


ROUTERSession

bool:=isStarted()


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


<<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]



[noReferencesToTopic] <<destroy>>


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()




[drParticipantIsInCurrentRouterGroup] ignore_participant()

Figure 3.34: OnParticipantDiscovered sequence diagram.


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()



*[!lastDataWriter] ROUTERDiscoveredEntity:=Get DataWriter


removeDiscoveredPublication()

ROUTERDiscoveredTopic ROUTERDiscoveredEntity



<<destroy>>

*[!lastDataReader] ROUTERDiscoveredEntity:=Get DataReader

removeDiscoveredSubscription()



<<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.


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


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,


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",


factory->get_primitive_tc(DDS_TK_FLOAT),


structTc->add_member("my_bool",


factory->get_primitive_tc(DDS_TK_BOOLEAN),


structTc->add_member("my_string",


factory->create_string_tc(128),

DDS_TYPECODE_KEY_MEMBER, ex);

Figure 4.3: Code example for defining a static type [29].


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.


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;


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.


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.


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.


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

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">







<routing_service>

<domain_route name="DefaultDomainRoute" enabled="true">

<participant_1>

<domain_id>0</domain_id>

</participant_1>

<participant_2>


</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


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.




<routing_service>


<participant_1>


</participant_1>

<participant_2>


</participant_2>


<topic_route name="SquaresToTriangles">

<input participant="1">

<registered_type_name>

ShapeType

</registered_type_name>

<topic_name>Square</topic_name>

</input>

<output>


ShapeType


<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.

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.




<transformation_class_library

name="TestTransformationLib">



<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>


<participant_1>


</participant_1>

<participant_2>


</participant_2>


<topic_route name="SquareTransformations">



ShapeType



</input>

<output>


ShapeType



</output>

<transformation

className=

"TestTransformationLib::FieldMapping">

<expression></expression>

65



<parameter>x=x</parameter>



<parameter>y=x</parameter>



<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.

66





<routing_service>


<participant_1>


</participant_1>

<participant_2>


</participant_2>


<auto_topic_route name="All" enabled="true">

<publish_with_original_info>

true

</publish_with_original_info>


<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.


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>


</element>

<element>

<name>

dds.transport.wan_plugin.wan.create_function

</name>

<value>NDDS_Transport_WAN_create</value>


</element>

<element>

<name>dds.transport.wan_plugin.wan.server</name>

<value>192.168.1.1</value>


</element>

<element>

<name>

dds.transport.wan_plugin.wan.transport_instance_id

</name>

<value>1</value>


</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


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:


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


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" ?>









<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"

attributeFormDefault="unqualified">







<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

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:complexType>

</xs:element>







<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:complexType>







<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-


<xs:element name="propagate_dispose" type="boolean_PROPAGATE_DISPOSE" minOccurs="0"

maxOccurs="1" />

<xs:element name="propagate_unregister" type="boolean_PROPAGATE_UNREGISTER" minOc-


<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: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-


<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-


<xs:element name="datareader_qos" type="datareaderQosProfileChild" minOccurs="0"

maxOccurs="1" />


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-


<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-


<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-


<xs:element name="propagate_dispose" type="boolean_PROPAGATE_DISPOSE" minOccurs="0"

maxOccurs="1" />

<xs:element name="propagate_unregister" type="boolean_PROPAGATE_UNREGISTER" minOc-


<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: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" />


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:complexType>

<xs:complexType name="transformation">

<xs:annotation>

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="className" use="required" type="xs:string" />

</xs:complexType>

<xs:complexType name="transformation_enable">

<xs:complexContent>

<xs:extension base="transformation">


</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>







<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>


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:simpleType>

<xs:simpleType name="string_QOS_PROFILE_NAME">

<xs:annotation>

<xs:documentation>Name of a QoS profile.</xs:documentation>

</xs:annotation>


</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: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: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: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: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:simpleType>

<xs:simpleType name="string_TOPIC_NAME">

<xs:annotation>

<xs:documentation>A Topic name or a Topic name pattern.</xs:documentation>

</xs:annotation>


</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>


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: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: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: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: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


</xs:annotation>

</xs:enumeration>


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


</xs:annotation>

</xs:enumeration>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="string_ROUTE_OUTPUT_CREATION_MODE_ENUM">


<xs:annotation>

<xs:documentation>Defines when the output (the data writer) of this topic route is


</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


</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


</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


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

dds on the wan: the dds routing service -...

Documents