DDS

What?

DDS（Data Distribution Service）数据分发服务是用于分布式软件应用程序通信的以数据为中心的通信协议。 它描述了通信应用程序编程接口（API）和通信语义，使数据提供者和数据使用者之间能够进行通信。

由于它是一个以数据为中心的发布订阅（DCPS: Data-Centric Publish Subscribe）模型，因此在其实现中定义了三个关键的应用程序实体：

• 发布实体(publication entities)，用于定义信息生成对象及其属性；
• 订阅实体(subscription entities)，用于定义消耗信息的对象及其属性；
• 配置实体(configuration entities)，这些实体定义作为主题传输的信息的类型，并利用其服务质量（QoS: Quality of Service）属性创建发布者和订阅者，从而确保上述实体的正确性能。

Why?

如何构建一个可靠、健壮、实时性的通信系统是很麻烦的一件事。

如：在自动驾驶系统开发过程中，需要实时且可靠的进行各种传感器数据的传输。

如果基于传统的Linux/Unix IPC（Inter-Process Communication）机制进行封装，实现起来往往非常复杂，不便于进行产品开发和大型商用项目应用。

已有解决方案：

• D-Bus系列（底层基于Socket）：FDBus、KDBus、Qt DBus、gDBus ...
• Binder（底层基于Binder driver）：Android中应用非常广泛，单拷贝，性能极高

个人觉得D-Bus系列性能欠佳（对自动驾驶来说实时性相当重要），Binder性能很强，但是依赖内核驱动支持，需要移植Google的Binder驱动。

DDS是一个标准，可以有不同的实现，如RTI的Connext，eProsima的Fast DDS。

本文只讨论eProsima Fast DDS，其特点：

• 高性能（High performance）: performance benchmarks.
• 跨平台（Multi-Platform）: Windows, Linux, Mac OS, QNX, VxWorks, iOS, Android, Raspbian.
• 易用（Easy to use）: See a hello world video tutorial here.
• 开源（Free and Open Source）: Apache License 2.0

因此选择DDS作为数据分发的中间件。

How？

Fast DDS上手起来比较容易，墙裂建议直接阅读官方文档。

在此先上一个Fast DDS的架构图：

• Application layer. The user application that makes use of the Fast DDS API for the implementation of communications in distributed systems.

• Fast DDS layer. Robust implementation of the DDS communications middleware. It allows the deployment of one or more DDS domains in which DomainParticipants within the same domain exchange messages by publishing/subscribing under a domain topic.

• RTPS layer. Implementation of the Real-Time Publish-Subscribe (RTPS) protocol for interoperability with DDS applications. This layer acts an abstraction layer of the transport layer.

• Transport Layer. Fast DDS can be used over various transport protocols such as unreliable transport protocols (UDP), reliable transport protocols (TCP), or shared memory transport protocols (SHM).

DDS layer

• QoS. The mechanism by which the behavior of each of the entities is defined.

• Listener. The mechanism by which the entities are notified of the possible events that arise during the application’s execution.

Below are listed the DDS Entities together with their description and functionality. For a more detailed explanation of each entity, their QoS, and their listeners, please refer to DDS Layer section.

• Domain. A positive integer which identifies the DDS domain. Each DomainParticipant will have an assigned DDS domain, so that DomainParticipants in the same domain can communicate, as well as isolate communications between DDS domains. This value must be given by the application developer when creating the DomainParticipants.

• DomainParticipant. Object containing other DDS entities such as publishers, subscribers, topics and multitopics. It is the entity that allows the creation of the previous entities it contains, as well as the configuration of their behavior.

• Publisher. The Publisher publishes data under a topic using a DataWriter, which reads the data from the transport. It is the entity that creates and configures the DataWriter entities it contains, and may contain one or more of them.

• DataWriter. It is the entity in charge of publishing messages. The user must provide a Topic when creating this entity which will be the Topic under which the data will be published. Publication is done by writing the data-objects as a change in the DataWriterHistory.

• DataWriterHistory. This is a list of changes to the data-objects. When the DataWriter proceeds to publish data under a specific Topic, it actually creates a change in this data. It is this change that is registered in the History. These changes are then sent to the DataReader that subscribes to that specific topic.

• Subscriber. The Subscriber subscribes to a topic using a DataReader, which reads the data from the transport. It is the entity that creates and configures the DataReader entities it contains, and may contain one or more DataReader entities.

• DataReader. It is the entity that subscribes to the topics for the reception of publications. The user must provide a subscription Topic when creating this entity. A DataReader receives the messages as changes in its HistoryDataReader.

• DataReaderHistory. It contains the changes in the data-objects that the DataReader receives as a result of subscribing to a certain Topic.

• Topic. Entity that binds Publishers’ DataWriters with Subscribers’ DataReaders.

RTPS layer

the RTPS protocol in Fast DDS allows the abstraction of DDS application entities from the transport layer. According to the graph shown above, the RTPS layer has four main Entities.

• RTPSDomain. It is the extension of the DDS domain to the RTPS protocol.

• RTPSParticipant. Entity containing other RTPS entities. It allows the configuration and creation of the entities it contains.

• RTPSWriter. The source of the messages. It reads the changes written in the DataWriterHistory and transmits them to all the RTPSReaders to which it has previously matched.

• RTPSReader. Receiving entity of the messages. It writes the changes reported by the RTPSWriter into the DataReaderHistory.

Transport layer

Fast DDS supports the implementation of applications over various transport protocols. Those are UDPv4, UDPv6, TCPv4, TCPv6 and Shared Memory Transport (SHM). By default, a DomainParticipant implements a UDPv4 and a SHM transport protocol. The configuration of all supported transport protocols is detailed in the Transport Layer section.

 

Reference：

1. eProsima Fast DDS Documentation (https://fast-dds.docs.eprosima.com/en/latest/fastdds/library_overview/library_overview.html)