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.3. QNX applications using shared-memory transport may have led to thread priority inversion issues

Running QNX applications using the Connext shared-memory transport may have led to thread priority inversion issues.

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-13745]

4.4.4. Stalled communication when using shared-memory transport

On systems with a weak memory architecture, such as Arm®, the shared-memory transport may have been corrupted due to a data race in the concurrent queue where the messages are written into the shared-memory segment. This data race may have occurred until received_message_count_max messages were sent through the transport. The corrupted transport resulted in parsing errors, which filled up the shared-memory segment. For example, you may have seen messages such as the following:

MIGInterpreter_parse:available space 24 < 28
MIGInterpreter_parse:!RTPS
MIGInterpreter_parse:INVALID from 0X1014D5A,0X7E8C7D92
NDDS_Transport_Shmem_send:failed to add data. shmem queue for port 0x1d3e is full (received_message_count_max=2880, receive_buffer_size=100971520). Try to increase queue resource limits.

This problem has been resolved. Now the data race that led to this situation cannot occur.

[RTI Issue ID CORE-13846]

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]