Informing other participants of this.removeParticipant() call [14689]

[suneeshs]

Consider participantA and participantB both created with leaseDuration = 10s. They have discovered each other and the writers and readers in each are working as expected.

Assume the following call is executed at time = 2s: Domain::removeParticipant(participantA)

1. participantB seems to assume participantA exists until time 10s, at which point it detects the disappearance of participantA due to lack of heartbeat.
2. If I were to recreate participantA with the same configuration before the leaseDuration (= 10s) is up then participantA sporadically is not able to establish communication with participantB
3. If I create participantA with the same configuration AFTER the leaseDuration (= 10s), then the behavior is as expected.

Is there something to be done before Domain::removeParticipant(participantA) to inform participantB of the removal so that participantA can be recreated without a "wait until lease expires" time out period?

[JLBuenoLopez]

Hi @suneeshs,

The behavior you are describing is the expected one. Calling Domain::removeParticipant causes the removed Participant to send a discovery metapacket indicating that it is being removed from the communication (if you capture the network traffic of your application you will see this packet named as DATA[uP]). However, this packet is necessarily sent as BEST_EFFORT, because the Participant leaves the communication just after sending the message to the network. If this packet is lost in the network then the other Participants would not be aware of its disappearance and the Participant would not be dropped until the lease duration is expired without the lease being asserted by the Participant no longer present. That is the reason why step 2 sometimes discovers the new participantA (when the DATA[uP] has been received and the remote ParticipantB has been removed) and sometimes not (the new ParticipantA is thought to be the same as the previous one because ParticipantB has not been notified of the previous participantA removal and consequently discovery phase is not launched again so communication between the participants' endpoints is not reestablished).

I hope this information helps you understand better how DDS works.

Finally, since Fast DDS v2.0.0 a new compliant API with DDS specification has been released. This is the currently supported API and the old FastRTPS API you are using is going to be deprecated soon and is no longer receiving support. So I suggest you update to the new supported API if possible.

[suneeshs]

Thank you! This is clear to me now.