6.2.5. Reliability Protocol and Wire Representation

6.2.5.1. [Critical] Samples lost by reliable reader acknowledging samples it did not receive after remote writer update

A reliable DataReader may have lost samples by incorrectly acknowledging samples it did not receive. This could occur after a remote DataWriter update, such as if the writer had an IP mobility event or updated its QoS policy. When the reader processed this event, it began sending a periodic ACK/NACK at the nack_period to the writer until it received another message from the writer. This ACK/NACK acknowledged samples up to the last sequence number that it received from the writer, even if samples before that sequence number had not been received. When the writer received this ACK/NACK, it may have considered those samples to be fully acknowledged.

The reader could request the lost samples again, but if the reader was using VOLATILE durability, the remote writer would GAP for the samples and they would not be resent. If the reader was using TRANSIENT_LOCAL durability, the writer would resend the samples if they were still available, but if the writer had updated the send window beyond the samples being requested, the samples would not be resent and would be lost.

This issue has been resolved. If a reader receives a remote writer update from a writer that is still alive, it will not begin sending additional ACK/NACKs at the nack_period to the writer. This prevents the reader from incorrectly acknowledging samples it did not receive. If a reader receives a remote writer update from a writer that is not alive, it will send additional ACK/NACKs at the nack_period to the writer, but the bitmap will accurately represent the missing samples rather than acknowledging the last received sample. Samples are no longer lost because they are not incorrectly acknowledged.

[RTI Issue ID CORE-13611]

6.2.5.2. [Critical] Sample loss when using asynchronous publisher due to missing GAP

Samples may have been lost when using an asynchronous publisher in the following scenario:

A reader sent a NACK to the writer requesting missing samples where the first m (where m >= 0) samples should have been sent to the reader and at least the last n (where n >= 2) samples were not for the reader (for example, were filtered with a content filter).
Some (but not all) of the n samples were no longer present in the writer queue (for example, were removed due to exceeding the writer_qos.history.depth).
The next sample after the NACK bitmap sent by the reader was also not for the reader.

In this scenario, the writer may have failed to send a GAP to the reader to inform the reader about the samples that were not for the reader. The reader may then have continued to NACK for these samples and failed to progress, leading to sample loss.

[RTI Issue ID CORE-13844]

6.2.5.3. [Major] Inconsistent RTPS protocol versions broadcasted by Connext

Previously, Connext broadcasted different RTPS protocol versions in different messages. The versions are fixed and unified in this release.

[RTI Issue ID CORE-13676]