The message is not received in time

[263868161]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

All messages have the same priority

Current behavior

The priority of messages is different, so some messages cannot be received in real time

Steps to reproduce

There are two nodes A and B. A sends two types of messages to B, namely a and b. The first type of message is sent in a cycle of 100ms, and the B message is only sent once. At the receiving end of B, it is found that the b message is not received in time, and a message received in real time

Fast DDS version/commit

FastDDS version 2.8.0

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

UDPv4

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JLBuenoLopez]

Thanks for the report @263868161,

This does not seem to be a bug in the library but some misconfiguration of the Quality of Services (QoS). Consequently, according with Fast DDS Contributing guidelines I am converting this issue in a Support discussion.

I encourage you to read the QoS section in Fast DDS documentation. You might be interested specially on:

• HistoryQosPolicy
• ReliabilityQosPolicy

You might also be interested on Topic instances.

I hope this is helpful!

[263868161]

@JLBuenoLopez-eProsima
my settings are as follows：
sender：
DataWriterQos wqos;
wqos.history().kind = KEEP_LAST_HISTORY_QOS;
wqos.history().depth = 10;
wqos.resource_limits().max_samples = 10000;
wqos.reliable_writer_qos().times.heartbeatPeriod.seconds = 1;
wqos.reliable_writer_qos().times.heartbeatPeriod.fraction(0);
wqos.reliability().kind = RELIABLE_RELIABILITY_QOS;
wqos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;
wqos.endpoint().history_memory_policy = DYNAMIC_REUSABLE_MEMORY_MODE;
wqos.publish_mode().kind = ASYNCHRONOUS_PUBLISH_MODE;

receiver：
DataReaderQos rqos;
rqos.history().kind = KEEP_LAST_HISTORY_QOS;
rqos.history().depth = 10;
rqos.resource_limits().max_samples = 10000;
rqos.reliable_reader_qos().times.heartbeatResponseDelay.seconds = 1;
rqos.reliable_reader_qos().times.heartbeatResponseDelay.fraction(0);
rqos.reliability().kind = RELIABLE_RELIABILITY_QOS;
rqos.endpoint().history_memory_policy = DYNAMIC_REUSABLE_MEMORY_MODE;

Based on the above settings, There are two nodes A and B. A sends two types of messages to B, namely a and b. The first type of message is sent in a cycle of 100ms, and the B message is only sent once. At the receiving end of B,two questions：
1 . the b message is not received in time, and a message received in real time，why？
2 .run for a long time，a message delay will increase and stabilize at 1000（100*10） milliseconds，the reason has to do with depth，the depth remains unchanged, how to receive the message in real time？
Thank you!

[JLBuenoLopez]

Sorry, but I am not understanding what are you trying to do. You mention that you want to receive the message "in real time". What does this mean? Fast DDS takes charge of sending and receiving the message but the latency would depend on the hardware and architecture of your system.

As far as I understand, the message B which is only sent once is not being received. Looking at your configuration this can be caused by several factors:

1. Even though the DataWriter is configured as TRANSIENT_LOCAL the DataReader Durability QoS is not set and by default it is VOLATILE. Consequently, as the DDS discovery is not synchronous (DataWriter may have discovered DataReader and sent the sample, but the DataReader has not yet completed the DataWriter discovery, so the message is lost. As the Durability QoS is VOLATILE, the DataReader will not receive again the sent message).
2. The History is configured as KEEP_LAST with a depth of 10. Therefore, the B message will be overwritten by the samples sent by DataWriter A. As I suggested in my previous comment, take a look into the Topic instances because using instances you will have an independent History for each instance and thus, the B message will not be overwritten.