注：本篇文章不讨论这三种DDS是如何使用的。只做结论性描述

经鉴定这篇文章没有任何创造性：学会创造才是最大的财富。

Connext DDS 与 FastDDS

问题鸟问：这两个能正常通信吗？

闻啼鸟答：我哪里知道。。。你不会百度吗

问题鸟问：百度？你骂人？

闻啼鸟答：哈哈！！！那咱就看一下，使用FastDDS发布数据，ConnextDDS订阅数据能正常收发吗？
（最近学会了使用gif的方式发布动图，请欣赏）

问题鸟问：OK，我就说能通信，不会有啥问题，你还犟。

闻啼鸟答：咳嗽~

问题鸟问：我的意思是，确实没有啥问题，那反过来呢？

闻啼鸟答：损色。其实没啥必要进行验证，还是看一下吧

问题鸟问：哦吼，果然没问题。那我知道了，Connext DDS节点与Fast-DDS进行交互是行得通的。

闻啼鸟答：没错，下面看一下Fast-DDS与OpenDDS。首先还是让Fast-DDS进行发布，OpenDDS进行订阅。

FastDDS 与 OpenDDS

问题鸟问：我知道没问题，你不用说了，直接反过来收发吧。

闻啼鸟答：额贼，嫌我多余了。不过我要告诉你，你看到的不一定是真的哦，这里还真的有些问题，变换一下收发启动的顺序，你在看。

问题鸟问：噗哧笑，你啥破配置，这就没内存了？？？

闻啼鸟答：32G内存好吧，不知道瞎嘚啵。（翻车现场）看现象应该是序列化使用的buffer出错了，内存溢出，问题的解释一句话：他是个bug。

问题鸟问：姑且算Fast DDS节点与OpenDDS 进行交互是行得通的吧。不过遇到问题，不要得过且过哦。 那么接下来呢？

闻啼鸟答：是_是是。 你教训的是。接下来是Connext DDS和OpenDDS之间的互通信，Connext DDS订阅，OpenDDS发布

ConnextDDS与 OpenDDS

问题鸟问：好像也没啥问题。

闻啼鸟答：嗯，其实吧有一个问题，接下来看，当我先开启opendds的发布节点时会提示错误，但是并不影响通信

问题鸟问：确实哎，RTPS header for SPDP， 那这是啥呀？

闻啼鸟答：SPDP全称是 Simple Participant Discovery Protocol（SPDP），这是DDS节点发现过程中的第一个阶段，这个阶段完成之后进入下一个阶段Simple Endpoint Discovery Protocol (SEDP) 。只有这两个阶段全部完成之后才会进入真正的数据交互。这应该是OpenDDS的版本问题，是一个bug。嘿嘿嘿，下面继续

问题鸟问：我也算Connext DDS节点与OpenDDS 进行交互是行得通的吧。

闻啼鸟:你总结吧。

问题鸟：过年了，在吃好吃的呢，一会着昂。

闻啼鸟：你到跑得快。

闻啼鸟总结：

只要不同厂家实现的DDS是符合OMG的标准的，那么相互通信就没有什么问题。至于这三家产品的好坏，请听下回辩解。