[RTPS_WRITER_HISTORY Error] Sequence number provided doesn't match any change in history

[fujitatomoya]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

If the many participants with security enabled, this is expected to print? with transient situation to security handshake with many participants at the same time, this error message can be seen easily. (as experimental, we have 150 participants with publishers, and single subscription can lead to print this error messages.)

this message should be tagged with Warning instead of Error if that is expected to happen?

Current behavior

it does print as error level message as below.

[RTPS_WRITER_HISTORY Error] Sequence number provided doesn't match any change in history

Steps to reproduce

1. Build with cmake -DSECURITY=ON.
2. Instantiate many SecureHelloWorldExample publishers and a subscriber. e.g test.sh 150 below.

#!/bin/bash

echo "---------- starting $1 publishers with security (each participant)"
for i in $(seq 1 $1);
do
  ./Fast-DDS/build/examples/cpp/dds/SecureHelloWorldExample/DDSSecureHelloWorldExample publisher &
done

echo "---------- starting a subscriber with participant security"
./Fast-DDS/build/examples/cpp/dds/SecureHelloWorldExample/DDSSecureHelloWorldExample subscriber &

exit 0

3. The following error message come up.

[RTPS_WRITER_HISTORY Error] Sequence number provided doesn't match any change in history

Fast DDS version/commit

So far we confirmed, this can be observed with master, V2.10.1, and V2.11.2

Platform/Architecture

Ubuntu Focal 20.04 amd64, Ubuntu Focal 20.04 arm64

Transport layer

UDPv4

Additional context

• DDS Security Specification

  8.3.2.9.1 Reliability of the Authentication Handshake
  
  Any time the state-machine indicates that a message shall be sent using the
  BuiltinParticipantStatelessMessageWriter and a reply message needs to be received by the
  BuiltinParticipantStatelessMessageReader, the DDS implementation shall cache the message
  that was sent and set a timer. If a correct reply message is not received when the timer expires,
  the state-machine shall send the same message again. This process shall be repeated multiple
  times until a correct message is received.
  

  according to the above description, this should not be categorized into error?
  because it can be expected to happen with Stateless Writer wuih QoS Best Effort.
  that said, this should be tagged with warning level message, cz security handshake eventually ends within certain amount of time with retries.

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[jiachm]

I tried initiating communication with 40 secure publishers and 40 secure subscribers but observed that the sync could not converge. I also encountered the same error as you reported.

[fujitatomoya]

@EduPonz @MiguelCompany do you guys have similar problem like this?