4.4. Transports
4.4.1. Connext started before Windows completed duplicate address detection on network interfaces
In some cases, such as the use of Connext in a Windows service, Connext would be started before Windows completed duplicate address detection on its network interfaces. This would result in the inability to use those interfaces in Connext.
Connext will now delay the usage of Windows network interfaces until duplicate address detection completes successfully (i.e., the DadState is IpDadStatePreferred).
[RTI Issue ID CORE-13425]
4.4.2. Ungracefully terminated QNX processes using SHMEM transport prevented startup of new processes due to unclosed POSIX semaphores
If a QNX application using the shared-memory transport was ungracefully shut down, crashed, or otherwise had an abnormal termination while holding a POSIX semaphore used by the transport (for example, while sending data through the shared-memory transport), Connext applications launched after that point on the same domain may have waited forever for that semaphore to be released.
This problem has been resolved. However, the fix makes communication with applications from a previous Connext version impossible when using the shared-memory transport. If you try to use shared memory with old applications, you will see the following error message(s):
incompatible shared memory protocol detected.
Current version 5.0 not compatible with x.y.
OR
incompatible shared memory protocol detected.
Current version x.y not compatible with 5.0.
There is no way to be backwards-compatible. You will have to use other transports such as UDPv4.
[RTI Issue ID CORE-9434]
4.4.5. Overflow in default TransportMulticastMappingQosPolicy procedure
This release fixes an integer overflow in a function that maps a
multicast IP address to DataReaders. You may now see a different IP
address being assigned to a DataReader when the
TRANSPORT_MULTICAST_MAPPING QoS policy is set and the default
DDS_TransportMulticastMappingFunction_t
is used.
[RTI Issue ID CORE-13653]