RMW API Proposal: Generic Middleware Context Access

[YuanYuYuan]

Background

This PR provides a Zenoh-specific API to expose the underlying Zenoh session. But it comes with limitations:

• Only works for rmw_zenoh
• Doesn't benefit other RMW implementations
• Uses Zenoh-specific terminology ("session")

This proposal extends the RMW API in a generic way that benefits all RMW implementations.

Investigation: What RMW Implementations Can Expose

1. rmw_zenoh_cpp

Internal Context Structure: rmw_context_impl_s::Data

• Location: rmw_zenoh_cpp/src/detail/rmw_context_impl_s.hpp
• Key object: std::shared_ptr<zenoh::Session>

What it provides:

• Zenoh session for creating custom publishers, subscribers, queryables
• Direct access to Zenoh APIs for advanced operations (customized shared memory provider)

2. rmw_cyclonedds_cpp

Internal Context Structure: rmw_context_impl_s

• Location: rmw_cyclonedds_cpp/src/rmw_node.cpp
• Key object: dds_entity_t ppant (DDS Participant)

Key Entities Stored:

Entity	Type	Purpose
ppant	dds_entity_t	DDS Domain Participant (main entry point)
domain_id	dds_domainid_t	ROS domain ID
rd_participant	dds_entity_t	Built-in topic reader for participant discovery
rd_subscription	dds_entity_t	Built-in topic reader for subscription discovery
rd_publication	dds_entity_t	Built-in topic reader for publication discovery
dds_pub	dds_entity_t	Global DDS Publisher
dds_sub	dds_entity_t	Global DDS Subscriber

What would be useful to expose:

• Primary: DDS Participant (ppant) - root entity for all DDS operations
• Secondary: Global publisher/subscriber entities

3. rmw_fastrtps_cpp

Internal Context Structure: rmw_context_impl_s → CustomParticipantInfo

• Location: rmw_fastrtps_shared_cpp/include/rmw_fastrtps_shared_cpp/custom_participant_info.hpp
• Key object: eprosima::fastdds::dds::DomainParticipant*

Key Entities Stored:

struct CustomParticipantInfo {
  std::shared_ptr<DomainParticipantFactory> factory_;
  DomainParticipant* participant_;
  ParticipantListener* listener_;
  std::map<std::string, std::unique_ptr<UseCountTopic>> topic_name_to_topic_;
  Publisher* publisher_;
  Subscriber* subscriber_;
};

Proposal

Extend rmw/rmw/include/rmw/rmw.h by

/// Get the underlying middleware context handle.
/**
 * Returns a type-erased pointer to the middleware-specific context/session
 * object. The actual type depends on the RMW implementation:
 *
 * - rmw_zenoh_cpp: Returns std::shared_ptr<zenoh::Session>*
 * - rmw_cyclonedds_cpp: Returns dds_entity_t* (DDS Participant)
 * - rmw_fastrtps_cpp: Returns eprosima::fastdds::dds::DomainParticipant**
 *
 * Users must cast the returned pointer to the appropriate type based on
 * rmw_get_implementation_identifier().
 */
RMW_PUBLIC
RMW_WARN_UNUSED
void *
rmw_get_implementation_handle(const rmw_context_t * context);

Example Usage

void* handle = rmw_get_implementation_handle(rmw_context);
const char* impl_id = rmw_get_implementation_identifier();

if (strcmp(impl_id, "rmw_zenoh_cpp") == 0) {
  auto session = *static_cast<std::shared_ptr<zenoh::Session>*>(handle);
  // Use Zenoh session...
} else if (strcmp(impl_id, "rmw_cyclonedds_cpp") == 0) {
  dds_entity_t participant = *static_cast<dds_entity_t*>(handle);
  // Use CycloneDDS participant...
} else if (strcmp(impl_id, "rmw_fastrtps_cpp") == 0) {
  auto participant = *static_cast<eprosima::fastdds::dds::DomainParticipant**>(handle);
  // Use FastDDS participant...
}

[fujitatomoya]

@YuanYuYuan thanks for bringing this up!!!

1st of all, do we already have this interface via rcl?

https://github.com/ros2/demos/blob/91c63e5301a174edda2b01cf79213bf5cc302e91/demo_nodes_cpp_native/src/talker.cpp#L41

(i am not necessarily against this approach since we already have API to access to native handle.)

IMO, I am more interested in what kind of operation or capability needs to be controlled and managed by user application from zenoh::Session (what is the use case for user application?), because that is exactly why we have this RMW APIs in the 1st place with ROS 2 RMW design principle? (i think this is why we maintain the RMW together) And then we can probably introduce the new generic APIs as ROS 2 RMW, so that user application can still be agnostic from underlying RMW implementation.
i mean, exposing the native handler, and do whatever you have to do with it in RMW impl native code would not be beneficial for anyone. (user application becomes aware of the underlying middleware type or internal structures, and we are losing the purpose of RMW as an interface boundary.)

• Abstraction principle could be violated if native handles are exposed directly.
• Encapsulation can be broken, because user application gains knowledge of implementation details.
• Losing portability for user application.

Can we have more discussion on what the use cases are for this? 🤔

[YuanYuYuan]

Hi @fujitatomoya! Thank you for the explanation. I agree with the design of RMW and the example you shown (demo_nodes_cpp_native) definitely could work on rmw_zenoh since my original PR use the similar way.

Regarding the purpose, we'd like to expose the Zenoh session so that user can customize the shared memory provider programmatically. This is quite important for user-defined memory management.

IMO, if the rmw_zenoh can find its way out and fastrtps already does, or maybe cyclonedds doesn't need this either. There is indeed no point to have this new API.

[fujitatomoya]

@YuanYuYuan

we'd like to expose the Zenoh session so that user can customize the shared memory provider programmatically.

if that is okay, can you describe more details? user application needs to change the segment size for shared memory or something?

There is indeed no point to have this new API.

good to know. but obviously i think we do not suggest this approach... because of above reasons i mentioned.

[JEnoch]

I’d rather keep RMW-specific operations within each RMW implementation (if relevant) for several reasons:

• Clarity: Using explicit function names like rmw_zenoh_get_session or rmw_fastrtps_cpp::get_domain_participant makes it clear what type of object the user will receive (e.g., a Zenoh Session or a FastRTPS Participant).

• Flexibility: This approach allows RMW implementers to provide different operations for different entities, such as rmw_fastrtps_cpp::get_domain_participant() and rmw_fastrtps_cpp::get_datawriter().

• Backporting possibility: I'm not sure if adding a function to rmw.h might break compatibility. For example, could updating the rmw package without updating the vendor package cause issues ? While adding such operation to rmw_zenoh.h allows for backporting to distributions like Humble, Jazzy, and Kilted.

• Limited Benefit: A generic rmw_get_implementation_handle() doesn’t add much value, since users still need to cast the result to the correct middleware entity. Their code will inherently depend on the specific middleware anyway.

@Yadunund , @YuanYuYuan , @fujitatomoya What do you think ?

[fujitatomoya]

@JEnoch yeah i think that is okay. as i mentioned before, we already have similar API https://github.com/ros2/demos/blob/91c63e5301a174edda2b01cf79213bf5cc302e91/demo_nodes_cpp_native/src/talker.cpp#L41. what i was trying to find here is, if that is the interface which RMW should support in generic API, that is exactly why RMW exists for. but i do understand that depends on use cases and requirements.