Learn About How it Works: Take the CoreDX DDS Data Distribution Service Tour

A unique on-line DDS tutorial.

Here is a valuable educational resource structured to build a strong understanding of DDS concepts. This DDS tour is unique because, rather than just reiterating the DDS Standards, it presents a clear and structured approach to grasping core DDS concepts.

Starting at the beginning, this tutorial provides an overview of Inter-Process Communication (IPC) and communications middleware. It describes some examples of some typical IPC mechanisms, comparing and contrasting them to DDS. Finally, it explains in detail the interesting and powerful core features of DDS.

  • CoreDX DDS Tour: Section 1

    CoreDX DDS Tour

    Section 1: Overview of Communications Middleware

    The CoreDX DDS Tour starts with a look at Inter-Process Communications, or IPCs, and middleware technologies in general. From this discussion, we can see how CoreDX DDS fits, and how it is different from other IPCs and middleware architectures.

  • What is CoreDX DDS?

    CoreDX DDS is an easy-to-use, cross-platform, cross-language Inter-Process Communication (IPC) library. IPC mechanisms are also referred to as Communications Middleware.

    CoreDX DDS is high-performance and low-overhead, with low latencies and high message throughput numbers. CoreDX DDS provides robust, flexible, and dynamic data communications.

    CoreDX DDS is an implementation of an international open standard: the Data Distribution Service (DDS). DDS is a data communications standard that describes low-latency data communications for distributed applications. The DDS standard defines a system, application programming interface (API), and wire protocol for type-safe network communications.

  • Why use CoreDX DDS?

    CoreDX DDS provides a Open Standards based communications architecture. Using DDS eliminates custom, proprietary software and provides standard interfaces. There are a number of benefits to this architecture, including:

    CoreDX DDS reduces development time and eases maintenance: Using a communications middleware allows software programmers to focus on domain-specific code.

    CoreDX DDS decouples applications: The CoreDX DDS architecture allows software programs to come and go and move around the network with no impact to application code.

    CoreDX DDS provides vendor independence: Open Standards and Interoperability make CoreDX DDS portable and interoperable.

    CoreDX DDS is easy to use: It provides a number of features that are difficult to implement by hand, and are not found in other IPC libraries.

  • Distributed Applications Background

    Distributed software applications are challenging to develop. This is due largely to the differences across platforms in:

    • Network Protocols
    • Operating Systems
    • Hardware Platforms
    • Coding languages

    The need for interoperability across all these aspects of distributed platforms makes this software complex to develop and costly to maintain.

  • Without Middleware...

    Creating distributed applications without a communications middleware like DDS requires using proprietary communications built directly using Operating Systems services - eg the Socket API.

    In this scenario, the software application is more than just the domain-specific code. The application defines the protocol and data types used for communications. The application is also responsible for providing Operating System and platform independence and the distributed architecture.

    This extra code for data communication makes the software application larger and more complex, and the it is expensive software to create, maintain, and extend.

  • The Role of Middleware

    Communication Middleware (also referred to as an IPC) provides a layer of abstraction between the software program and the Operating System. There are different types of Communication Middleware, but they have common goals, including:

    • Enabling Distributed Applications
    • Creating Operating System and Platform Independence
    • Providing Interoperability

    There are a number of advantages to using a Communications Middleware. Middleware technologies provide standardization, an abstraction from the Operating System, and in most cases, sophisticated features.

    Some benefits to using a Communications Middleware include:

    • Application Portability
    • Reduced Development Cost
    • Simplified Application Code

  • Types of Middleware

    Today's common middleware architectures (IPC mechanisms) can be classified as either Functional (sometimes known as Service Oriented) Middleware or Message Oriented Middleware (MOM).

    Examples of Functional / Service Oriented Middleware:

    • Remote Procedure Call (RPC)
    • Object Request Broker (ORB), eg CORBA
    • Database Access, eg SQL

    Examples of Message Oriented Middleware (MOM):

    • Publish/Subscribe, eg CoreDX DDS
    • Message Queue, eg JMS
  • Functional / Service Based Middleware

    Functional Middleware includes a client and a service (or server). The client located the server or service and makes a call to the service. The service performs some action or actions and returns the result.

    Examples of Functional Middleware include RPC, CORBA, and SQL.

    Functional Middleware is fundamentally a point-to-point architecture, and the client and service are tightly coupled.

  • Message Oriented Middleware

    Message Oriented Middleware includes a publisher or producer that generates data or messages and a subscriber or consumer that accesses the data. With MOM, the middleware manages the data.

    Examples of Message Oriented Middleware include MQSeries, Rendezvous, JMS, and CoreDX DDS.

    Message Oriented Middleware publishers and subscribers are loosely coupled.

  • CoreDX DDS Publish/Subscribe Middleware

    CoreDX DDS is a Message Oriented Middleware and extends MOM concepts.

    CoreDX DDS provides strong data typing to mazimize performance and safety of data communications.

    CoreDX DDS adds a number of Quality of Service (QoS policies) to tailor the communication behavior between publishers and subscribers. Some QoS policies include Reliable communications, saved historical data, and data filtering.

    And, CoreDX DDS is based on a formalized standard providing a portable API and interoperable wire protocol between DDS vendors.

  • CoreDX DDS Tour: Section 2

    CoreDX DDS Tour

    Section 2: Comparing Middleware/IPC Technologies

    To further the discussion of communication middleware, we now compare CoreDX DDS with some other common Inter-Process Communication options.

  • Comparing CoreDX DDS and the Socket API

    Sockets are widely used for Inter-Process Communications, and have been widely used for decades. Some form of a Socket API is included in virtually all programming and scripting languages, and Sockets are included in most Operating Systems.

    The standard Socket API requires specialized code on each side of the connection. On the 'server' side, this code performs the necessary tasks to create and configure the socket, wait for and accept a connection, and write data. On the 'client' side, this code performs the necessary tasks to create and configure the socket, attempt a connection, and read data. Further, this code is potentially different for each Operating System and coding language.

    In comparison, CoreDX DDS publishers and subscribers are easy to create and use. Simply create the publisher (or subscriber) and write (or read) data. Further, the application uses the same API for all Operating Systems and coding languages.

  • Features Included in CoreDX DDS and Sockets

    Not only is CoreDX DDS much easier to use than the Sockets API, but it is also packed with features. Features like data filtering, storage, organization,and presentation. Features like discovery of endpoints, deadlines, and ownership. These features can be accomplished using the Sockets API only if they are hand written, tested, and maintained by the application developer.

  • Comparing CoreDX DDS and CORBA (RPC)

    The CORBA API requires an Object Request Broker (ORB). All clients and servers must connect to and register with the ORB before starting communications, which is usually a stand-alone server. CORBA clients call a remote method on the server and get a response. This is a Remote Procedure Call (RPC) architecture.

    Each CoreDX DDS application contains all the necessary code for discovery and data communications - there is no server required.

  • Features Included in CoreDX DDS and CORBA (RPC)

    CoreDX DDS does not contain the single point of failure like the CORBA architecture, and furthermore, it is packed with features:

    • Automatic Discovery
    • Ability to tailor Communication Behavior
    • Interoperability

    These features are not available with CORBA.

  • Comparing CoreDX DDS and JMS

    The JMS architecture requires a server that must be configured and available before data communications can occur. JMS producers and consumers of data must locate and connect to this server. The JMS server often requires significant resources and creates a single point of failure.

    Each CoreDX DDS application contains all necessary code for discovery and communications. There is no server required. In addition, CoreDX DDS applications automatically discover each other, so they do not require configuration of end-points.

  • Features Included in CoreDX DDS and JMS

    CoreDX DDS does not contain the single point of failure like JMS, and furthermore, it is packed with features:

    • Automatic Discovery
    • Type Safety
    • Ability to tailor Communication Behavior
    • Interoperability

    These features are not available with JMS.

  • Comparing CoreDX DDS and SOA Web Services

    Web Services require a web server that is configured that has the appropriate web services modules installed. Each client must be configured with the address of the web server before the service can be called. This architecture, once again, depends on a server (in this case, the web server).

    Each CoreDX DDS application contains all necessary code for discovery and communications. There is no server to install or configure, and no single point of failure in the architecture.

  • Features Included in CoreDX DDS and SOA Web Services

    CoreDX DDS does not contain the single point of failure like the Web Services architecture, and furthermore, it is packed with features:

    • Automatic Discovery
    • Type Safety
    • Ability to tailor Communication Behavior

    These features are not available with SOA Web Services.

  • CoreDX DDS Tour: Section 3

    CoreDX DDS Tour

    Section 3: CoreDX DDS Features

    We have looked at the basic features of a few types of communication middleware and compared some common middleware architectures. This next section highlights some of the fundamental features of the CoreDX DDS technology.

    This section touches on only a few of the features of CoreDX DDS, in order to highlight the difference between CoreDX DDS and other middleware technologies. For a more in depth view of CoreDX DDS features, take a look at Why Choose CoreDX DDS?.

  • CoreDX DDS Feature: Discovery

    CoreDX DDS provides Dynamic Discovery of publishers and subscribers.

    The application does not know or configure CoreDX DDS endpoints - they can be on the same machine or across a network. There are no IP addresses or ports to configure and no look-up of servers or services. The application simply indicates an intent to publish or subscribe to data and CoreDX DDS does the rest.

    This is a unique and powerful feature of CoreDX DDS that is not found in other IPC's or common middleware technologies. Dynamic Discovery provides for a flexible deployment architecture, where applications can be added, removed, or moved to different platforms with no impact to the rest of the network.

  • CoreDX DDS Feature: Strong Type Safety

    CoreDX DDS provides strong type safety. The application specifies the Types of data that will be used for communications, and these types are passed into write() calls and returned from read() calls. CoreDX DDS includes a compiler to generate type-specific code that is called by the application.

    Strong Type Safety reduces programming errors, since type mismatches are discovered at compile time.

    Many other middleware technologies provide an API to read and write a stream of bytes, or an XML format, which does not provide this type safety.

  • CoreDX DDS Feature: QoS Policies

    CoreDX DDS provides a rich set of Quality of Service (QoS) policies to tailor data communications. QoS Policy settings affect the behavior of data communications and control diverse aspects of DDS.

    Dynamic Discovery uses QoS settings to appropriately match Producers and Consumers of data. These QoS Policies of Producers and Consumers do not necessarily have to match, but the must be compatible.

    For example, a data Producer that offers "RELIABLE" communications will meet the requirements of Consumers that request "RELIABLE" or just "BEST_EFFORT" communications. However, a data Producer that offers "BEST_EFFORT" communications will NOT meet the requirement of Consumers that request "RELIABLE" communications.

  • CoreDX DDS Feature: Interoperability

    What is Interoperability? Interoperability is the ability of DDS Implementations from different vendors/sources to communicate.

    Why do we want it? Interoperability provides increased flexibility in implementation decisions and vendor independence.

    Open Standards from the OMG allow for Interoperability: DDS API, RTPS Wire Protocol, CDR Data Encoding.

    Some vendors commit to and test Interoperability, including the makers of CoreDX DDS, Twin Oaks Computing.

    Learn more...

  • CoreDX DDS Feature: Performance

    CoreDX DDS has a low-latency communication architecture. It includes fundamental design principles aimed to meet the requirements of real-time and near-real time systems, including:

    • Minimal data copies
    • Compact encoding on the wire
    • Light-weight notification mechanisms
    • Pre-allocation of resources
    • Pre-compilation of type-specific code blocs

    Learn more...

  • CoreDX DDS Tour: Section 4

    CoreDX DDS Tour

    Section 4: CoreDX DDS Use Cases

    This section provides a number of basic examples where CoreDX DDS can be used to solve common architecture challenges. These examples are high-level and are intended to be a helpful learning resource. They are not designed provide full architectural solutions.

  • Use Case: Continuous Data

    The Continuous Data Use Case addresses a scenario with a sensor producing data and consumers of this data.

    The sensor produces data updates at a high frequency. The consumers should receive the data in near-real-time, without any significant network delays.

    Some consumers need all the data produced by the sensor, other consumers need only recent data.

  • Continuous Data Solution

    The Continuous Data Use Case is a very common application for CoreDX DDS. In this solution the following CoreDX DDS features are used:

    • BEST_EFFORT and RELIABLE Reliability QoS: Some consumers of data cannot have the network drop an occasional network packet, while for other consumers, the update frequency makes dropped packets acceptable. The Sensor application simply publishes data, without concern for which types of consumers are at the other end.
    • Time Based Filter QoS: A User Display consumer may need an update only once per second, as opposed to the 500 per second that the sensor is producing. A Time Based Filter allows the consuming application to configure this behavior, and again, the sensor application does not need to know.
    • Low Latency Communications: CoreDX DDS can support update frequencies of 500 per second (and much higher) to ensure maximum data throughput with low latencies.
  • Use Case: Reliability over Unreliable Networks

    The Reliability Use Case addresses a scenario where poor communications must use a network infrastructure that lossy, or are just old or slow. This presents a common problem - ensuring reliable data transfers in these environments.

    In this example, we look at a Package Deliver Service with a central office that tracks delivery status, and drivers with hand-held devices to scan packages as they are received or delivered.

    The wireless network used to communicate between the hand-held devices and central office is inherently unreliable. Yet it is important that the data from the hand-held devices is received by the central office.

  • Reliability over Unreliable Networks Solution

    This solution for the Reliability Use Case uses the following CoreDX DDS Features:

    • Reliable Reliability QoS: The CoreDX DDS Reliable QoS policy provides very efficient handshaking and retransmission of dropped data to guarantee written data samples will be received by all subscribing recipients. The CoreDX DDS Reliability protocol is in fact more efficient in terms of network traffic than TCP.
    • Compact Data Encoding: The compact data encoding used by CoreDX DDS over the wire provides efficient communications and reduces the network bandwidth required for sending (and re-sending) data.

    Learn more...

  • Use Case: Simulation and Test

    The Simulation and Test Use Case addresses a testing scenario where the system under test will interface with specialized equipment. For initial testing phases, simulators need to be used in place of the specialized equipment, which will not be available until later testing in the testing process.

    In many cases, different code is executed to communicate with simulators versus the actual equipment, which is not necessarily an accurate test of the system.

  • Simulation and Test Solution

    This solution for the Simulation and Test Use Case uses the following CoreDX DDS Features:

    • Publish-Subscribe Architecture: This architecture decouples producers from consumers. The test system can simply publish data and subscribe to data without knowledge of whether it is a simulator or real equipment on the other end.
    • Dynamic Discovery: Dynamic Discovery allows DDS endpoints to discover each other automatically - there is no configuration of communication end points. There are no IP addresses or port numbers to configure when moving from one test environment to another.
  • Use Case: Failover

    The Failover Use Case addresses a scenario where there are redundant servers. CoreDX DDS provides features that can be used in conjunction with other failover mechanisms to provide a robust solution.

    In this scenario there are two copies of a Data Producer. The Data Producers may be on the same machine, or on multiple machines across the network. Each Data Producer can produce the necessary data, and the Data Consumer should not see more than one copy of the data, and there cannot be an interruption in the delivery of data if one Data Producer fails.

  • Failover Solution

    This solution for the Failover Use Case uses the following CoreDX DDS Features:

    • Ownership QoS: With Exclusive Ownership, the consumer will see only one copy of the data, even if there are two or more producers writing. The consumer receives the data from the strongest producer. When that producer fails, the consumer will automatically see one copy of the data from the strongest remaining producer.
    • Reliability QoS: The Reliability QoS ensures that the one copy all data written by any of the producers will be received by the consumer. If any data is lost on the network, it will be retransmitted.
  • Use Case: State Information

    The State Information Use Case addresses a scenario where sensor devices are publishing state information. One consumer of this state information is a user display application.

    The display needs only the current state of the sensors.

    The display cannot miss updates, even if the display application starts late (after the Sensors have published their current state).

  • State Information Solution

    This solution for the State Information Use Case uses the following CoreDX DDS Features:

    • History QoS: The History QoS Policy allows the display application and sensors to specify how much history data to keep. In this case, only the current status is needed, or a History . depth = 1.
    • Reliability QoS: The display application cannot miss an update from any Sensor, so the Reliable protocol will be used.
    • Durability QoS: CoreDX DDS can keep previously published data (for example, sensor status) and deliver it to an application that starts after the data was written. In this example, the display application will start up and receive the last status published by each of the sensors.

  • Use Case: Distributing Network Load

    The State Information Use Case addresses a scenario where published sensor data needs to be stored to disk. The sensors are writing data faster than the disk I/O can handle, so it is necessary to distribute the disk I/O over several machines.

  • Distributing Network Load Solution

    This solution for the Distributing Network Load Use Case uses the following CoreDX DDS Features:

    • Content Filters: Each consumer can filter the data based on content, ensuring each machine receives a unique set of the sensor data.
    • Dynamic Discovery: New sensors and disks can be added to the architecture at any time without reconfiguration of the applications. Even the content filters can be changed dynamically.
  • CoreDX DDS Tour: Section 5

    CoreDX DDS Tour

    Section 5: CoreDX DDS in Depth

    Many of the powerful concepts provided by CoreDX DDS are connected and inter-related. This section provides a look into some of these features in a well organized and ordered manner, where each new concept will build on previously presented concepts.

    Additional resources and further information on these topics and other CoreDX DDS Features can be found at (Why Use CoreDX DDS?) and (Developing with CoreDX DDS).

  • CoreDX DDS Data Types

    With CoreDX DDS, application data types can be defined at compile time or run-time. CoreDX DDS uses data type information to:

    • Optimize marshal and unmarshal operations
    • Optimize data filtering
    • Manage data instances and keys

    CoreDX DDS provides a number of basic and complex data types, and these can be combined as needed to build application data types.

    Each CoreDX DDS Topic, DataWriter and DataReader are associated with a single application data type.

  • CoreDX DDS Keyed Data Types

    Application data types that define a key (keyed data types) imply relationships between data updates.

    A data Sample is one data update or messages.

    An Instance is any number of data Samples with the same key value. Instances enable advanced CoreDX DDS concepts:

    • Allow CoreDX DDS to organize data updates and provide sorted data to the application
    • Provide lifecycle management
    • Affect QoS policies, including History, Deadline, Resource Limits, Reader and Writer Data Lifecycle, and Filters

    The figure to the right depicts an example application data type: Temperature.

  • CoreDX DDS History QoS

    The History QoS policy allows both DataReaders and DataWriters to specify the amount of historical data to keep in the CoreDX DDS middleware. Each DataReader and DataWriter maintains a DataCache that holds historical data samples.

    For DataWriters, this historical data can be used for retransmission in Reliable communications, or for late joining DataReaders in Durable communications.

    For DataReaders, this historical information can be provided to the application on read() calls.

    The History QoS Policy allows the application to specify:

    • Kind: KEEP_LAST or KEEP_ALL. With a kind = KEEP_ALL, the number of samples kept by CoreDX DDS is bounded only by the Resource Limits QoS settings or available memory.
    • Depth: Only applicable with a Kind = KEEP_LAST, this is the number of samples CoreDX DDS will lkeep for each Instance. Providing a bound on the history allows CoreDX DDS to pre-allocate resources and bound memory usage.

  • CoreDX DDS Durability QoS

    The Durability QoS specifies how long published samples are kept for late joining subscribers. These already published samples can then be delivered to subscribers that do not exist when the original sample was published.

    There are several levels (Kinds) of Durability:

    • Kind = VOLITILE: No historical samples are maintained for late joining subscribers. This does not affect the History or Reliability QoS policies - dropped samples may still be retransmitted to existing subscribers.
    • Kind = TRANSIENT_LOCAL: Historical samples are maintained in the DataWriter. These samples will not survive an application exit, since the DataWriter will no long exist.
    • Kind = TRANSIENT: Historical samples are maintained in memory by a separate service. These samples will survive an application restart, but will be deleted on a computer restart.
    • Kind = PERSISTENT: Historical samples are maintained on permanent storage. These samples will survive a computer restart.
  • CoreDX DDS Filters

    CoreDX DDS provides filtering options for DataReaders to limit the data that is received by the application. This filtering can be performed at the sending end or receiving end, but either way, filtering reduces both network traffic and CPU load.

    Different filters can be specified by each DataReader, even those DataReaders subscribing to the same Topic. Some DataReaders may receive unfiltered data, while other set different filter criteria.

    There are two kinds of filters:

    • Content Filters are specified by an SQL-lik query.
    • Time Based Filters are specified by a duration for minimum separation between samples.

  • CoreDX DDS Content Filters

    Content filters can be implemented at the source or destination.

    The more typical use is to filter at the destination. This allows the DataWriter to publish data as usual, multicasting samples to all matched DataReaders. The DataReader applies the filter very early in the data receiving process, eliminating unnecessary processing by both CoreDX DDS and the application.

    Filtering at the source can also be beneficial. For data that will pass filters on a small number of matched DataReaders, filtering at the source not only reduces network traffic, but also does not 'wake up' threads to receive data that will just be dropped by the filter.

  • CoreDX DDS Time Based Filters

    CoreDX DDS DataReaders also have the option to filter data received by time. This allows the DataReader to receive samples no more frequency than a minimum separation.

    For example, a sensor publishes 500 updates every second. A display application subscribing to the sensor data will only refresh once per second. This display application can configure a time based filter to receive no more than one update every second. The remaining 499 updates that arrive in that second will be dropped by CoreDX DDS.

    Time based filters are applied per Instance. For example, consider 5 sensors, each publishing on a different Instance on the Temperature Topic. In this case, the display application with a time based filter minimum_separation = 1 second may receive 5 samples each second. That is, the subscribing application will receive one sample per second for each Instance.

  • CoreDX DDS Reliability

    The CoreDX DDS wire protocol uses UDP, which is a low overhead, but unreliable network protocol. CoreDX DDS allows applications to choose the reliability of data communications: either RELIABLE or BEST_EFFORT.

    The RELIABLE setting adds hand shaking and transmission functions to guarantee data delivery.

    The BEST_EFFORT setting uses the default UDP protocol, and there is no guarantee of data delivery.

    With the RELIABLE setting, retransmission of data is dependent on additional QoS Policy settings:

    • History Depth on the DataWriter must be adequate to save samples that may need to be retransmitted.
    • Resource Limits may be applied to force the publishing application to block until all subscribing applications have acknowledged already-sent data.

      The diagram to the right shows an example of BEST_EFFORT and RELIABLE communications when a published data sample is lost by the network.

  • CoreDX DDS Tour: Conclusion

    CoreDX DDS Tour

    Conclusion: Additional Resources

    We hope this tour of CoreDX DDS has provided you with a strong foundation for the many features and benefits of this extraordinary technology. Of course, there is a wealth of additional information about CoreDX DDS. The following is a list of additional resources available:

    CoreDX DDS Features...
    Try a CoreDX DDS Demonstration...
    Developer Resources...
    User Forums...