Repository navigation
[Feature Request] Support Routing for ROS 2 service and action (with security) #487
Description
Originally discussed on #484
ROS 2 services and actions are constructed with topics, so technically having all topics under namespace rt, rq and rr would support the ROS 2 service and action communication.
- ROS 2 Service
- rq/xxxxxxRequest
- rr/xxxxxxReply
- ROS 2 Action
- rq/xxxxxx/_action/send_goalRequest
- rr/xxxxxx/_action/send_goalReply
- rq/xxxxxx/_action/cancel_goalRequest
- rr/xxxxxx/_action/cancel_goalReply
- rq/xxxxxx/_action/get_resultRequest
- rr/xxxxxx/_action/get_resultReply
- rt/xxxxxx/_action/feedback
- rt/xxxxxx/_action/status
But actually this is not straight-forward like this, because there needs to be the process to associate request/response identification (DDS Writer/Reader GUID, Goal ID) for ROS 2 service and action.
the followings are where ROS 2 system filters out unconcerned response or message on the requester side.
the service responses are filtered out here to check if the response data writer guid matches with either request data reader or writer here. this part is actually implemented with RMW CustomClientInfo, this mechanism needs to be implemented in DDS Router.
https://github.com/ros2/rclcpp/blob/rolling/rclcpp_action/include/rclcpp_action/client.hpp#L714-L719 and https://github.com/ros2/rclcpp/blob/rolling/rclcpp_action/include/rclcpp_action/client.hpp#L751-L756
it does the almost same thing here, to make sure the goal id matches the action client request. the difference from service is that goal id is on the message, so that this is done by rclcpp application layer, not in the RMW implementation. that said, DDS router can just proxy the topics for actions without filtering process.
Activity
fujitatomoya commentedon Jan 6, 2025
CC: @juanlofer-eprosima @Barry-Xu-2018
fujitatomoya commentedon Jan 7, 2025
@juanlofer-eprosima
CC: @Barry-Xu-2018
could you share your insights here? i would love to have a quick chat on this feature request if you are available.
so i was mistaken a bit to support this feature from the discussion on #484.
we confirmed that without security (every kind other than XML participant), DDS router can actually proxy the ROS 2 services and actions.
originally i was expecting that we need to add some association process what is done by RMW, that is filtering out the unconcerned response message based on the guid. but actually we do not need that process, because it already can allow the ROS 2 service clients to fetch the guid information as RMW CustomClientInfo, specifically
eprosima::fastrtps::rtps::SampleIdentity.https://github.com/ros2/rmw_fastrtps/blob/508ad9dd2ce05cb831ba00e9784c5f334101174c/rmw_fastrtps_shared_cpp/src/rmw_response.cpp#L75-L76
(note that action feedback and status topics should not be the problem, since goal identification is on the message and filtered out in ROS 2 client layer.)
this generates the question for me. why we cannot route the ROS 2 service and action once security is enabled??? what exactly needs to be done to support ROS 2 service and action with security enclaves??