Why not ign-transport use DDS?

Gazebo Gazebo General
,
1

In ROS on DDS, I see the advantage of DDS over Protobuf with ZeroMQ, so I wonder to known why ign-transport choose not to use DDS? Can anybody have a explain?

1 Like
2

Not a direct answer to your question, but a relevant discussion was held here: https://discourse.openrobotics.org/t/why-are-ros-and-ignition-gazebo-diverging-or-not-converging/9513 .

1 Like
3

DDS did not fit our use-case based on the following:

  1. DDS was not, and maybe still is not, a debian package released in normal Ubuntu distributions.
  2. There was no open-source community around DDS when ign-transport started.
  3. DDS has a lot of configuration options that are not needed by Ignition.
  4. We’d rather have a faster transport via TCP/IP than rely on UDP. The protobuf + zeromq setup is faster than DDS.
  5. Protobuf is a widely adopted message format that let’s us leverage a large community of developers and libraries. For example, we can do things like transmit messages directly from a sever to a browser without message translation.
1 Like
4

Hope it is not too much off topic, but I did not get answer on mu question and I believe is is connected. Could IPC be used in Ignition transport? If so, how? If not, is there a good reason? Thanks

5

@nate thanks for the information. it helps a lot :+1:

  1. We’d rather have a faster transport via TCP/IP than rely on UDP. The protobuf + zeromq setup is faster than DDS.

AFAIK, DDS is sets of API. so transport layer can be also TCP/IP.
btw, do you happen to have any benchmark information about How faster it could be against DDS?, we are really interested in that.

  1. Protobuf is a widely adopted message format that let’s us leverage a large community of developers and libraries. For example, we can do things like transmit messages directly from a sever to a browser without message translation.

totally agree.

6

Hope it is not too much off topic, but I did not get answer on mu question and I believe is is connected. Could IPC be used in Ignition transport? If so, how? If not, is there a good reason? Thanks

Ignition Transport doesn’t use ZeroMQ with nodes within the same process. It doesn’t even serialize the messages. For communication between processes within the same machine we still rely on TCP/IP. The kernel does some optimizations in this case. We still do serialization, so something to improve in the future.

1 Like
7

The DDS specification does not allow for TCP/IP, everything is UDP.

We did some benchmark tests a couple years back here.

1 Like
8

@nate

thanks, we will look into it.

The DDS specification does not allow for TCP/IP, everything is UDP.

is that true? as far as i see the specification, it does not mention about specification of network transport…

https://www.omg.org/spec/DDS/1.4/PDF

and most of dds implementation for ROS 2 support TCP/IP transport as well.

1 Like
9

since i am new user, i am not allowed to post more than 2 links…

10

Right, the things you are mentioning are not part of the official DDS specification. Those are extra’s provided by different vendors.

11

Thanks for your answer. Do you plan in the future to also switch from TCP/IP to IPC for communication on one machine? Or you do did not expect any significant improvement to benchmarks mentioned by @nate here?

12

Adding in IPC as an option is not currently on our roadmap. If you’re so inclined, I encourage you to take a stab at an implementation. We can offer guidance and support.

Alternatively, you could consider using Iceoryx.

13

Thank you for clearing this. I will do some benchmarking and if the native Ignition transport won’t be fast enough, I may try to implement it.

14

Coming back to this thread in 2026, it is fascinating to see how well the original decision to use Protocol Buffers for ign-transport (now Gazebo Transport) has aged. Protobuf’s performance, simplicity, and multi-language/MLOps friendliness have proven indispensable.

However, as many in the community have experienced over the years, the divergence between Gazebo speaking Protobuf and ROS 2 speaking DDS/CDR created an unfortunate architectural divide. The resulting ros_gz_bridge ros_gz/ros_gz_bridge/README.md at ros2 · gazebosim/ros_gz · GitHub has to deserialize gz::msgs, copy fields into ROS 2 .msg structs, and serialize into CDR—which becomes a noticeable CPU and latency bottleneck for high-frequency sensors like 4K cameras or high-beam Lidars.

Historically, people often framed the solution as either “Gazebo should adopt DDS” (which Open Robotics rightly resisted) or “live with the bridge marshaling penalty”.

Recently, we’ve been exploring the third possibility: What if ROS 2 natively embraces Protobuf without modifying ros2core or RMW vendors?

We recently announced our work on protoros2 Announcing protoros2: use protobuf in ros2 without compromise. One relevant architectural takeaway for the Gazebo ecosystem is:

  1. Zero-conversion on stock RMW: Even under default RMWs (rmw_fastrtps_cpp / rmw_cyclonedds_cpp), ROS 2’s publish_serialized API can pass raw Protobuf bytes directly as an opaque payload.
  2. Direct consumption: Subscribing nodes leveraging SerializedMessage callbacks can parse directly into C++ Protobuf objects with 0 intermediate .msg conversions and 0 extra field copies.

If this concept were applied to ros_gz_bridge (for instance, as an opt-in direct_proto fast-path mode for heavy sensor streams), gz::msgs could flow from Gazebo through the ROS 2 transport directly into downstream perception nodes with virtually zero translation overhead.

I thought this perspective might be interesting to those who followed this design debate. The historical gap between Gazebo’s transport and ROS 2 doesn’t necessarily have to be paid in CPU conversion cycles anymore!

2 Likes