-
Notifications
You must be signed in to change notification settings - Fork 60
Description
Describe the bug
I'm trying to build familiarity with Zenoh and learn how we may apply it. I have started with a simple example setup in which Zenoh is used to route DDS messages from one domain to another. I understand this is a contrived example and there are other ways to achieve this, bu it is a simple way to provide an example of the issue.
I find that it fails to create a DataWriter if the topic/if the originating DDS DataWriter is using XCDR1. If all of my DDS messages are encoded with XCDR2, there is no issue. The error which is reported from Zenoh is:
2025-10-06T12:31:44.646869Z ERROR tokio-runtime-worker ThreadId(16) zenoh_plugin_dds: Route Zenoh->DDS (Topic -> Topic): creation failed: Error creating DDS Writer: Bad Parameter
Is this an expected limitation of the current Zenoh image (1.5.1) ?
I don't find a reference to XCDR in this repo, nor in https://github.com/eclipse-zenoh/zenoh.
To reproduce
In a DDS application:
- Create 2 DomainParticipants, one on Domain 5 and another on Domain 6
- Use each Participant to create a Topic on the two domains. Each topic using same name and the same IDL type
- Create a DataWriter on Domain 5
- Create 2 DataReaders, one on Domain 5 and another on Domain 6
- Write data on Domain 5
- Note: The created Topics, Readers, and Writers, are each created with a QoS object whose DataRepesentation policy is set as below. No further changes are made to the QoS policy for the sake of this example.
#define XCDR_VER dds::core::policy::DataRepresentationId::XCDR1
//Note dp is a DomainParticipant; pub is a Publisher and sub is a Subscriber all created with Default QoD
dds::topic::qos::TopicQos topicQos{dp.default_topic_qos()};
topicQos << dds::core::policy::DataRepresentation(dds::core::policy::DataRepresentationIdSeq{XCDR_VER});
dds::pub::qos::DataWriterQos dwQos{pub.default_datawriter_qos()};
dds::sub::qos::DataReaderQos drQos{sub.default_datareader_qos()};
dwQos = topicQos;
drQos = topicQos;
dwQos << dds::core::policy::DataRepresentation(dds::core::policy::DataRepresentationIdSeq{XCDR_VER});
drQos << dds::core::policy::DataRepresentation(dds::core::policy::DataRepresentationIdSeq{XCDR_VER});
Pull and launch Zeno:
- (Following the steps in this repo's README):
docker pull eclipse/zenoh-bridge-dds:latest docker run --init --net host eclipse/zenoh-bridge-dds --rest-http-port 8000 -d 5 -i 123 -l tcp/0.0.0.0:7447docker run --init --net host eclipse/zenoh-bridge-dds --rest-http-port 8001 -d 6 -i 456 -e tcp/<IP_ADD>:7447
Run the DDS application. The expectation is that the DataReaders on each Domain both receive DDS messages.
The observation is that the Zenoh instance started with -d 6 reports the following error
2025-10-06T12:31:44.646869Z ERROR tokio-runtime-worker ThreadId(16) zenoh_plugin_dds: Route Zenoh->DDS (Topic -> Topic): creation failed: Error creating DDS Writer: Bad Parameter
No such error seems to be reported by the Zenoh instance on domain 5 with regards to creating a DataReader.
If the QoS settings used to create all DDS components are changed to use #define XCDR_VER dds::core::policy::DataRepresentationId::XCDR2, we also see no such error in Zenoh and the DDS messages are received on both domains as expected.
Further note: The steps above assume all readers/writers are on the same host. The same setup has been tested with additional DataReaders created on remote hosts but the same behaviour from Zenoh is observed whether readers are on the same host as the writer or remote hosts.
System info
- Platform: RedHat Enterprise v8.10
- Zenoh: 1.5.1 (acquired using
docker pull eclipse/zenoh-bridge-dds:latest), executed from the Docker image - DDS Implementation: Cyclone CXX built using
- Cyclone @ eclipse-cyclonedds/cyclonedds@8aa3015
- Cyclone CXX @ eclipse-cyclonedds/cyclonedds-cxx@08d9778