The Connext DDS core uses an API that is an extension of the OMG Data Distribution Service (DDS) standard API, version 1.2. RTI strives to maintain API compatibility between versions, but will conform to changes in the OMG DDS standard.
The Connext DDS core primarily consists of a library and a set of header files. In most cases, upgrading simply requires you to recompile your source using the new header files and link the new libraries. In some cases, minor modifications to your application code might be required; any such changes are noted in this document.
RTI allows you to define the data types that will be used to send and receive messages. To create code for a data type, Connext DDS includes RTI Code Generator (also known as rtiddsgen). For input, RTI Code Generator takes a data-type description (in IDL, XML, XSD, or WSDL format); RTI Code Generator generates header files (or a class in Java) that can be used to send and receive data of the defined type. It also generates code that takes care of low-level details such as transforming the data into a machine-independent representation suitable for communication.
While this is not the common case, some upgrades require you to regenerate the code produced by RTI Code Generator. The regeneration process is very simple; you only need to run the new version of RTI Code Generator using the original input IDL file. This process will regenerate the header and source files, which can then be compiled along with the rest of your application.
This section points out important differences in Connext DDS 5.x compared to 4.5f that may require changes on your part when upgrading from 4.5f (or lower) to 5.x
For QNX architectures, in release 5.x: The C++ libraries are now built without -fno-rtti and with -fexceptions. To build QNX architectures with release 5.x, you must build your C++ applications without -fno-exceptions in order to link with the RTI libraries. In summary:
Do not use -fno-exceptions when building a C++ application or the build will fail. It is not necessary to use -fexceptions, but doing so will not cause a problem.
It is no longer necessary to use -fno-rtti, but doing so will not cause a problem.
Starting with Connext DDS 5.0.0, the ContentFilter’s evaluate() function now receives a new ‘struct DDS_FilterSampleInfo *’ parameter that allows it to filter on meta-data.
The evaluate() function of previous custom filter implementations must be updated to add this new parameter.
Starting with Connext DDS 5.2.0, the return value of the function FooDataWriter::get_key_value() has changed from DDS_RETCODE_ERROR to DDS_RETCODE_BAD_PARAMETER if the instance handle passed to the function is not registered.
This change in behavior was done to align with the DDS specification (RTI Issue ID CORE-6096).
The rtiddsgen-generated type-support code for user-defined data type changed in 5.0.0 to facilitate some new features. If you have code that was generated with rtiddsgen 4.5 or lower, you must regenerate that code using the version of rtiddsgen provided with this release.
The rtiddsgen-generated type-support code for user-defined data type changed in 5.1.0 to facilitate some new features. If you have code that was generated with rtiddsgen 5.0.0 or lower, you must regenerate that code using the version of rtiddsgen provided with this release.
Starting with Connext DDS 5.1.0, the default value of participant_property_string_max_length in the DomainParticipantResourceLimitsQosPolicy has been changed from 1024 characters to 2048 to accommodate new system properties (see Section 8.7, System Properties, in the RTI Connext DDS Core Libraries User’s Manual).
Starting with Connext DDS 5.1.0, the default value for participant_qos.participant_name.name has been changed from the string “[ENTITY]” to NULL to provide consistency with the default name of other entities such as DataWriters and DataReaders.
Starting with Connext DDS 5.1.0, the constant DDS_AUTO_NAME_ENTITY, which was used to assign the name “[ENTITY]” to a participant, has been removed. References to DDS_AUTO_NAME_ENTITY must be removed from Connext DDS applications.
Starting with Connext DDS 5.2.0, the signatures for some of the Time_t and Duration_t methods have changed:
Traditional C++:
Old: from_micros(DDS_UnsignedLong microseconds);
New: from_micros(DDS_UnsignedLongLong microseconds);
Old: from_millis(DDS_UnsignedLong milliseconds);
New: from_millis(DDS_UnsignedLongLong milliseconds);
Old: from_nanos(DDS_UnsignedLong nanoseconds);
New: from_nanos(DDS_UnsignedLongLong nanoseconds);
Old: from_seconds(DDS_Long seconds);
New: from_seconds(DDS_UnsignedLong seconds);
Java:
Old: from_seconds(long seconds)
New: from_seconds(int seconds)
.NET:
Old: from_micros(long microseconds)
New: from_micros(System::UInt64 microseconds)
Old: from_millis(System::UInt32 milliseconds)
New: from_millis(System::UInt64 milliseconds)
Old: from_nanos(long nanoseconds)
New: from_nanos(System::UInt64 nanoseconds)
In Connext DDS (and RTI Data Distribution Service 4.5c,d,e), we assume all platforms natively support the ‘long long’ data type. This was not the case in older versions of RTI Data Distribution Service. There is no longer a need to define RTI_CDR_SIZEOF_LONG_LONG to be 8 on some platforms in order to map the DDS ‘long long’ data type to a native ‘long long’ type.
If your Connext DDS (or RTI Data Distribution Service 4.3-4.5e) application’s data type uses a ‘double,’ ‘long long,’ ‘unsigned long long,’ or ‘long double,’ it will not be backwards compatible with applications built with RTI Data Distribution Service 4.2e or lower, unless you use the -use42eAlignment flag when generating code with rtiddsgen.
The rtiddsgen-generated type-support code for user-defined data type changed in 4.5 to facilitate some new features. If you have code that was generated using rtiddsgen 4.4 or lower, you must regenerate that code using the version of rtiddsgen provided with this release.
This issue only impacts systems using RTI Data Distribution Service 4.3.
In RTI Data Distribution Service 4.3, keys were serialized with the incorrect byte order when using the Java and .NET1The Connext DDS .NET language binding is currently supported for C# and C++/CLI. APIs for the user-defined data type, resulting in incorrect behavior in the lookup_instance() and get_key() methods when using keyed data-types to communicate between applications in these languages and other programming languages. This issue was resolved in Java starting in RTI Data Distribution Service 4.3e rev. 01 and starting in .NET in RTI Data Distribution Service 4.4b.
As a result of this change, systems using keyed data that incorporate Java or .NET applications using both RTI Data Distribution Service 4.3 and this Connext DDS release could experience problems in the lookup_instance() and get_key() methods. If you are affected by this limitation, please contact RTI Support.
If your data type contains more than one key field and at least one of the key fields except the last one is of variable size (for example, if you use a string followed by a long as the key):
RTI Data Distribution Service 4.3e, 4.4b or 4.4c DataWriters may not be compatible with RTI Data Distribution Service 4.4d or higher DataReaders.
RTI Data Distribution Service 4.3e, 4.4b or 4.4c DataReaders may not be compatible with RTI Data Distribution Service 4.4d or higher DataWriters.
Specifically, all samples will be received in those cases, but you may experience the following problems:
Samples with the same key may be identified as different instances. (For the case in which the DataWriter uses RTI Data Distribution Service 4.4d-4.5e or Connext DDS, this can only occur if the DataWriter’s disable_inline_keyhash field (in the DataWriterProtocolQosPolicy) is true (this is not the default case).
Calling lookup_instance() on the DataReader may return HANDLE_NIL even if the instance exists.
Please note that you probably would have had the same problem with this kind of data type already, even if both your DataWriter and DataReader were built with RTI Data Distribution Service 4.3e, 4.4b or 4.4c.
If you are using a C/C++ or Java IDL type that belongs to this data type category in your RTI Data Distribution Service 4.3e, 4.4b or 4.4c application, you can resolve the backwards compatibility problem by regenerating the code with version of rtiddsgen distributed with RTI Data Distribution Service 4.4d. You can also upgrade your whole system to this release.
If you are upgrading from a release prior to 4.5f and use Dynamic Data in a C++ application, you may need to make a minor code change to avoid a compilation error.
The error would be similar to:
MyFile.cpp:1060: error: could not convert ‘{0u, 4294967295u, 4294967295u, 0u}’ to ‘DDS_DynamicDataTypeSerializationProperty_t MyFile.cpp:1060: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0 MyFile.cpp:1060: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x MyFile.cpp:1060: error: could not convert ‘{0l, 65536l, 1024l}’ to ‘DDS_DynamicDataProperty_t’ MyFile.cpp:1060: error: could not convert ‘{0u, 4294967295u, 4294967295u, 0u}’ to ‘DDS_DynamicDataTypeSerializationProperty_t
The code change involves using a constructor instead of a static initializer. Therefore if you have code like this:
DDS_DynamicDataTypeProperty_t properties = DDS_DynamicDataTypeProperty_t_INITIALIZER; ... typeSupport = new DDSDynamicDataTypeSupport(typeCode, properties);
Replace the above with this:
DDS_DynamicDataTypeProperty_t properties; ... typeSupport = new DDSDynamicDataTypeSupport(typeCode, properties);
Starting with RTI Data Distribution Service 4.5c (and thereby included in Connext DDS), there is a new DataWriterListener method, on_instance_replaced(), which supports the new instance replacement feature. This method provides notification that the maximum instances have been used and need to be replaced. If you are using a DataWriterListener from an older release, you may need to add this new method to your listener.
Starting with RTI Data Distribution Service 4.5c (and thereby included in Connext DDS), all the ‘count’ data types in DataReaderCacheStatus, DataReaderProtocolStatus, DataWriterCacheStatus and DataWriterProtocolStatus changed from ‘long’ to ‘long long’ in the C, C++ and .NETAPIs in order to report the correct value for Connext DDS applications that run for very long periods of time. If you have an application written with a previous release of RTI Data Distribution Service that is accessing those fields, data-type changes may be necessary.
Starting with RTI Data Distribution Service 4.4c (and thereby included in Connext DDS), two fields in DDS_RtpsReliableWriterProtocol_t have been renamed:
Old name: disable_positive_acks_decrease_sample_keep_duration_scaler
New name:disable_positive_acks_decrease_sample_keep_duration_factor
Old name: disable_positive_acks_increase_sample_keep_duration_scaler
New name: disable_positive_acks_increase_sample_keep_duration_factor
In releases prior to 4.4c, the NACK-only feature was not supported on platforms without floating-point support. Older versions of RTI Data Distribution Service will not run on these platforms because floats and doubles are used in the implementation of the NACK-only feature. In releases 4.4c and above, the NACK-only feature uses fixed-point arithmetic and the new DDS_Long "factor" fields noted above, which replace the DDS_Double "scaler" fields.
Starting with RTI Data Distribution Service 4.4b (and thereby included in Connext DDS), by default, the middleware is less restrictive (compared to older releases) on the writer side with regards to timestamps between consecutive samples: if the timestamp of the current sample is less than the timestamp of the previous sample by a small tolerance amount, write() will succeed.
If you are upgrading from RTI Data Distribution Service 4.4a or lower, and the application you are upgrading relied on the middleware to reject timestamps that ‘went backwards’ on the writer side (that is, when a sample’s timestamp was earlier than the previous sample’s), there are two ways to keep the previous, more restrictive behavior:
Starting with RTI Data Distribution Service 4.4b (and thereby included in Connext DDS), by default, the middleware is more restrictive (compared to older releases) on the reader side with regards to source and reception timestamps of a sample if DestinationOrderQosPolicy kind is set to BY_SOURCE_TIMESTAMP: if the reception timestamp of the sample is less than the source timestamp by more than the tolerance amount, the sample will be rejected.
If you are upgrading from RTI Data Distribution Service 4.4a or lower, your reader is using BY_SOURCE_TIMESTAMP, and you need the previous less restrictive behavior, set source_timestamp_tolerance to infinite on the reader side.
Starting with RTI Data Distribution Service 4.4d (and thereby included in Connext DDS) the default XML QoS Profiles file has been renamed and is installed in a new directory:
If you want to use this QoS profile, you need to set up your NDDSHOME environment variable at run time and rename the file NDDS_QOS_PROFILES.example.xml to NDDS_QOS_PROFILES.xml (i.e., by default, even if your NDDSHOME environment variable is set, this QoS profile is not used.) See Section 17.2, How to Load XML-Specified QoS Settings, in the RTI Connext DDS Core Libraries User’s Manual for details.
Starting with RTI Data Distribution Service 4.4d (and thereby included in Connext DDS), the default value for the max_objects_per_thread field in the SystemResourceLimitsQosPolicy has been changed from 512 to 1024.
Starting with RTI Data Distribution Service 4.5c (and thereby included in Connext DDS), the constructor for SampleInfoSeq has been changed from SampleInfoSeq(UInt32 maxSamples) to SampleInfoSeq(Int32 maxSamples). This was to make it consistent with other sequences.
Starting with RTI Data Distribution Service 4.5d (and thereby included in Connext DDS), the send window size of a DataWriter is set to infinite by default. This is done by changing the default values of two fields in DDS_RtpsReliableWriterProtocol_t (min_send_window_size, max_send_window_size) to DDS_LENGTH_UNLIMITED.
In RTI Data Distribution Service 4.4d, the send window feature was introduced and was enabled by default in 4.5c (with min_send_window_size = 32, max_send_window_size = 256). For DataWriters with a HistoryQosPolicy kind of KEEP_LAST, enabling the send window could cause writes to block, and possibly fail due to blocking timeout. This blocking behavior changed the expected behavior of applications using default QoS. To preserve that preestablished non-blocking default behavior, the send window size has been changed to be infinite by default starting in release 4.5d.
Users wanting the performance benefits of a finite send window will now have to configure the send window explicitly.
© 2015 RTI