Add type hash support (pub/sub only) #349
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add support of ROS 2 type hash set by
rmw_cyclone_dds
in USER_DATA QoS.What this PR does if
$ROS-DISTRO
>=iron
:ros_discovevry_info
topic with the expected type hash (hard coded) in USER_DATA QoSstatus
topic with the expected type hash (hard coded) in USER_DATA QoSfeedback
topic with an pseudo-type hash (hard coded) in USER_DATA QoS(currently
rmw_cyclonedds_cpp
only checks the presence of a type hash, not the compatibility...)The propagation of type hashes for Services and Actions is not implemented in this PR.
A type hash encoded in USER_DATA QoS is 81 characters/bytes (
"typehash=RIHS01_<64bytes>;"
). For a Service on DDS, we need to propagate the type hashes for both the Request and Response topics (162 bytes). For an Action it would be 8*162=1296 bytes. Even if the Zenoh Liveliness Tokens have no size limit, this would add a burden on the discovery phase.Moreover, at this stage
rmw_cyclonedds_cpp
set the type hash in USER_DATA for each DDS Reader/Writer, but on discovery it check if it's present only for Topics Pub/Sub, not for Services.fix #290