7.9. Known Issues with Transports
7.9.1. AppAck messages cannot be greater than underlying transport message size
A DataReader with acknowledgment_kind (in the ReliabilityQosPolicy) set to DDS_APPLICATION_AUTO_ACKNOWLEDGMENT_MODE or DDS_APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE cannot send AppAck messages greater than the underlying transport message size.
If a DataReader tries to send an AppAck message greater than the transport message size, Connext will print the following error message:
COMMENDFacade_sendAppAck:!add APP_ACK to MIG
COMMENDSrReaderService_sendAppAck:!send APP_ACK
PRESPsService_onReaderAppAckSendEvent:!send acknowledgment
To recover from the above error, the DataReader must acknowledge samples until the size of the AppAck message goes below the transport message size threshold.
Why does an AppAck message increase its size? An AppAck message contains a list of sequence number intervals where each interval represents a set of consecutive sequence numbers that have been already acknowledged. As long as samples are acknowledged in order, the AppAck message will always have a single interval. However, when samples are acknowledged out of order, the number of intervals and the size of the AppAck will increase.
For more information, see the “Application Acknowledgment” section in the Core Libraries User’s Manual.
[RTI Issue ID CORE-5329]
7.9.2. DataReader cannot persist AppAck messages greater than 32767 bytes
A DataReader using durable reader state, whose acknowledgment_kind (in the ReliabilityQosPolicy) is set to DDS_APPLICATION_AUTO_ACKNOWLEDGMENT_MODE or DDS_APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE, cannot persist an AppAck message greater than 32767 bytes.
To recover from the previous error, the DataReader must acknowledge samples until the size of the AppAck message goes below the transport message size threshold.
For more information, see the section “Durable Reader State,” in the Core Libraries User’s Manual.
[RTI Issue ID CORE-5360]
7.9.4. Communication may not be reestablished in some IP mobility scenarios
If you have two Connext applications in different nodes and they change their IP address at the same time, they may not reestablish communication. This situation may happen in the following scenario:
The applications see each other only from one single network.
The IP address change happens at the same time in the network interface cards (NICs) that are in the network that is in common for both applications.
The IP address change on one of the nodes happens before the arrival of the DDS discovery message propagating the address change from the other side.
[RTI Issue ID CORE-8260]
7.9.6. Network Capture does not support frames larger than 65535 bytes
Network capture does not support frames larger than 65535 bytes. This limitation affects the TCP transport protocol if the message_size_max property is set to a value larger than the default one.
[RTI Issue ID CORE-11083]
7.9.8. Ungracefully terminated QNX processes using SHMEM transport prevents startup of new processes due to unclosed POSIX semaphores (QNX 7.0 and earlier)
If a QNX 7.0 or earlier 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 wait forever for that semaphore to be released.
Workaround for QNX 7.0 and earlier: to enable new applications to start, RTI recommends stopping all applications, then cleaning up the Inter-Process Communication (IPC) resources before starting new applications.
This problem is resolved for QNX 7.1, as described in the fix for [Critical] Ungracefully terminated QNX processes using SHMEM transport prevented startup of new processes due to unclosed POSIX semaphores.
[RTI Issue ID CORE-9434]