RTI Connext
Core Libraries and Utilities
User’s Manual
Part 1 — Introduction
Chapters
Version 5.0
© 2012
All rights reserved.
Printed in U.S.A. First printing.
August 2012.
Trademarks
Copy and Use Restrictions
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form (including electronic, mechanical, photocopy, and facsimile) without the prior written permission of Real- Time Innovations, Inc. The software described in this document is furnished under and subject to the RTI software license agreement. The software may be used or copied only under the terms of the license agreement.
Note: In this section, "the Software" refers to
This product implements the DCPS layer of the Data Distribution Service (DDS) specification version 1.2 and the DDS Interoperability Wire Protocol specification version 2.1, both of which are owned by the Object Management, Inc. Copyright
Portions of this product were developed using ANTLR (www.ANTLR.org). This product includes software developed by the University of California, Berkeley and its contributors.
Portions of this product were developed using AspectJ, which is distributed per the CPL license. AspectJ source code may be obtained from Eclipse. This product includes software developed by the University of California, Berkeley and its contributors.
Portions of this product were developed using MD5 from Aladdin Enterprises.
Portions of this product include software derived from Fnmatch, (c) 1989, 1993, 1994 The Regents of the University of California. All rights reserved. The Regents and contributors provide this software "as is" without warranty.
Portions of this product were developed using EXPAT from Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Technical Support
232 E. Java Drive
Sunnyvale, CA 94089
Phone: |
(408) |
Email: |
support@rti.com |
Website: |
Available Documentation
To get you up and running as quickly as possible, we have divided the RTI® Connext™ (formerly, RTI Data Distribution Service) documentation into several parts.
❏Getting Started Guide
If you want to use the Connext Extensible Types feature, please read:
• Addendum for Extensible Types (RTI_CoreLibrariesAndUtilities_GettingStarted _ExtensibleTypesAddendum.pdf) Extensible Types allow you to define data types in a more flexible way. Your data types can evolve over
If you are using Connext on an embedded platform or with a database, you will find additional documents that specifically address these configurations:
•Getting Started Guide Addendum for Embedded Systems (RTI_CoreLibrariesAndUtilities_GettingStarted _EmbeddedSystemsAddendum.pdf)
•Addendum for Database Setup (RTI_CoreLibrariesAndUtilities_GettingStarted _DatabaseAddendum.pdf).
❏What’s New
❏Release Notes and Platform Notes (RTI_CoreLibrariesAndUtilities_ReleaseNotes.pdf and
❏Core Libraries and Utilities User’s Manual (RTI_CoreLibrariesAndUtilities
❏API Reference Documentation (ReadMe.html, RTI_CoreLibrariesAndUtilities
iii
The Programming How To's provide a good place to begin learning the APIs. These are hyperlinked code snippets to the full API documentation. From the ReadMe.html file, select one of the supported programming languages, then scroll down to the Programming How To’s. Start by reviewing the Publication Example and Subscription Example, which provide
Connext.
Many readers will also want to look at additional documentation available online. In particular, RTI recommends the following:
❏The RTI Customer Portal, https://support.rti.com, provides access to RTI software, documentation, and support. It also allows you to log support cases. Furthermore, the portal provides detailed solutions and a free public knowledge base. To access the software, documentation or log support cases, the RTI Customer Portal requires a username and password. You will receive this in the email confirming your purchase. If you do not have this email, please contact license@rti.com. Resetting your login password can be done directly at the RTI Customer Portal.
❏
•Example Performance Test (available for C++, Java
❏Whitepapers and other
1. RTI Connext .NET language binding is currently supported for C# and C++/CLI.
iv
Contents, Part 1
|
|
iii |
|
|
|
vi |
|
|
|
vi |
|
|
|
vi |
|
|
|
vi |
|
|
|
vi |
|
|
|
vii |
|
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|
||
|
|
||
|
|||
|
|||
|
|||
|
|
2.5.1 Controlling Behavior with Quality of Service (QoS) Policies |
|
|
v
Welcome to RTI Connext
RTI Connext solutions provide a flexible data distribution infrastructure for integrating data sources of all types. At its core is the world's leading
Conventions
The terminology and example code in this manual assume you are using C++ without namespace support.
C, C++/CLI, C#, and Java APIs are also available; they are fully described in the API Reference HTML documentation.
Namespace support in C++, C++/CLI, and C# is also available; see the API Reference HTML documentation (from the Modules page, select Using DDS:: Namespace) for details.
Extensions to the DDS Standard
Connext implements the DDS Standard published by the OMG. It also includes features that are extensions to DDS. These include additional Quality of Service parameters, function calls, structure fields, etc.
Extensions also include
NDDSTransportSupport::register_transport().
Environment Variables
Connext documentation refers to pathnames that have been customized during installation. NDDSHOME refers to the installation directory of Connext.
Names of Supported Platforms
Connext runs on several different target platforms. To support this vast array of platforms, Connext separates the executable, library, and object files for each platform into individual directories.
vi
Each platform name has four parts: hardware architecture, operating system, operating system version and compiler. For example, i86Linux2.4gcc3.2 is the directory that contains files specific to Linux® version 2.4 for the Intel processor, compiled with gcc version 3.2.
For a full list of supported platforms, see the Platform Notes.
Additional Resources
The details of each API (such as function parameters, return values, etc.) and examples are in the API Reference HTML documentation. In case of discrepancies between the information in this document and the API Reference HTML documentation, the latter should be considered more
vii
Chapter 1 Overview
RTI Connext (formerly, RTI Data Distribution Service) is network middleware for distributed real- time applications. Connext simplifies application development, deployment and maintenance and provides fast, predictable distribution of
With Connext, you can:
❏Perform complex
❏Customize application operation to meet various
❏Provide
❏Use a variety of transports.
This chapter introduces basic concepts of middleware and common communication models, and describes how Connext’s
1.1What is Connext?
Connext is network middleware for
Connext implements the
With Connext, systems designers and programmers start with a
1.2What is Middleware?
Middleware is a software layer between an application and the operating system. Network middleware isolates the application from the details of the underlying computer architecture, operating system and network stack (see Figure 1.1). Network middleware simplifies the development of distributed systems by allowing applications to send and receive information without having to program using
Figure 1.1 Network Middleware
Connext is middleware that insulates applications from the raw
Despite the simplicity of the model, PS middleware can handle complex patterns of information flow. The use of PS middleware results in simpler, more modular distributed applications. Perhaps most importantly, PS middleware can automatically handle all network chores, including connections, failures, and network changes, eliminating the need for user applications to program of all those special cases. What experienced network middleware developers know is that handling special cases accounts for over 80% of the effort and code.
1.3Network Communications Models
The communications model underlying the network middleware is the most important factor in how applications communicate. The communications model impacts the performance, the ease to accomplish different communication transactions, the nature of detecting errors, and the robustness to different error conditions. Unfortunately, there is no “one size fits all” approach to distributed applications. Different communications models are better suited to handle different classes of application domains.
This section describes three main types of network communications models:
❏
❏
❏
TCP is a
Figure 1.2
A
B
The
Figure 1.3
Server |
Client |
Client
request
reply |
Client |
Client
While the
❏
❏Remote Method Invocation (alternate solutions: CORBA, COM, SOAP)
❏
❏Synchronous transfers (alternate solution: CORBA)
Figure 1.4
Subscriber
Publisher
Subscriber
Publisher Subscriber
1.4Features of Connext
Connext supports mechanisms that go beyond the basic
❏determining who should receive the messages,
❏where recipients are located,
❏what happens if messages cannot be delivered.
This is made possible by how Connext allows the user to specify Quality of Service (QoS) parameters as a way to configure
Furthermore, Connext includes the following features, which are designed to meet the needs of distributed
❏
•Clear semantics for managing multiple sources of the same data.
•Efficient data transfer, customizable Quality of Service, and error notification.
•Guaranteed periodic samples, with maximum rate set by subscriptions.
•Notification by a callback routine on data arrival to minimize latency.
•Notification when data does not arrive by an expected deadline.
•Ability to send the same message to multiple computers efficiently.
❏
❏Reliable messaging Enables subscribing applications to specify reliable delivery of samples.
❏Multiple Communication Networks Multiple independent communication networks (domains) each using Connext can be used over the same physical network. Applications are only able to participate in the domains to which they belong. Individual applications can be configured to participate in multiple domains.
❏Symmetric architecture Makes your application robust:
•No central server or privileged nodes, so the system is robust to node failures.
•Subscriptions and publications can be dynamically added and removed from the system at any time.
❏Pluggable Transports Framework Includes the ability to define new transport
❏Multiple
❏
❏
❏Compliance with Standards
•API complies with the DCPS layer of the OMG’s DDS specification.
•Data types comply with OMG Interface Definition Language™ (IDL).
•Data packet format complies with the International Engineering Consortium’s (IEC’s) publicly available specification for the RTPS wire protocol.
Chapter 2
Communications
This chapter describes the formal communications model used by Connext: the
This chapter includes the following sections:
❏Data Types, Topics, Keys, Instances, and Samples (Section 2.2)
❏DataWriters/Publishers and DataReaders/Subscribers (Section 2.3)
❏Domains and DomainParticipants (Section 2.4)
❏Quality of Service (QoS) (Section 2.5)
❏Application Discovery (Section 2.6)
2.1What is DCPS?
DCPS is the portion of the OMG DDS (Data Distribution Service) Standard that addresses data- centric
The
The
In contrast, in
types of method arguments). An
Data and
2.1.1DCPS for
DCPS, and specifically the Connext implementation, is well suited for
Efficiency
Determinism
Flexible delivery bandwidth Typical
Thread awareness
Connext provides
DCPS, and thus Connext, was designed and implemented specifically to address the requirements above through configuration parameters known as QosPolicies defined by the DCPS standard (see QosPolicies (Section 4.2)). The following section introduces basic DCPS terminology and concepts.
2.2Data Types, Topics, Keys, Instances, and Samples
In
Within different programming languages there are several ‘primitive’ data types that all users of that language naturally share (integers, floating point numbers, characters, booleans, etc.). However, in any
struct Time { long year; short day; short hour; short minute; short second;
};
struct StockPrice { float price; Time timeStamp;
};
Within a set of applications using DCPS, the different applications do not automatically know the structure of the data being sent, nor do they necessarily interpret it in the same way (if, for instance, they use different operating systems, were written with different languages, or were compiled with different compilers). There must be a way to share not only the data, but also information about how the data is structured.
In DCPS, data definitions are shared among applications using OMG IDL, a language- independent means of describing data. For more information on data types and IDL, see Chapter 3.
2.2.1Data Topics — What is the Data Called?
Shared knowledge of the data types is a requirement for different applications to communicate with DCPS. The applications must also share a way to identify which data is to be shared. Data (of any data type) is uniquely distinguished by using a name called a Topic. By definition, a Topic corresponds to a single data type. However, several Topics may refer to the same data type.
Topics interconnect DataWriters and DataReaders. A DataWriter is an object in an application that tells Connext (and indirectly, other applications) that it has some values of a certain Topic. A corresponding DataReader is an object in an application that tells Connext that it wants to receive values for the same Topic. And the data that is passed from the DataWriter to the DataReader is of the data type associated with the Topic. DataWriters and DataReaders are described more in Section 2.3.
For a concrete example, consider a system that distributes stock quotes between applications. The applications could use a data type called StockPrice. There could be multiple Topics of the StockPrice data type, one for each company’s stock, such as IBM, MSFT, GE, etc. Each Topic uses the same data type.
Data Type: StockPrice
struct StockPrice { float price;
Time timeStamp;
};
Topic: “IBM”
Topic: “MSFT”
Topic: “GE”
Now, an application that keeps track of the current value of a client’s portfolio would subscribe to all of the topics of the stocks owned by the client. As the value of each stock changes, the new price for the corresponding topic is published and sent to the application.
2.2.2Samples, Instances, and Keys
The value of data associated with a Topic can change over time. The different values of the Topic passed between applications are called samples. In our
For a data type, you can select one or more fields within the data type to form a key. A key is something that can be used to uniquely identify one instance of a Topic from another instance of the same Topic. Think of a key as a way to
However, for topics with keys, a unique value for the key identifies a unique instance of the topic. Samples are then updates to particular instances of a topic. Applications can subscribe to a topic and receive samples for many different instances. Applications can publish samples of one, all, or any number of instances of a topic. Many quality of service parameters actually apply on a per instance basis. Keys are also useful for subscribing to a group of related data streams (instances) without
For example, let’s change the StockPrice data type to include the symbol of the stock. Then instead of having a Topic for every stock, which would result in hundreds or thousands of topics and related DataWriters and DataReaders, each application would only have to publish or subscribe to a single Topic, say “StockPrices.” Successive values of a stock would be presented as successive samples of an instance of “StockPrices”, with each instance corresponding to a single stock symbol.
Data Type: StockPrice
struct StockPrice { float price; Time timeStamp;
char *symbol; //@key
};
Instance 1 = (Topic: “StockPrices”) + (Key: “MSFT”)
sample a, price = $28.00
sample b, price = $27.88
Instance 2 = (Topic: “StockPrices”) + (Key: “IBM”)
sample a, price = $74.02
sample b, price = $73.50
Etc.
Just by subscribing to “StockPrices,” an application can get values for all of the stocks through a single topic. In addition, the application does not have to subscribe explicitly to any particular stock, so that if a new stock is added, the application will immediately start receiving values for that stock as well.
To summarize, the unique values of data being passed using DCPS are called samples. A sample is a combination of a Topic (distinguished by a Topic name), an instance (distinguished by a key), and the actual user data of a certain data type. As seen in Figure 2.1 on page
single type, ranging from one single instance to a whole collection of instances of that given topic for keyed data types. For more information, see Chapter 3: Data Types and Data Samples and Chapter 5: Topics.
Figure 2.1 Relationship of Topics, Keys, and Instances
|
|
|
|
|
|
|
|
a_type:instance1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Type:a_type |
|
|
|
|
|
|
Key = key1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Key = ... |
|
|
|
|
|
|
|
|
|
Topic:a_topic |
|
|
|
a_type:instance2 |
||
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Key = key2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a_type:instance3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Key = key3 |
|
|
|
|
|
|
|
|
|
By using keys, a Topic can identify a collection of
2.3DataWriters/Publishers and DataReaders/Subscribers
In DCPS, applications must use APIs to create entities (objects) in order to establish publish- subscribe communications between each other. The entities and terminology associated with the data itself have been discussed
The sending side uses objects called Publishers and DataWriters. The receiving side uses objects called Subscribers and DataReaders. Figure 2.2 illustrates the relationship of these objects.
❏An application uses DataWriters to send data. A DataWriter is associated with a single Topic. You can have multiple DataWriters and Topics in a single application. In addition, you can have more than one DataWriter for a particular Topic in a single application.
❏A Publisher is the DCPS object responsible for the actual sending of data. Publishers own and manage DataWriters. A DataWriter can only be owned by a single Publisher while a Publisher can own many DataWriters. Thus the same Publisher may be sending data for many different Topics of different data types. When user code calls the write() method on a DataWriter, the data sample is passed to the Publisher object which does the actual dissemination of data on the network. For more information, see Chapter 6: Sending Data.
❏The association between a DataWriter and a Publisher is often referred to as a publication although you never create a DCPS object known as a publication.
❏An application uses DataReaders to access data received over DCPS. A DataReader is associated with a single Topic. You can have multiple DataReaders and Topics in a single application. In addition, you can have more than one DataReader for a particular Topic in a single application.
Figure 2.2 Overview
❏A Subscriber is the DCPS object responsible for the actual receipt of published data. Subscribers own and manage DataReaders. A DataReader can only be owned by a single
Subscriber while a Subscriber can own many DataReaders. Thus the same Subscriber may receive data for many different Topics of different data types. When data is sent to an application, it is first processed by a Subscriber; the data sample is then stored in the appropriate DataReader. User code can either register a listener to be called when new data arrives or actively poll the DataReader for new data using its read() and take() methods. For more information, see Chapter 7: Receiving Data.
❏The association between a DataReader and a Subscriber is often referred to as a subscription although you never create a DCPS object known as a subscription.
Example: The
By default, each data sample is propagated individually, independently, and uncorrelated with other samples. However, an application may request that several samples be sent as a coherent set, so that they may be interpreted as such on the receiving side.
Figure 2.3 An Example of
Topic = "Newsweek" |
|
|
|
Topic = "Newsweek" |
||
|
|
Sample |
|
|
||
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
||
Publisher |
Issue for Feb. 15 |
Subscriber |
||||
|
Send |
|
|
|
Receive |
|
|
Delivery |
|
Service |
|||
|
|
|
||||
|
|
|
|
|
The
2.4Domains and DomainParticipants
You may have several independent DCPS applications all running on the same set of computers. You may want to isolate one (or more) of those applications so that it isn’t affected by the others. To address this issue, DCPS has a concept called Domains.
Domains represent logical, isolated, communication networks. Multiple applications running on the same set of hosts on different Domains are completely isolated from each other (even if they are on the same machine). DataWriters and DataReaders belonging to different domains will never exchange data.
Applications that want to exchange data using DCPS must belong to the same Domain. To belong to a Domain, DCPS APIs are used to configure and create a DomainParticipant with a specific Domain Index. Domains are differentiated by the Domain Index (an integer value). Applications that have created DomainParticipants with the same Domain Index belong to the same Domain. DomainParticipants own Topics, Publishers and Subscribers which in turn owns
DataWriters and DataReaders. Thus all DCPS Entities belong to a specific domain.
An application may belong to multiple domains simultaneously by creating multiple
DomainParticipants with different domain indices. However, Publishers/DataWriters and
Subscribers/DataReaders only belong to the domain in which they were created.
As mentioned before, multiple domains may be used for application isolation which is useful when users are testing their applications using computers on the same network or even the same computers. By assigning each user different domains, one can guarantee that the data produced by one user’s application won’t accidentally be received by another. In addition, domains may be a way to scale and construct larger systems that are composed of
For more information, see Chapter 8: Working with Domains.
2.5Quality of Service (QoS)
The
2.5.1Controlling Behavior with Quality of Service (QoS) Policies
QosPolicies control many aspects of how and when data is distributed between applications. The overall QoS of the DCPS system is made up of the individual QosPolicies for each DCPS
Entity. There are QosPolicies for Topics, DataWriters, Publishers, DataReaders, Subscribers, and DomainParticipants.
On the publishing side, the QoS of each Topic, the Topic’s DataWriter, and the DataWriter’s Publisher all play a part in controlling how and when data samples are sent to the middleware. Similarly, the QoS of the Topic, the Topic’s DataReader, and the DataReader’s Subscriber control behavior on the subscribing side.
Users will employ QosPolicies to control a variety of behaviors. For example, the DEADLINE policy sets up expectations of how often a DataReader expects to see samples. The OWNERSHIP and OWNERSHIP_STRENGTH policy are used together to configure and arbitrate whose data is passed to the DataReader when there are multiple DataWriters for the same instance of a Topic. The HISTORY policy specifies whether a DataWriter should save old data to send to new subscriptions that join the network later. Many other policies exist and they are presented in QosPolicies (Section 4.2).
Some QosPolicies represent “contracts” between publications and subscriptions. For communications to take place properly, the QosPolicies set on the DataWriter side must be compatible with corresponding policies set on the DataReader side.
For example, the RELIABILITY policy is set by the DataWriter to state whether it is configured to send data reliably to DataReaders. Because it takes additional resources to send data reliably, some DataWriters may only support a
To address this issue, and yet keep the publications and subscriptions as decoupled as possible, DCPS provides a way to detect and notify when QosPolicies set by DataWriters and DataReaders are incompatible. DCPS employs a pattern known as RxO (Requested versus Offered). The DataReader sets a “requested” value for a particular QosPolicy. The DataWriter sets an “offered” value for that QosPolicy. When Connext matches a DataReader to a DataWriter, QosPolicies are checked to make sure that all requested values can be supported by the offered values.
Note that not all QosPolicies are constrained by the RxO pattern. For example, it does not make sense to compare policies that affect only the DataWriter but not the DataReader or vice versa.
If the DataWriter can not satisfy the requested QosPolicies of a DataReader, Connext will not connect the two entities and will notify the applications on each side of the incompatibility if so configured.
For example, a DataReader sets its DEADLINE QoS to 4
In one application, the DataWriter sets its DEADLINE QoS to 2
In another application, the DataWriter sets its DEADLINE QoS to 5 seconds. It only commits to sending data at 5 second intervals. This will not satisfy the request of the DataReader. Connext will flag this incompatibility by calling
For a summary of the QosPolicies supported by Connext, see QosPolicies (Section 4.2).
2.6Application Discovery
The DCPS model provides anonymous, transparent,
So how is this all done? Ultimately, in each application for each publication, Connext must keep a list of applications that have subscribed to the same Topic, nodes on which they are located, and some additional QoS parameters that control how the data is sent. Also, Connext must keep a list of applications and publications for each of the Topics to which the application has subscribed.
This propagation of this information (the existence of publications and subscriptions and associated QoS) between applications by Connext is known as the discovery process. While the DDS (DCPS) standard does not specify how discovery occurs, Connext uses a standard protocol RTPS for both discovery and formatting
When a DomainParticipant is created, Connext sends out packets on the network to announce its existence. When an application finds out that another application belongs to the same domain, then it will exchange information about its existing publications and subscriptions and associated QoS with the other application. As new DataWriters and DataReaders are created, this information is sent to known applications.
The Discovery process is entirely configurable by the user and is discussed extensively in Chapter 14: Discovery.
Index, Part 1
A
architectures supported
C
DCPS
D
data types
E
environment variables NDDSHOME
I
IDL
N
NDDSHOME
O
P
platforms supported
definition
definition
Q
R
S
samples definition
stock quote example
definition
T
Topics