|
RTI Connext DDS Micro
Version 2.4.10
|
|
RTI Connext DDS Micro
Version 2.4.10
|
It is now possible to generate an example application for RTI Connext Micro using rtiddsgen. To generate an example:
rtiddsgen -language C | C++ -micro -example <IDL File>
A CMakeLists.txt file is generated that can be used with rtime-make:
rtime-make [options] --srcdir <path to CMakeLists.txt> Please refer to the generated README.txt file for details.
The DataReader and DataWriter Qos policy now includes the DDS_DestinationOrderQosPolicy.
Please refer to the DDS reference manual for details.
[RTI Issue ID MICRO-1597]
The i86Win32VS2010 libraries shipped with RTI Connext DDS Micro did not include PDB files. For this reason, when compiling an application a warning similar to the following may have been shown:
rti_mezd.lib(BuiltinTopicData.obj) : warning LNK4099: PDB 'dds_czd.pdb' was not found with 'rti_mezd.lib(BuiltinTopicData.obj)' or at '<path>\dds_czd.pdb'; linking object as if no debug info
The warning was harmless and only indicates that debug information was missing for the linked libraries.
[RTI Issue ID MICRO-1556]
All shipped RTI Connext DDS Micro libraries for Windows platforms (static release/debug, dynamic release/debug) now link with the dynamic Windows C Run-Time (CRT). Previously, the static RTI Connext DDS Micro libraries statically linked the CRT.
An existing Windows project that is linking with the RTI Connext DDS Micro static libraries must update the RunTime Library settings.
In Visual Studio, select C/C++, Code Generation, Runtime Library, select:
For command-line compilation, use:
In addition, it may be necessary to ignore the static run-time libraries in their static configurations. In Visual Studio, select Linker, Input in the project properties and add libcmtd;libcmt to the 'Ignore Specific Default Libraries' entry.
For command-line linking, add /NODEFAULTLIB:"libcmtd" /NODEFAULTLIB:"libcmt" to the linker options.
[RTI Issue ID MICRO-1572]
When an application reaches the local_writer_allocation resource limit, where subsequent calls to DDS_Publisher_create_datawriter() fail to create a new DataWriter, calling DDS_Publisher_delete_datawriter() should reclaim resources of the deleted DataWriter and allow the creation of a new DataWriter. However, in the previous release, in certain cases there was a problem with reclaiming DataWriter resources that prevented the creation of a new DataWriter.
Deleting a DataWriter or DataReader involves acknowledgements from matched applications. Thus, calling DDS_Publisher_delete_datawriter() is not an instantaneous operation so resources may not be available immediately. When this case occurs, calling DDS_Publisher_create_datawriter() after a short duration may be successful. The maximum time for a resource to be released is the maximum time a response is expected from a matched application based on the DPDE discovery plugin configuration for the built-in discovery endpoints.
[RTI Issue ID MICRO-1579]
Applications using read()/take() in on_data_available may not have received NOT_ALIVE_NO_WRITERS for instances that changed state to NOT_ALIVE_NO_WRITERS when a deleted data writer or data reader lost liveliness with a data writer caused the change. This has been fixed.
[RTI Issue ID MICRO-1580]
A reliable DataWriter can mark a matched DataReader as inactive if the DataReader fails to respond to heartbeats, as configured by max_heartbeat_retries. However, if a DataReader is marked as inactive and the Participant liveliness for the DataReader's Participant expires, a DataWriter afterwards may have failed to reclaim instances resources if unregister_instance() was called. This has been fixed.
[RTI Issue ID MICRO-1581]
A reliable DataWriter with max_samples_per_instance = 1 may have run out of instance resources if the same instance is unregistered multiple times before an acknowledgement is received from a matched DataReader. This has been fixed.
[RTI Issue ID MICRO-1583]
If an application developed with RTI Connext Core used set_qos() on an enabled endpoint or deleted and created new endpoints before RTI Connext DDS Micro had discovered the deleted endpoints, RTI Connext DDS Micro failed to discovery new endpoints. This has been fixed.
[RTI Issue ID MICRO-1588]
If there was insufficient space to store a complete log-message, the default display function would incorrectly try to print log-data beyond the log-buffer. This has been fixed.
[RTI Issue ID MICRO-1589]
Calling unregister_instance() on the same TRANSIENT_LOCAL instance may have caused a segmentation fault. The segmentation fault occured when a call to unregister_instance() is acknowledged and a later call on unregister_instance() for the same instance had not been acknowledged yet. For the segmentation fault to occur there must be more than 1 call to unregister_instance() within the history depth. This has been fixed.
[RTI Issue ID MICRO-1590]
The rtiddsgen included by this release will correctly generate C++ code for data types defined within IDL modules, when passed the "-namespace" argument. Consider the following IDL:
C++ code generated by previous releases of rtiddsgen for this IDL input would fail to build if the "-namespace" argument was used to map each IDL module to a C++ namespace.
Some of the automatically generated data types were incorrectly being exported with C linkage, effectively disabling the C++ namespaces. This would cause duplicate symbols to be detected if two types with the same name were defined in two different modules.
[RTI Issue ID MICRO-1600]
When a received RTPS message had its message and submessage headers processed, RTI Connext DDS Micro incorrectly did not validate for all cases that there was sufficient space in the message's receive buffer before accessing a field of a header. Consequently, reception of certain malformed messages could have resulted in memory access violations. The problem has been fixed by always validating for sufficient buffer. This has been fixed.
[RTI Issue ID MICRO-1614]
Some combinations of timeouts, clock resolution and resource-limits may have caused an incorrect timeout to be scheduled causing an infinite loop in the timer thread.
If multiple timers expires at the same time and the timeout is exactly:
(dp_qos.resource_limits.remote_participant_allocation +
(3*dp_qos.resource_limits.local_writer_allocation) +
(3*dp_qos.resource_limits.local_reader_allocation) +
1) / 2 * timer_resolution
the next timeout may be scheduled for immediate timeout, causing the timer thread to consume excessive CPU.
[RTI Issue ID MICRO-1617]
Limitations in CMake prior to 3.6 required forcing the compiler to a specific path. However, this resulted in warnings from CMake 3.6 and higher that this feature has been deprecated and instead the CMAKE_TRY_COMPILE_TARGET_TYPE should be used to prevent linking.
Unless there are specific needs,there are no plans to support CMake prior to 3.6 when building for VxWorks.
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
Some changes were made to how RTI Connext DDS Micro includes different ports. In versions before 2.4.9 new ports would typically update osapi_config.h and add a new directory with an implementation for the required OSAPI functions. As of 2.4.9 osapi_config.h was re-factored and OS and compiler specific functions were moved to two new files:
Please refer to Porting RTI Connext DDS Micro for details.
RTI Connext DDS Micro now includes better support for adding CMake tool-chain files and also includes a better infrastructure to manage multiple builds of RTI Connext DDS Micro. It is strongly encouraged to read Building the RTI Connext DDS Micro Source for details to get familiar with the new build environment.
RTI Connext DDS Micro ships with a more cmake tool-chain files for Linux, Darwin, Windows and VxWorks. Please refer to Building the RTI Connext DDS Micro Source for details.
[RTI Issue ID MICRO-706]
A new smaller host bundle that does not include Java Runtime Environments (JRE) is now available for download. A host bundle with JREs included is still available.
With Java being necessary for the rtiddsgen utility, rtiddsgen now picks Java based on the following order:
[RTI Issue ID MICRO-1520]
RTI Connext DDS Micro was written for 32 bit architectures and is for all practical purposes a 32 bit application. There is no advantage to compiling RTI Connext DDS Micro for a 64 bit architecture and the only reason to do so is if RTI Connext DDS Micro must execute in a 64 bit environment for other reasons, such as other applications being 64 bit or 64 bit libraries not being available.
RTI Connext DDS Micro is compiled and tested on various 64 bit architectures (iOS, MacOS, Windows, Linux, VxWorks). However, when doing so the following must be kept in mind:
RTI Connext DDS Micro supports various POSIX like operating systems. Due to small differences in the implementations not all POSIX like are equal and OS specific adaptations are necessary.
As of 2.4.9 RTI Connext DDS Micro's POSIX OSAPI implementation conforms to:
The RTI Connext DDS Micro UDP transport uses ioctl calls to enable certain socket features. The required flags are in non-standard header-files on some operating system. In addition, not all POSIX-like operating systems support all the features. RTI Connext DDS Micro checks which OS it is compiled for by testing the presence of preprocessor flags. As of 2.4.9 RTI Connext DDS Micro has been built and tested on the following operating systems that supports a POSIX API (osapi_os.h):
NOTE: An additional compile option to enable certain non-POSIX features can be enabled to unchecking the RTIME_OSAPI_ENABLE_STRICT_POSIX option in the cmake-gui or by defining the C preprocessor flag -DOSAPI_ENABLE_STRICT_POSIX=1
[RTI Issue ID MICRO-1548]
The operation DDS_DomainParticipant_find_topic() is now natively supported by the C++ API as DDSDomainParticipant::find_topic().
[RTI Issue ID MICRO-1551]
In previous releases, types must be unregistered manually from a DomainParticipant before the participant can be deleted. Now in this release, all registered types are automatically unregistered when calling DDS_DomainParticipant_delete_contained_entitites().
NOTE: It is legal to register the same type multiple times as long as it is registered with the same type-plugin. If manually unregistering a type, the type must be unregistered the same number of times as it was registered. DDS_DomainParticipant_delete_contained_entitites() ignores the number of times a type has been registered since all entities using a type are deleted first.
[RTI Issue ID MICRO-1569]
The RTI Connext DDS Micro documentation has been improved for the following topics:
[RTI Issue ID MICRO-711, MICRO-1521, MICRO-1538, MICRO-1555]
Previously, given a DomainParticipant "P1" whose endpoints are communicating with other endpoints belonging to other DomainParticipants, when P1 detected liveliness lost with one other DomainParticipant, communication incorrectly stopped with endpoints belonging to other DomainParticipants as well.
[RTI Issue ID MICRO-1543]
The function lookup_topicdescription() returned a DDSTopicDescription that caused DDSTopic::narrow() to segmentation fault when this DDSTopicDescription was passed to other functions.
DDSTopic::narrow() now correctly returns a DDSTopic when passed a DDSTopicDescription found with lookup_topicdescription().
[RTI Issue ID MICRO-1544]
delete_topic() incorrectly returned PRECONDITION_NOT_MET if there where multiple references to it (for example via find_topic()). This has been corrected and delete_topic() now returns DDS_RETCODE_OK if there are multiple references, but the reference count can be decremented.
[RTI Issue ID MICRO-1545]
When an instance is unregistered on the data writer that is best-effort with infinite deadline or using TRANSIENT_LOCAL durability, the data writer fails to free the resources being used. As a result, new instances cannot be written. This has been fixed and when an instance is unregistered all resources associated with the key is released.
[RTI Issue ID MICRO-1546]
Some memory profile tools reported an invalid read in Log.c. This was caused by an invalid pointer access when the log buffer was full and has been corrected.
[RTI Issue ID MICRO-1550]
Code generated by rtiddsgen to support user data types has been updated to properly support compilation with the flag RTI_CERT. All unsupported operations (e.g. FooTypeSupport_delete_data) are now excluded when RTI_CERT is specified.
[RTI Issue ID MICRO-1558]
The HelloWorld_cert called functions that were not supported by libraries built with RTI_CERT. This has been corrected.
[RTI Issue ID MICRO-1561]
Previously in RTI Connext DDS Micro 2.4.6, a function to validate IP hostnames as defined by RFC-952 was added and called before passing them to the OS. However, this function was too restrictive and excluded valid service names. Hostname validation is now only done directly by the OS.
[RTI Issue ID MICRO-1563]
This problem was only present when using dynamic discovery.
Consider two participants A and B. In the previous release, if A lost liveliness with B, but B did not lose liveliness with A, then A did not completely rediscover B when their connection was reestablished. The problem was that since B had not lost liveliness with A, when a connection was reestablished, B thought A was already up to date on endpoint discovery. Hence, A did not rediscover the endpoints in B. This release has fixed this issue.
[RTI Issue ID MICRO-1571]
When performing matching between A DataReader and DataWriter the entity kind was not checked. This means a keyed DataReader would match a non-keyed DataWriter and a non-keyed DataReader would match an keyed DataWriter.
This issue would can happen if two different IDLs files are used to create DataReaders and DataWriters of the same topic and type.
Note that RTI Connext DDS Micro does not support type validation. If two (or more) IDLs are used to describe the same keyed type there is no check that the key-fields are the same. Thus, even with this issue resolved there are still potential pitfalls with multiple IDLs for the same type.
[RTI Issue ID MICRO-1574]
When using static endpoint discovery (DPSE), RTI Connext Micro requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just between remote endpoints within the same participant. Note, this restriction was incorrectly documented as removed in version 2.4.1.
[RTI Issue ID MICRO-211, MICRO-1553]
Between VS2010 and VS2015 some APIs used by the RTI Connext DDS Micro OSAPI and UDP transport on Windows have been deprecated. The applicable APIs are:
Note that although these warnings can be removed by defining _WINSOCK_DEPRECATED_NO_WARNINGS, RTI Connext DDS Micro does not do so to make it clear these APIs are being used.
[RTI Issue ID MICRO-1575]
When compiling for VxWorks 6.9 with the -Wconversion flag there are compiler warnings of the type:
warning: conversion to 'DDS_Boolean' from 'int' may alter its value
These compiler warnings seem to be an issue with GCC for VxWorks and can be ignored. The problem is that returning a value from a expression seems to always be treated as an unbounded int as opposed to an int with a value of 0 or 1 as the C standard dictates.
osapi_cc_stdc.h detects the CPU endianness by checking GCC predefined macros, such as BYTE_ORDER. However, some versions of GCC does not set these macros, for example GCC for VxWorks. If osapi_cc_stdc.h does not find any of the flags, it incorrectly sets the CPU to little endian.
In this case it is important that one of the following preprocessor macros are defined:
NOTE: The VxWorks cmake toolchain file from RTI set these based on CPU type in the target name (–name option).
2.4.8 is a maintenance release with no new features.
The assignment operator for the DDS Qos, Qos policy and Status structures were not consistently supported. This has been fixed in this release as follows:
In addition, all QoS structures support the == and != operators.
[RTI Issue ID MICRO-1541]
The DPSE C++ API had methods called assert. However, this conflicts with the C assert() macro. This has been fixed in this release by updating the DPSE C++ API to be inline with the C API. The new API is:
[RTI Issue ID MICRO-1539]
RTI Connext DDS Micro Version 2.4.10
Copyright © Fri Jun 30 2017
Real-Time Innovations, Inc