search

OpenDDS / OpenDDS

OpenDDS is an open source C++ implementation of the Object Management Group (OMG) Data Distribution Service (DDS). OpenDDS also supports Java bindings through JNI.
http://www.opendds.org
Other
1.29k stars 465 forks source link

Send Spdp directly when we have a new discovered participant #2798

Open jwillemsen opened 2 years ago

simpsont-oci commented 2 years ago

The small delay is important, since it protects against a flood of outgoing SPDP announcements when a large number of remote participants are discovered sequentially. On a network of 300 participants, all trying to discover each other, we get 300^2 participant announcements if we respond immediately for every incoming SPDP message. This floods the network and causes lots of packet loss / slower discovery times.

Perhaps we can have a special case for "the first SPDP announcement we've seen in X seconds (or since startup)" to respond immediately, but we need a safe fallback for the large deployment case.

jwillemsen commented 2 years ago

I can see your point with 300 participants, but with the small DevGuideExample which writes 100 samples it takes 7 seconds for the test to complete with RTPS, and below 1 second when using the DCPSInfoRepo.

@simpsont-oci Maybe we could have a configurable limit for the amount of domain participants under which we do a direct send, above we do a delayed send? Really would like to see that the use case of a simple system has fast discovery.

jrw972 commented 2 years ago

I agree with Tim that we need to be smart about sending SPDP to avoid flooding networks. I have an idea on this that I will try to document and circulate.

Beyond that, is the delay from SPDP or from SEDP? If SEDP, you may want to try responsive mode (see the dev guide).

jwillemsen commented 2 years ago

It is SPDP, I also see the same slow discovery on Linux, not always, but there it also happens.

jrw972 commented 2 years ago

I agree with Tim that we need to be smart about sending SPDP to avoid flooding networks. I have an idea on this that I will try to document and circulate.

Beyond that, is the delay from SPDP or from SEDP? If SEDP, you may want to try responsive mode (see the dev guide).

When a participant receives an SPDP message from a new participant, it should send its own announcement to the new participant quickly but not too quickly lest the network becomes flooded.

Let D be an arbitrary delay, e.g., 10 ms.

Let N be the number of remote participants discovered by a participant P.

Whenever P receives an SPDP message for new remote Q, it picks a random number r in [0,N) and schedules to send a directed (unicast, INFO_DST) announcement to Q at D * r seconds in the future.

Assuming that D and N are the same for all participants in the network, then the random delay should smooth out discovery while still making it responsive.

Saurabh996 commented 2 years ago

Any update on improving this slow discovery of participants associated with RTPS mode?

mitza-oci commented 2 years ago

Any update on improving this slow discovery of participants associated with RTPS mode?

How many participants are you supporting? What is ResendPeriod set to?

Saurabh996 commented 2 years ago

Any update on improving this slow discovery of participants associated with RTPS mode?

How many participants are you supporting? What is ResendPeriod set to?

Less than 20 participants. Where do we have the option of setting up the "ResendPeriod"? As of now it should be in default only I suppose..

simpsont-oci commented 2 years ago

ResendPeriod is in the rtps_discovery section of the config file. You can check the OpenDDS developer's guide for more info on what this looks like, or try to find an example in one of the test configs.

Saurabh996 commented 2 years ago

ResendPeriod is in the rtps_discovery section of the config file. You can check the OpenDDS developer's guide for more info on what this looks like, or try to find an example in one of the test configs.

Yes, got them. Thanks for the guidance.