Is there default maximum number of participants via multicast default discovery?

[fujitatomoya]

We have seen the discovery problem if the number of participants goes beyond 100, that we cannot discover the participants anymore via on_participant_discovery. i think this is related to https://fast-dds.docs.eprosima.com/en/latest/fastdds/dds_layer/core/policy/eprosimaExtensions.html#participantresourcelimitsqos, but it does not say the default behavior.

we would like to know,

• what is the default behavior and default values.
• how we can change those configuration in application and xml configuration.

thanks in advance.

[fujitatomoya]

CC: @MiguelCompany @EduPonz @Barry-Xu-2018 @richiware

[MiguelCompany]

@fujitatomoya I'd say mutation_tries is probably the setting you are looking for, but I think the behavior should be that creating participant 101 on the same host fails.

Will check here to confirm.

[fujitatomoya]

@MiguelCompany thanks for the comment, we will try that.

we did some experimental verification to see the behavior.

using HelloWorldExample,

Case-1, cannot discover more than 100 participants

1. instantiate publisher process (participant) 100 instantly during short period.
2. start subscriber process (participant)
3. subscriber can see up to 100 publishers, but no more than 100. e.g 120

Case-2, can discover more than 100 participants

1. instantiate publisher process (participant) 120 one by one with a few seconds duration.
2. start subscriber process (participant)
3. subscriber can see 120 publishers

i am not really sure why this behavior difference happening, only difference is how quickly we create the publishers.

[fujitatomoya]

@MiguelCompany

i believe that mutation_tries is to allocate receiver ports retry, that means DataReader not Patficipant, right?

Our requirement is to have 300 participants, no matter how fast or slow we generate the participants in the DDS network. as described above comment, it seems to be dependent how fast we create the participants. if we create them in transition and short time window, it failed to create the participants more than 100.

we tried to change,

Fast-DDS/include/fastdds/rtps/attributes/RTPSParticipantAttributes.h

Lines 400 to 412 in 6898d18

	//! Memory policy for builtin readers
	MemoryManagementPolicy_t readerHistoryMemoryPolicy =
	MemoryManagementPolicy_t::PREALLOCATED_WITH_REALLOC_MEMORY_MODE;
	//! Maximum payload size for builtin readers
	uint32_t readerPayloadSize = BUILTIN_DATA_MAX_SIZE;
	//! Memory policy for builtin writers
	MemoryManagementPolicy_t writerHistoryMemoryPolicy =
	MemoryManagementPolicy_t::PREALLOCATED_WITH_REALLOC_MEMORY_MODE;
	//! Maximum payload size for builtin writers
	uint32_t writerPayloadSize = BUILTIN_DATA_MAX_SIZE;

into DYNAMIC_RESERVE_MEMORY_MODE, and it seems to be working on our case.

but we are not really sure why PREALLOCATED_WITH_REALLOC_MEMORY_MODE default setting is not working for our case. it should allocate the memory when necessary, so that it should not depend on how fast we are creating the participants?

[fujitatomoya]

@Barry-Xu-2018 CCed

[fujitatomoya]

besides this, we cound the CPU consumption increases significantly if we have more than 102 participants (that means other 101 participants on the participant).

https://fast-dds.docs.eprosima.com/en/latest/fastdds/xml_configuration/domainparticipant.html#dconf explains well.

just trying to understand what was happening. i might be mistaken, let me know if i got anything wrong.

Fast-DDS/src/cpp/rtps/writer/StatefulWriter.cpp

Line 288 in 7606b96

return send_periodic_heartbeat();

here it calls periodically for participant discovery, then

Fast-DDS/src/cpp/rtps/writer/StatefulWriter.cpp

Lines 1677 to 1678 in 7606b96

	//TODO if separating, here sends periodic for all readers, instead of ones needed it.
	send_heartbeat_to_all_readers();

this TODO makes sense to me, it tries to send all readers to get ACK message.
i think unacked_changes comes true if participants are more than 100, since there will be the one participants cannot be discovered fully and response ACK message.
and this undiscovered participants could be different for each participant in the DDS network, this depends to discovery and timing situation.

Fast-DDS/include/fastdds/rtps/writer/RTPSWriter.h

Line 516 in 7606b96

bool m_separateSendingEnabled = false;

it does not send the ACK message only for necessary remote participants.

and if we change m_separateSendingEnabled int true, even with 120 participants cannot increase the CPU consumption since it excludes local participants.

diff --git a/include/fastdds/rtps/writer/RTPSWriter.h b/include/fastdds/rtps/writer/RTPSWriter.h
index b92c820f4..837a350e8 100644
--- a/include/fastdds/rtps/writer/RTPSWriter.h
+++ b/include/fastdds/rtps/writer/RTPSWriter.h
@@ -513,7 +513,7 @@ protected:
     //!Asynchronous publication activated
     bool is_async_ = false;
     //!Separate sending activated
-    bool m_separateSendingEnabled = false;
+    bool m_separateSendingEnabled = true;

     //! The liveliness kind of this writer
     LivelinessQosPolicyKind liveliness_kind_;

[andreclerigo]

@fujitatomoya
Does this behaviour occur when the participants are all in the same machine?
Or are the participants in different machines/docker containers?

[fujitatomoya]

we can observe the problem both cases, originally we found this behavior with 300 different physical devices in the same network. later we came up with reproducible sample that can observe this behavior even with single host with creating 300 participants.