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

[juanlofer-eprosima]

@fujitatomoya @Barry-Xu-2018

I think there's been a misunderstanding here. Support of services and actions in DDS-Router was added in release v1.0.0 (#281), which implements the mechanism mentioned in previous comments that allows to associate requests and replies transferred across DDS-Router participants. However when some time later the XML participant kind was added (the only one currently allowing security configuration), we did not extend services support for it. So that would be the task we would need to discuss about. We would be glad to have that meeting, will be sending an email soon to arrange it.

[fujitatomoya]

@juanlofer-eprosima thanks for the info.

okay, my bad, i was misunderstanding the current status... thanks!

we are considering the contribution, but it depends on how much work needs to be done. our use case requires the security enclaves on the other side of DDS Router, that means we need XML participant kinds for sure. i can explain more details for the requirements on the call.

can you send us the invitation for [email protected] and [email protected]?

in the mean time, if you can point where we should take a look at in the source code, that would be really appreciated.

[fujitatomoya]

@juanlofer-eprosima friendly ping.

[juanlofer-eprosima]

Hi @fujitatomoya , sorry for the delay. You should have received an email already, see you soon!