Updating Discovery/Peers after participant creation

[m-mead]

Hi, I have a question regarding participant discovery that I have been unable to find an answer to in documentation or online. That is, is there a way to dynamically add Peers to the discovery process, after the domain and participant handles have been created?

The problem I am trying to solve is we have a system which has multicast disabled. This has lead us to augmenting the discovery process by specifying a list of all peers in the Discovery/Peers [section of the configuration file](https://cyclonedds.io/docs/cyclonedds/0.9.1/config.html#discovery-configuration). This process works, but we occasionally have scenarios where the IP addresses might change or new participants are added to the system. Our current approach is to restart all services that use DDS when an IP address change or addition occurs, but we would like to ultimately avoid the service restart.

[eboasson]

There's currently no (official) way to add peers through the API. Unofficially, it can be done, but it won't be through a stable API (and I can already guarantee that it will break (in a trivial way) once I merge my work-in-progress.

Would you be interested in such an unofficial solution? It simply involves a few weird includes and scary function calls 🙂

[m-mead]

Hi @eboasson, thank you for the reply. I'm still interested in the solution despite it being unofficial and likely to break 🙂. I should mention that we are using the C++ CycloneDDS-cxx APIs, so if the APIs are not accessible from C++ then that is good to know too.

I did have another thought. Would the following work for discovering new peers without a full process restart?

• Tear down the DDS participants in our system
• Update the XML configuration file
• Recreate the DDS participants in our system

I assume this would result in some messaging drops, but if it can avoid restarting the process then it could be a good middle ground solution between the unofficial APIs and a process restart.

[eboasson]

Once upon a time, there were two contrasting views on which header files to install and which to keep private. Some advocated only installing header files defining things related to the supported interface, others prefer installing everything and saying: "well, if you use this bit, we'll support you; if you use that bit, you're on your own".

I guess these days most people are in the first camp, I am mostly in the second camp — perhaps because I enjoyed the contents of /usr/include/sys/*.h way back when — but I do see the point in keeping things clean. For better or for worse, that means Cyclone is somewhere in between the extremes ... and of course that now means not everything one needs to update the set dynamically is available.

Fortunately, Cyclone is open source and so I can keep my promise 😄 This branch on my fork shows a possible way. It needed moving some stuff around in header files, and to avoid having to change the set of header files to install I also added a function that obviously is not supposed to be in the API. I guess it is quite self-explanatory if you look at the hello world publisher. Given that there will be some changes in this anyway, I think I should see whether there's a nice way for making this possible without having to hack it like this.

I should mention that we are using the C++ CycloneDDS-cxx APIs, so if the APIs are not accessible from C++ then that is good to know too.

Given that the above is such an ugly hack, it would probably be good to isolate it a bit. You can call the relevant C functions for C++ without any problem. The one thing you need is the handle for the C entity, that you can get from the C++ API by doing DomainParticipant dp(0); ... dp->get_ddsc_entity().

I did have another thought. Would the following work for discovering new peers without a full process restart?

• Tear down the DDS participants in our system
• Update the XML configuration file
• Recreate the DDS participants in our system

Yep, that would work. It might be useful to know that you can also play tricks with the configuration because it doesn't have to really have to be one file. The CYCLONEDDS_URI is consumed piecewise where it looks at the first unprocessed character, and then:

• if it is <, it starts parsing (a relaxed form of) XML until all tags have been closed or it runs into a parse error,
• else it treats everything until the next comma as a URI (which may be just a file name)
  and then it eats up any commas, and repeats the above until it reaches the end. That "relaxed form" of XML accepts </> as a generic closing tag, uses unique prefix matching and allows you to skip the CycloneDDS and Domain bits.

So you can do a "proper" configuration file followed by a configuration file that really only defines peers, or you can even make a string that starts with the configuration file name, and then put the list of peers directly into the string.

There is also the dds_create_domain function in the C API which allows you to pass in the configuration string directly. This would allow you to avoid touching the CYCLONEDDS_URI contents or modifying the file system. In the C++ API this feature is available, too, there is a variant for the DomainParticipant constructor that takes the configuration string, like:

dds::domain::DomainParticipant(0, nullptr, nullptr, dds::core::status::StatusMask::none(), config);

[m-mead]

Wow, thank you for the really informative reply! This is all helpful, and I appreciate it. Also, I apologize for my delay in getting back to the thread -- I have been away on holiday.

The experimental APIs in your commit looks reasonable for us to support in a forked version, if the reinitialization time for the option involving updating the XML file ends up being too long. Would the project ever be interested in adding official support, or is that outside the scope of the public library interface?