6.9. Known Issues with Transports

6.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]

6.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]

6.9.3. Discovery with Connext Micro fails when shared memory transport enabled

Given a Connext application with the shared memory transport enabled, a Connext Micro 2.4.x application will fail to discover it. This is due to a bug in Connext Micro that prevents a received participant discovery message from being correctly processed. This bug will be fixed in a future release of Connext Micro. As a workaround, you can disable the shared memory transport in the Connext application and use UDPv4 instead.

[RTI Issue ID EDDY-1615]

6.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]

6.9.5. Corrupted samples may be forwarded through Routing Service when using Zero-Copy transfer over shared memory

When using Zero Copy transfer over shared memory together with RTI Routing Service, Routing Service avoids an additional copy of the data by passing a reference to the sample from the input to the output of a route. If the sample is reused and rewritten by the original application DataWriter during the time between when the sample was received on the route input and copied into the route output buffer, the forwarded sample will contain the updated, and now invalid, values for the original sample.

This situation can be avoided in a few different ways, with various tradeoffs.

6.9.5.1. Use automatic application acknowledgment

Using automatic application acknowledgment (acknowledgment_mode = APPLICATION_AUTO_ACKNOWLEDGMENT in the Reliability QoS Policy) between the Routing Service input DataReader and its matching DataWriters will avoid the issue.

When using Zero Copy transfer over shared memory, DataWriters must loan samples using the get_loan API. Only samples that have been fully acknowledged will be returned by the get_loan API. This means that if automatic application acknowledgment is turned on, that only samples that the Routing Service has already copied and written to the route output will be available for reuse by the original DataWriter, because Routing Service does not return the loan on a sample until after it is forwarded to the route outputs.

The drawback to this approach is that it requires RELIABLE Reliability. In addition, application-level acknowledgments are not supported in Connext Micro, so this approach will not work if Connext Micro is the source of the Zero Copy samples.

6.9.5.2. Ensure that the number of available samples accounts for Routing Service processing time

Regardless of whether you are using Routing Service, it is important when using Zero Copy transfer over shared memory to size your resources so that your application can continue to write at the desired rate while the receiving applications receive and process the samples. If you are using Routing Service and cannot, or do not wish to, use automatic application acknowledgments, you must take into account the amount of time it will take to receive and forward a sample when setting writer_loaned_sample_allocation in the DATA_WRITER_RESOURCE_LIMITS QoS Policy and managing the samples in your application.

[RTI Issue ID CORE-10782]

6.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]