![]() A long-standing bug of Cyclone is that a sample written immediately after a publication-matched event may never arrive at the reader that was just matched. This happened because the reader need not have completed discovery of the writer by the time the writer discovers the reader, at which point the reader ignores the sample because it either doesn't know the writer at all, or it hasn't yet seen a Heartbeat from it. That Heartbeat arrives shortly after, but by then it is too late: the reader slaves decides to accept the next sample to be written by the writer. (It has no choice, really: either you risk losing some data, or you will be requesting all historical data, which is empathically not what a volatile reader is about ...) A related issue is the handling of historical data for transient-local readers: it used to deliver this out-of-order, but that is firstly against the specification, and secondly, against reasonable expectations of those who use DDS as a mere publish-subscribe messaging system. To add insult to injury, it didn't completely handle some reordering issues with disposes ... This commit changes the way writers respond to a request for retransmission from volatile proxy readers and the way the in-sync/out-of-sync setting of a reader with respect to a proxy-writer is used. The first makes it safe for a Cyclone reader to ask a Cyclone writer for all data (all these details not being covered in the specs it errs on the reasonable side for other vendors, but that may cause the data loss mentioned above): the writer simply send a Gap message to the reader for all the sequence numbers prior to the matching. The second changes the rule for switching from out-of-sync to in-sync: that transition is now simply once the next sequence number to be delivered to the reader equals the next sequence number that will be delivered directly from the proxy writer object to all readers. (I.e., a much more intuitive notion than reaching some seemingly arbitrary sequence number.) To avoid duplicates the rule for delivery straight from a proxy writer has changed: where samples were delivered from the proxy writer to all matching readers, they are now delivered only to the matching readers that are in-sync. To avoid ordering problems, the idea that historical data can be delivered through the asynchronous delivery path even when the regular data goes through the synchronous delivery path has been abandoned. All data now always follows the same path. As these same mechanisms are used for getting historical data into transient-local readers, the ordering problem for the historical data also disappeared. The test stuff in src/core/xtests/initsampledeliv covers a lot of the interesting cases: data published before the existene of a reader, after it, mixes of volatile and transient-local. Running them takes quite a bit of time, and they are not yet integrated in the CI builds (if ever, because of that time). Note: the "conservative built-in startup" option has been removed, because it really makes no sense to keep a vague compatibility option added a decade ago "just in case" that has never been used ... Note: the workaround in the src/mpt/tests/basic/procs/hello.c (use transient-local to ensure delivery of data) has been removed, as has been its workaround for the already-fixed #146. Signed-off-by: Erik Boasson <eb@ilities.com> |
||
---|---|---|
docs/dev | ||
notes | ||
performance | ||
ports/freertos-posix | ||
src | ||
vdds-xcode/vdds-xcode.xcodeproj | ||
.gitignore | ||
.gitmodules | ||
.travis.yml | ||
appveyor.yml | ||
conanfile.txt | ||
CONTRIBUTING.md | ||
LICENSE | ||
NOTICE.md | ||
README.md |
Eclipse Cyclone DDS
Eclipse Cyclone DDS is by far the most performant and robust DDS implementation available on the market. Moreover, Cyclone DDS is developed completely in the open as an Eclipse IoT project (see eclipse-cyclone-dds).
Getting Started
Building Eclipse Cyclone DDS
In order to build Cyclone DDS you need a Linux, Mac or Windows 10 machine with the following installed on your host:
- CMake, version 3.7 or later. (Version 3.6 should work but you
will have to edit the
cmake_minimum_required
version and may have to disable building the tests.) - OpenSSL, preferably version 1.1 or later. If you wish, you can
build without support for OpenSSL by setting DDSC_ENABLE_OPENSSL to FALSE on the
cmake
command line (i.e.,cmake -DDDSC_ENABLE_OPENSSL=FALSE
../src). In that, there is no need to have openssl available. - Java JDK, version 8 or later, e.g., OpenJDK 11.
- Apache Maven, version 3.5 or later.
The Java-based components are the preprocessor and a configurator tool. The run-time libraries are pure C code, so there is no need to have Java available on "target" machines.
To obtain Eclipse Cyclone DDS, do
$ git clone https://github.com/eclipse-cyclonedds/cyclonedds.git
$ cd cyclonedds
$ mkdir build
Depending on whether you want to develop applications using Cyclone DDS or contribute to it you can follow different procedures
For application developers
To build and install the required libraries needed to develop your own applications using Cyclone DDS requires a few simple steps. There are some small differences between Linux and macOS on the one hand, and Windows on the other. For Linux or macOS:
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=<install-location> ../src
$ cmake --build .
and for Windows:
$ cd build
$ cmake -G "<generator-name>" -DCMAKE_INSTALL_PREFIX=<install-location> ../src
$ cmake --build .
where you should replace <install-location>
by the directory under which you would like to
install Cyclone DDS and <generator-name>
by one of the ways
CMake generators offer for
generating build files. For example, "Visual Studio 15 2017 Win64" would target a 64-bit build
using Visual Studio 2017.
To install it after a successful build, do:
$ cmake --build . --target install
which will copy everything to:
<install-location>/lib
<install-location>/bin
<install-location>/include/ddsc
<install-location>/share/CycloneDDS
<install-location>/etc/CycloneDDS
Depending on the installation location you may need administrator privileges.
At this point you are ready to use Eclipse Cyclone DDS in your own projects.
Note that the default build type is a release build with debug information included
(RelWithDebInfo), which is generally the most convenient type of build to use from applications
because of a good mix between performance and still being able to debug things. If you'd rather
have a Debug or pure Release build, set CMAKE_BUILD_TYPE
accordingly.
Contributing to Eclipse Cyclone DDS
We very much welcome all contributions to the project, whether that is questions, examples, bug
fixes, enhancements or improvements to the documentation, or anything else really. When considering
contributing code, it might be good to know that build configurations for Travis CI and AppVeyor are
present in the repository and that there is a test suite using CTest and CUnit that can be built
locally if desired. To build it, set the cmake variable BUILD_TESTING
to on when configuring, e.g.:
$ cd build
$ cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON ../src
$ cmake --build .
$ ctest
Such a build requires the presence of CUnit. You can install this yourself, or you can choose to instead rely on the Conan packaging system that the CI build infrastructure also uses. In that case, install Conan and do:
$ conan install ..
in the build directory prior to running cmake. For Windows, depending on the generator, you might
also need to add switches to select the architecture and build type, e.g., conan install -s arch=x86_64 -s build_type=Debug ..
This will automatically download and/or build CUnit (and, at
the moment, OpenSSL).
Documentation
The documentation is still rather limited, and at the moment only available in the sources (in the
form of restructured text files in src/docs
and Doxygen comments in the header files), or as
a
PDF. The
intent is to automate the process of building the documentation and have them available in more
convenient formats and in the usual locations.
Performance
Median small message throughput measured using the Throughput example between two Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (that's 2012 hardware ...) running Linux 3.8.13-rt14.20.el6rt.x86_64, connected via a quiet GbE and when using gcc-6.2.0 for a default (i.e., "RelWithDebInfo") build is:

This is with the subscriber in polling mode. Listener mode is marginally slower; using a waitset the
message rate for minimal size messages drops to 600k sample/s in synchronous delivery mode and about
750k samples/s in asynchronous delivery mode. The configuration is an out-of-the-box configuration,
tweaked only to increase the high-water mark for the reliability window on the writer side. For
details, see the scripts in the performance
directory and
the
data.
There is some data on roundtrip latency below.
Building and Running the Roundtrip Example
We will show you how to build and run an example program that measures latency. The examples are built automatically when you build Cyclone DDS, so you don't need to follow these steps to be able to run the program, it is merely to illustrate the process.
$ cd cyclonedds/src/examples/roundtrip
$ mkdir build
$ cd build
$ cmake ..
$ make
On one terminal start the application that will be responding to pings:
$ ./RoundtripPong
On another terminal, start the application that will be sending the pings:
$ ./RoundtripPing 0 0 0
# payloadSize: 0 | numSamples: 0 | timeOut: 0
# Waiting for startup jitter to stabilise
# Warm up complete.
# Round trip measurements (in us)
# Round trip time [us] Write-access time [us] Read-access time [us]
# Seconds Count median min 99% max Count median min Count median min
1 28065 17 16 23 87 28065 8 6 28065 1 0
2 28115 17 16 23 46 28115 8 6 28115 1 0
3 28381 17 16 22 46 28381 8 6 28381 1 0
4 27928 17 16 24 127 27928 8 6 27928 1 0
5 28427 17 16 20 47 28427 8 6 28427 1 0
6 27685 17 16 26 51 27685 8 6 27685 1 0
7 28391 17 16 23 47 28391 8 6 28391 1 0
8 27938 17 16 24 63 27938 8 6 27938 1 0
9 28242 17 16 24 132 28242 8 6 28242 1 0
10 28075 17 16 23 46 28075 8 6 28075 1 0
The numbers above were measured on Mac running a 4.2 GHz Intel Core i7 on December 12th 2018. From these numbers you can see how the roundtrip is very stable and the minimal latency is now down to 17 micro-seconds (used to be 25 micro-seconds) on this HW.
Trademarks
-
"Eclipse Cyclone DDS" and "Cyclone DDS" are trademarks of the Eclipse Foundation.
-
"DDS" is a trademark of the Object Management Group, Inc.