-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating Discovery/Peers
after participant creation
#2013
Comments
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 🙂 |
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?
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. |
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 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.
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
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:
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::domain::DomainParticipant(0, nullptr, nullptr, dds::core::status::StatusMask::none(), config); |
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? |
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.The text was updated successfully, but these errors were encountered: