5.6.5. Reliability Protocol and Wire Representation

5.6.5.1. [Critical] Repair sample was not sent if the sample was smaller than either transport’s message_size_max

This issue was fixed in previous releases but not documented at those times.

Consider the following scenario:

  • The DomainParticipant is using two transports.

  • The transports have different values for message_size_max.

  • The DataWriter’s publish_mode.kind is SYNCHRONOUS.

  • The DataWriter writes a sample whose serialized size is between the two values of message_size_max.

  • The DataReader’s reliability.kind is RELIABLE.

In release 5.0.0, this sample was successfully sent as live data using the transport with the larger message_size_max. But if this sample ever had to be resent as repair data, the resend attempt would fail with the following error message:

!write resend. Reliable large data requires asynchronous writer

The problem was the inconsistency between the behavior of live data and repair data. This problem affected release 5.0.0. A fix was made in 5.3.0 (undocumented) so both the live data and repair data were successfully sent using the transport with the larger message_size_max.

Further changes were made in 5.3.1.20 and 6.0.1, as part of RTI Issue ID CORE-9287. Starting in those releases, both live data and repair data in the above scenario failed to be sent because one of the message_size_max values was too small for the sample. The send attempt failed with the following error message:

COMMENDFacade_canSampleBeSent:NOT SUPPORTED | Reliable fragmented data requires asynchronous writer.

Starting in release 7.4.0, because of the new feature Set up reliable communications for fragmented data more easily and with better performance, by removing asynchronous publishing requirement, the sample is successfully sent as live and repair data, regardless of the value of the message_size_max of the installed transports.

[RTI Issue ID CORE-9297]

5.6.5.2. [Critical] Late-joiner DataReader may have stopped receiving samples from DataWriters using a finite durability.writer_depth

A late-joining DataReader may have stopped receiving samples from a DataWriter configured with a finite durability.writer_depth. This issue might have occurred under the following conditions:

  • The DataReader was using multicast

  • The DataWriter was configured to use an asynchronous publisher

When the issue occurred, you would have observed an infinite exchange of Heartbeat messages, followed by NACK messages, on the wire without the DataWriter re-sending the samples mentioned in the NACK messages.

[RTI Issue ID CORE-14930]

5.6.5.3. [Major] inactivate_nonprogressing_readers did not always inactivate non-progressing readers

The RtpsReliableWriterProtocol_t::inactivate_nonprogressing_readers field did not always work as expected. It was possible for a non-progressing DataReader to incorrectly stay activated despite setting this field to true. Most of the time, this problem took effect when the DataReader was not progressing beyond the initial periodic NACKs (see RtpsReliableReaderProtocol_t::nack_period).

[RTI Issue ID CORE-14425]

5.6.5.4. [Major] Reliable large data performance issues due to redundant fragment repairs

In this scenario, while publishing large data reliably, a DataWriter was sending a sample and the DataReader had received some fragments from that sample. If the DataReader received a heartbeat message, the DataReader may have requested all the fragments missing from that sample (by sending a NACK_FRAG message), including the ones that had not been sent yet.

When the DataWriter received the NACK_FRAG message, this triggered the DataWriter to send redundant repair messages for those fragments that had not been sent. This behavior affected the DataWriter’s performance. Now the DataReader only requests the fragments that the DataWriter has sent and are missing.

[RTI Issue ID CORE-14599]

5.6.5.5. [Major] DataWriters with finite durability.writer_depth may have sent repairs over unicast instead of multicast

A DataWriter configured with finite durability.writer_depth is intended to use unicast to send repairs to a late-joining DataReader configured with a multicast address, then switch to multicast once the DataReader has caught up. This switch from unicast to multicast did not occur as expected. As a result, late-joining DataReaders may have continued receiving repair data via unicast instead of multicast even after catching up, potentially affecting network performance.

The issue only affected DataWriters using batching or multichannel features.

[RTI Issue ID CORE-14823]