Send Spdp directly when we have a new discovered participant

[jwillemsen]

No description provided.

[simpsont-oci]

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]

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]

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]

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

[jrw972]

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]

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

[mitza-oci]

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]

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]

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]

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.