-
Notifications
You must be signed in to change notification settings - Fork 68
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
Reconsidering 1-to-1 mapping of ROS nodes to DDS participants #180
Comments
Relates to ros2/design#250 |
thread information with Fast-RTPS, https://github.com/nobleo/ros2_performance
ros:
|
I'm going to close this in favor of the existing design pr (ros2/design#250) and discourse discussions (https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062/12) and because this will affect way more than just this repository. Feel free to continue to comment or suggest a reason why we should keep this open. |
Feature request
Reconsidering 1-to-1 mapping of ROS nodes to DDS participants
Feature description
As a result of the research published here:
https://github.com/nobleo/ros2_performance
A ROS discourse discussion was started here:
https://discourse.ros.org/t/reconsidering-1-to-1-mapping-of-ros-nodes-to-dds-participants/10062
at this discussion it was requested that this feature be posted as an issue.
From the discourse discussion:
dirk-thomas:
"Instead of introducing an option the current idea is to associate the DDS participant with the context created during rmw_init. That would imply that common applications using a single init / context will only use a single DDS participant - even if they are composed of multiple ROS nodes."
Argumentation for change: Making every Node in rclcpp a DDS participant creates significant CPU overhead. Use cases exists where all Nodes run on a single piece of hardware. The CPU overhead can be reduced by creating 1 participant per process space.
Implementation considerations
From the discourse discussion:
dirk-thomas:
"... Any help is appreciated. It will likely start with a design article to discuss the side affects of the intended change. E.g. the ROS node name is currently being used for the DDS participant name. When that mapping goes away there needs to be a replacement mechanism to communicate the node name."
kyrofa:
"Not trying to debate the performance gains of this approach, but I think it’s worth pointing out that SROS 2 (and indeed DDS-Security in general) currently only supports security at the domain participant level. Using the same participant for multiple nodes will make security very difficult, as all nodes will have effectively the same identity and thus the same access control."
The text was updated successfully, but these errors were encountered: