# Why not ign-transport use DDS?

**URL:** <https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915>\
**Category:** Gazebo General\
**Tags:** ros2, ignition\
**Created:** [December 6, 2021, 8:42am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915 "2021-12-06T08:42:16Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![llapx](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/llapx/32/26928_2.png) [@llapx](https://discourse.openrobotics.org/u/llapx)\
**Post date:** [December 6, 2021, 8:42am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/1 "2021-12-06T08:42:16Z")

</div>

In [ROS on DDS](https://design.ros2.org/articles/ros_on_dds.html), 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?

---

<div class="post-metadata">

**Author:** ![peci1](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/peci1/32/10145_2.png) [@peci1](https://discourse.openrobotics.org/u/peci1)\
**Post date:** [December 6, 2021, 11:14am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/2 "2021-12-06T11:14:38Z")

</div>

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](https://discourse.openrobotics.org/t/why-are-ros-and-ignition-gazebo-diverging-or-not-converging/9513) .

---

<div class="post-metadata">

**Author:** ![Nate\_Koenig](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/nate_koenig/32/4940_2.png) [@Nate\_Koenig](https://discourse.openrobotics.org/u/Nate_Koenig)\
**Post date:** [December 6, 2021, 7:04pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/3 "2021-12-06T19:04:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![m.bahno](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/m.bahno/32/11598_2.png) [@m.bahno](https://discourse.openrobotics.org/u/m.bahno)\
**Post date:** [December 7, 2021, 9:12am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/4 "2021-12-07T09:12:12Z")

</div>

Hope it is not too much off topic, but I did not get answer on [mu question](https://answers.gazebosim.org/question/27606/which-transport-class-is-used-in-ignition-transport-and-is-it-possible-to-choose-it/) and I believe is is connected. Could IPC be used in Ignition transport? If so, how? If not, is there a good reason? Thanks

---

<div class="post-metadata">

**Author:** ![tomoyafujita](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/tomoyafujita/32/6097_2.png) [@tomoyafujita](https://discourse.openrobotics.org/u/tomoyafujita)\
**Post date:** [December 7, 2021, 5:54pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/5 "2021-12-07T17:54:34Z")

</div>

@nate thanks for the information. it helps a lot 👍

> 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.

---

<div class="post-metadata">

**Author:** ![caguero](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/caguero/32/3037_2.png) [@caguero](https://discourse.openrobotics.org/u/caguero)\
**Post date:** [December 7, 2021, 6:14pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/6 "2021-12-07T18:14:25Z")

</div>

> Hope it is not too much off topic, but I did not get answer on [mu question](https://answers.gazebosim.org/question/27606/which-transport-class-is-used-in-ignition-transport-and-is-it-possible-to-choose-it/) 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.

---

<div class="post-metadata">

**Author:** ![Nate\_Koenig](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/nate_koenig/32/4940_2.png) [@Nate\_Koenig](https://discourse.openrobotics.org/u/Nate_Koenig)\
**Post date:** [December 7, 2021, 6:14pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/7 "2021-12-07T18:14:36Z")

</div>

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

We did some benchmark tests a couple years back [here](http://gazebosim.org/blog/gazebo9).

---

<div class="post-metadata">

**Author:** ![tomoyafujita](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/tomoyafujita/32/6097_2.png) [@tomoyafujita](https://discourse.openrobotics.org/u/tomoyafujita)\
**Post date:** [December 7, 2021, 7:11pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/8 "2021-12-07T19:11:01Z")

</div>

@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](https://www.omg.org/spec/DDS/1.4/PDF)

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

- [6.3. TCP Transport - 3.3.0](https://fast-dds.docs.eprosima.com/en/latest/fastdds/transport/tcp/tcp.html)

---

<div class="post-metadata">

**Author:** ![tomoyafujita](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/tomoyafujita/32/6097_2.png) [@tomoyafujita](https://discourse.openrobotics.org/u/tomoyafujita)\
**Post date:** [December 7, 2021, 7:11pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/9 "2021-12-07T19:11:42Z")

</div>

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

- [RTI TCP Transport: TCP Transport for RTI Connext](https://community.rti.com/rti-doc/510/ndds.5.1.0/doc/html/tcp_transport/#:~:text=RTI%20TCP%20Transport%20enables%20participant,of%20exposed%20ports%20to%20one).
- [cyclonedds/docs/manual/options.md at master · eclipse-cyclonedds/cyclonedds · GitHub](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/docs/manual/options.md)

---

<div class="post-metadata">

**Author:** ![Nate\_Koenig](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/nate_koenig/32/4940_2.png) [@Nate\_Koenig](https://discourse.openrobotics.org/u/Nate_Koenig)\
**Post date:** [December 7, 2021, 8:52pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/10 "2021-12-07T20:52:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![m.bahno](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/m.bahno/32/11598_2.png) [@m.bahno](https://discourse.openrobotics.org/u/m.bahno)\
**Post date:** [December 8, 2021, 8:58am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/11 "2021-12-08T08:58:50Z")

</div>

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](https://community.gazebosim.org/t/why-not-ign-transport-use-dds/1190/7)?

---

<div class="post-metadata">

**Author:** ![Nate\_Koenig](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/nate_koenig/32/4940_2.png) [@Nate\_Koenig](https://discourse.openrobotics.org/u/Nate_Koenig)\
**Post date:** [December 8, 2021, 4:52pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/12 "2021-12-08T16:52:59Z")

</div>

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](https://iceoryx.io/v1.0.1/).

---

<div class="post-metadata">

**Author:** ![m.bahno](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/m.bahno/32/11598_2.png) [@m.bahno](https://discourse.openrobotics.org/u/m.bahno)\
**Post date:** [December 13, 2021, 2:53pm UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/13 "2021-12-13T14:53:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ZhenshengLee](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/zhenshenglee/32/10103_2.png) [@ZhenshengLee](https://discourse.openrobotics.org/u/ZhenshengLee)\
**Post date:** [September 8, 2026, 11:24am UTC](https://discourse.openrobotics.org/t/why-not-ign-transport-use-dds/47915/14 "2026-09-08T11:24:00Z")

</div>

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](https://github.com/gazebosim/ros_gz/blob/ros2/ros_gz_bridge/README.md) 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](https://discourse.openrobotics.org/t/announcing-protoros2-use-protobuf-in-ros2-without-compromise/57152). 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!