[14812] Fast-DDS RELIABILITY mode

[pinorobotics]

Hi,

We are testing Fast-DDS RELIABILITY mode and see some unexpected behavior.

We use custom RTPS publisher which creates a HelloWorld topic and announces it with the following PublicationData:

serializedData
    encapsulation kind: PL_CDR_LE (0x0003)
    encapsulation options: 0x0000
    serializedData:
        PID_UNICAST_LOCATOR (LOCATOR_KIND_UDPV4, 172.17.0.2:8081)
            parameterId: PID_UNICAST_LOCATOR (0x002f)
            parameterLength: 24
            locator
        PID_PARTICIPANT_GUID
            parameterId: PID_PARTICIPANT_GUID (0x0050)
            parameterLength: 16
            Participant GUID: ******** 00be2a39 41d5e9be 000001c1
        PID_TOPIC_NAME
            parameterId: PID_TOPIC_NAME (0x0005)
            parameterLength: 20
            topic: HelloWorldTopic
        PID_TYPE_NAME
            parameterId: PID_TYPE_NAME (0x0007)
            parameterLength: 16
            typeName: HelloWorld
        PID_ENDPOINT_GUID
            parameterId: PID_ENDPOINT_GUID (0x005a)
            parameterLength: 16
            Endpoint GUID: ******** 00be2a39 41d5e9be 00000103
        PID_KEY_HASH
            parameterId: PID_KEY_HASH (0x0070)
            parameterLength: 16
            guid: ********:00be2a39:41d5e9be:00000103
        PID_PROTOCOL_VERSION
            parameterId: PID_PROTOCOL_VERSION (0x0015)
            parameterLength: 4
            Protocol version: 2.3
        PID_VENDOR_ID
            parameterId: PID_VENDOR_ID (0x0016)
            parameterLength: 4
            vendorId: ***.*** (*******)
        PID_DURABILITY
            parameterId: PID_DURABILITY (0x001d)
            parameterLength: 4
            Durability: TRANSIENT_LOCAL_DURABILITY_QOS (0x00000001)
        PID_RELIABILITY
            parameterId: PID_RELIABILITY (0x001a)
            parameterLength: 12
            Kind: RELIABLE_RELIABILITY_QOS (0x00000002)
        PID_DURABILITY_SERVICE
            parameterId: PID_DURABILITY_SERVICE (0x001e)
            parameterLength: 28
            PID_DURABILITY_SERVICE
                lease_duration: INFINITE
                    seconds: 2147483647
                    fraction: 4294967295
                History Kind: KEEP_ALL_HISTORY_QOS (0x00000001)
                History Depth: 10
                Max Samples: 100
                Max Instances: 1
                Max Samples Per Instance: 100
        PID_DESTINATION_ORDER
            parameterId: PID_DESTINATION_ORDER (0x0025)
            parameterLength: 4
            Kind: BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS (0x00000000)
        PID_SENTINEL
            parameterId: PID_SENTINEL (0x0001)

Then it sends following messages:

• 1st RTPS message (Data submessages with writerSNs: 2, 3, 4, 5)
• 2nd RTPS message (Data submessages with writerSN: 1)

Purpose of this test is to make sure that Fast-DDS behaves acordingly with respect to RTPS Specification v2.3 (in particular 8.4.1.1 Example Behavior section 9a):

For a RELIABLE DDS DataReader, changes in its RTPS Reader’s HistoryCache are made visible to the user
application only when all previous changes (i.e., changes with smaller sequence numbers) are also visible

As subscber we use HelloWorldExample from Fast-DDS:

HelloWorldSubscriber.cpp (as taken from Fast-DDS examples):

    SubscriberAttributes Rparam;
    Rparam.topic.topicKind = NO_KEY;
    Rparam.topic.topicDataType = "HelloWorld";
    Rparam.topic.topicName = "HelloWorldTopic";
    Rparam.topic.historyQos.kind = KEEP_LAST_HISTORY_QOS;
    Rparam.topic.historyQos.depth = 30;
    Rparam.topic.resourceLimitsQos.max_samples = 50;
    Rparam.topic.resourceLimitsQos.allocated_samples = 20;
    Rparam.qos.m_reliability.kind = RELIABLE_RELIABILITY_QOS;
    Rparam.qos.m_durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS;

The results look like:

% HelloWorldExample subscriber
Starting 
Subscriber running. Please press enter to stop the Subscriber
Subscriber matched
Message HelloWorld 2 RECEIVED
Message HelloWorld 3 RECEIVED
Message HelloWorld 4 RECEIVED
Message HelloWorld 5 RECEIVED

As we can see for some reason Fast-DDS does not wait and makes data visible right away losing Message 1. This is not what is described in RTPS Specification.

Behavior observed on versions Fast-DDS v2.6.0, v2.1.1 and more

Possibly we are missing something here, any suggestions would be appreciated.

[EduPonz]

Hi @pinorobotics ,

This is indeed strange. We'd like to ask for a reproducer since you have one. Also, would you mind sharing a Wireshark capture? We would be specially interested in looking at the heartbeats messages, since that is the means that data readers use to get to know the data writers' states.

Thanks!

[pinorobotics]

Hi Eduardo,

Thank you for reply.

The captured data is attached. Naming of each capture represents order of messages.

reliability_test4-message_received_later_in_time.zip