[Feature Request] Support Routing for ROS 2 service and action (with security)

[fujitatomoya]

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.

https://github.com/ros2/rmw_fastrtps/blob/508ad9dd2ce05cb831ba00e9784c5f334101174c/rmw_fastrtps_shared_cpp/src/rmw_response.cpp#L75-L76

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.

[fujitatomoya]

CC: @juanlofer-eprosima @Barry-Xu-2018

[fujitatomoya]

@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??