1. Scope引言部分【翻译】该规范解决了图 1 中总结的四个相关关注点类型系统Type System、类型的表示Type Representation、数据的表示Data Representation以及用于访问类型和数据的语言绑定Language Binding。这四个关注点中的每一个都被建模为属于相应包Package的类集合。本规范为 DDS 的实现者和用户提供了以下额外功能1. 类型系统 (Type System) —— 规则的定义者【翻译】类型系统Type System本规范定义了可用于 DDS Topic 的数据类型模型。该类型系统使用 UML 进行了正式定义。类型系统在第 7.2 节及其子节中定义。该系统的结构模型在第 7.2.2 节的“类型系统模型”中定义。随着时间的推移允许对类型进行修改的框架在第 7.2.3 节“类型可扩展性与可变性Type Extensibility and Mutability”中进行了概述。在面对此类修改时综合第 7.2.2 节和第 7.2.3 节的概念以定义类型兼容性的具体规则在第 7.2.4 节“类型兼容性Type Compatibility”中定义。【白话解释】以前的老 DDS 协议中数据结构一旦定死就不能改了改一个字段整个系统都得重新编译。 XTypes 引入的Type System就是为了打破这个限制。它规定了可扩展性 (Extensibility)允许你在 IDL 结构体末尾追加新字段Appendable或者完全自由修改字段Mutable。兼容性规则 (Type Compatibility)规定了当发布方和订阅方的数据结构不完全一致时比如发布方多了一个字段DDS 底层如何通过强弱类型匹配规则判定双方是否还能继续通信。2. 类型表示 (Type Representations) —— 结构的传输【翻译】类型表示Type Representations本规范定义了如何将“类型系统”中所描述的类型进行外部化序列化以便它们可以存储在文件中或在网络上进行传输。除了 DDS 规范已经隐含的表示形式IDL之外本规范还增加了更多的类型表示。第 7.3 节的子节中指定了几种类型表示包括IDL (7.3.1)、XML (7.3.2)、XML Schema (XSD) (7.3.3) 以及 TypeObject (7.3.4)。【白话解释】这里指的是“如何向别人描述我的数据长什么样”。除了传统的*.idl文件XTypes 允许用 XML 或 XSD 来定义和传输数据结构。 最核心的引入是TypeObject它是一种将“数据结构本身”转化成二进制网络报文的技术。DDS 节点在握手时可以直接在网络上互发 TypeObject这样即使没有 IDL 文件接收方也能瞬间看懂发送方的数据结构。3. 数据表示 (Data Representation) —— 数据的传输【翻译】数据表示Data Representation本规范定义了将“类型系统”所定义类型的对象进行外部化序列化的多种方式以便它们可以存储在文件中或在网络上进行传输这通常也被称为“数据序列化”或“数据编组”。本规范扩展并泛化了 DDS 互操作性规范 [RTPS] 中已经定义的机制。本规范包含支持“数据类型演进”的数据表示即允许数据类型在某些明确定义的规则下发生改变而不会破坏通信。第 7.4 节的子节中指定了两种数据表示分别是扩展 CDR (Extended CDR见 7.4.1、7.4.2 和 7.4.3) 和 XML (7.4.4)。【白话解释】这里指的是“实际的用户数据Payload如何在网络上传输”。老 DDS 只支持标准 CDR纯定长时直接拷贝性能极高但无法变动字段。XTypes 引入了Extended CDR包括PL_CDR和DELIMITED_CDR。它通过在网络数据流中加入“长度标签”和“封装头”从而允许在数据类型发生演进比如结构体变长、字段可选时反序列化引擎依然能准确找到 Padding 并正确解析。4. 语言绑定 (Language Binding) —— 代码怎么调用【翻译】语言绑定Language Binding本规范定义了应用程序访问“类型系统”所定义对象状态的多种方式。本规范扩展并泛化了当前 DDS 规范所隐含的机制“静态语言绑定”/“平铺语言绑定”并增加了一种动态语言绑定Dynamic Language Binding允许应用程序在无需在编译期知晓其类型的情况下访问数据。本规范还定义了一个用于通过编程方式动态定义和操作数据类型的 API。第 7.5 节的子节中指定了两种语言绑定分别是静态语言绑定Plain Language Binding和动态语言绑定Dynamic Language Binding。【白话解释】这里指的是“程序员在写 C/Python 编程时怎么拿到数据”。Plain Language Binding静态绑定就是传统的做法。用工具把 IDL 生成.h和.cpp源码在编译期就知道结构体里有long m1。Dynamic Language Binding动态绑定这是 XTypes 的大招。比如你要做一个通用的数据抓包和显示软件类似 Wireshark你不可能提前把所有用户的 IDL 都编译进你的程序里。动态绑定允许你利用DynamicData和DynamicTypeAPI在运行期动态解析任何接收到的数据如data.get_long_value(m1)从而极大地增强了系统的灵活性。 总结四者的关系结合图 1 的 UML 包图它们形成了一个完美的闭环 总结这段话的核心意思是XTypes 不仅仅是一个网络传输协议它首先是一套完整的编程框架。任何一个 DDS 厂商如果宣称自己支持 XTypes 1.2就必须在生成的代码和库中为程序员提供动态类型DynamicData、类型对象TypeObject的完整编程接口2.1 节并且在网络层2 节至少能够根据封装头去正确解析基本的 CDR 报文。2.1 编程接口一致性 —— 代码层面的硬性指标【翻译】2.1 编程接口一致性本规范扩展了《实时系统数据分发服务规范 [DDS]》增加了一个额外可选的一致性配置文件“可扩展与动态类型配置文件Extensible and Dynamic Types Profile”。就编程接口而言符合本规范应等同于至少符合 DDS 规范现有的“最低配置文件Minimum Profile”以及这个新的“可扩展与动态类型配置文件”。实现即产品也可以符合其他的 DDS 配置文件。新的 DDS “可扩展与动态类型配置文件”应由本规范的以下章节组成【白话解释】这一段是针对API程序员调用的函数和接口提要求的。它说你的 DDS 栈不仅要支持以前最基础的 DDS 函数发布、订阅、QoS等还必须提供 XTypes 带来的新工具箱。具体必须提供哪些工具箱章节呢编程接口必须包含的章节内容【翻译】“DDS 的可扩展和动态主题类型”第 7 节直到并包括“类型表示”第 7.3 节【技术解释】代码层必须实现类型系统Type System的逻辑。你的代码必须能识别什么是定长、什么是变长、什么是可扩展字段并且能够支持生成 IDL 对应的结构体。【翻译】“语言绑定”第 7.5 节【技术解释】必须给程序员提供生成好的 C、Java 或其他语言的静态结构体接口Plain Language Binding。【翻译】“DDS 对类型系统的使用”第 7.6 节但不包括“带 Key 值的 Topic 的互操作性”第 7.6.8 节【技术解释】必须实现 DDS 核心实体如 DataWriter、DataReader、Topic如何去加载和使用这些新类型的 API。但第 7.6.8 节关于 Key 值的高级网络互操作性在最低 API 层面被豁免了因为比较复杂。【翻译】附录 B使用 TypeObject 表示类型【技术解释】协议栈的 API 必须支持把一个数据结构转成TypeObject对象。这意味着代码里必须有相关接口能让程序在运行时导出一个结构体的二进制描述。【翻译】附录 C动态语言绑定Dynamic Language Binding【技术解释】必须提供DynamicData和DynamicType的 API也就是说厂商不能只做静态编译工具他们的库里必须包含动态解析数据的函数比如让程序员可以用data-get_long()这种动态反射方式去读写数据。【翻译】附录 D内置类型【技术解释】必须在代码中内置支持 XTypes 规定的一些标准核心类型。2.2.2 基本网络互操作性配置文件Basic Profile【翻译】2.2.2 基本网络互操作性配置文件此配置文件在“最低配置文件”的基础上增加了类型安全性Type Safety。它能够将“检查发布类型与订阅类型之间的类型兼容性”作为端点匹配的前置条件。 符合基本网络互操作性配置文件要求符合“最低网络互操作性配置文件”以及以下章节“内置 TypeLookup 服务”第 7.6.3.3 节【技术解释】这是更为推荐的标准要求黄金段位。相比最低要求它多了一个核心大招TypeLookup服务类型查找服务。 总结整个 2.2 和 2.3 章节在网络层面上串联起了整个 DDS XTypes 的演进逻辑2.3 可选的 XTYPES 1.1 互操作性配置文件【翻译】2.3 可选的 XTYPES 1.1 互操作性配置文件此配置文件增加了与符合 XTYPES 1.1 版本规范的老旧实现之间的互操作性。 符合 XTYPES 1.1 互操作性配置文件要求符合“基本网络互操作性配置文件”并且支持第 7.6.3.1.1 节“DataRepresentationQosPolicy概念模型”中的版本 1 编码version 1 encoding。【白话解释】这是一个向前兼容的外挂选项王者段位的一部分。 DDS XTypes 在 1.1 版本到 1.2 版本之间对底层的序列化编码格式做过一次大升级从 v1 演进到了 v2。 深度拓展为什么 DDS 需要支持 XML Data Representation你可能会纳闷DDS 不是追求极致的实时性和低延迟吗为什么要引入 XML 这种又大又慢的文本格式主要有以下三个应用场景 总结实现 2.4 节的产品等于在原本高效的二进制传输网络中开辟了一条“高可读性、高兼容性”的文本通道。当它在 RTPS 封装头中看到对应 XML 的Representation Identifier时就会放下计算 Padding 和直接memcpy的那一套转而调用 XML 解析器Parser来处理文本报文。TypeSystem类型系统居于核心定义了数据结构的抽象数学规则。TypeRepresentation类型表示负责把这个结构变成 IDL 或 TypeObject 报文发出去告诉别人结构。DataRepresentation数据表示负责把实际填充了数值的数据变成 CDR 二进制流发出去发真实数据。Language Binding语言绑定给上层程序员提供 C/C# 等语言的 API 接口让他们既能用静态结构体也能用动态 API 来读写这些数据。在标准规范文档中“一致性”指的是“一个 DDS 产品比如 FastDDS、RTI Connext 等要宣称自己支持 XTypes 1.2 标准究竟需要实现哪些功能”。它为厂商划定了合格线、良好线和优秀线。引言与三个一致性级别【翻译】2. 一致性准则本规范确认了两个一致性领域1编程接口一致性——即在 DDS API 层面2网络互操作性一致性——即在 RTPS 协议层面。 此外它定义了两个可选的配置文件ProfilesXTYPES 1.1 互操作性XTYPES 1.1 Interoperability和 XML 数据表示XML Data Representation。存在三个一致性级别Conformance Levels最低一致性Minimal conformance符合 XTYPES 1.2 版本的最低要求是必须符合“编程接口”以及“最低网络互操作性配置文件”。基本一致性Basic conformance符合 XTYPES 1.2 变版本的基本要求是必须符合“编程接口”以及“基本网络互操作性配置文件”。完全一致性Complete conformance符合 XTYPES 1.2 版本的完全要求是必须具备“基本一致性”同时还要符合上述两个可选的配置文件。【白话解释】规范在这里把厂家的产品分成了三个段位。要及格必须同时满足代码层面API和网络层面RTPS 协议的要求青铜选手最低一致性满足 API 要求并能用最基本的网络格式和别人聊天。黄金选手基本一致性满足 API 要求且支持更高级、更完整的网络互操作特性比如完整的类型演进兼容。王者选手完全一致性不仅满足黄金选手的标准还顺带支持了两个外挂技能——兼容老版本 XTypes 1.1并且支持用 XML 格式在网络上传输数据。2.2 网络互操作性一致性总览【翻译】2.2 网络互操作性一致性存在两个网络互操作性配置文件Profiles。一个实现产品可以宣称符合“最低配置文件Minimal profile”或“基本配置文件Basic profile”其中基本配置文件是对最低配置文件的扩展。 无论符合哪种配置文件网络互操作性方面的一致性都必须要求符合《实时发布-订阅有线协议规范 [RTPS]》。【白话解释】这里是在网络传输RTPS 协议层面划分段位。DDS 的核心价值就在于“互操作性”——即 A 厂商的 DDS 节点和 B 厂商的 DDS 节点在同一个局域网里必须能互相连通。所以无论哪个段位底层的 RTPS 协议都是必须严格遵守的铁律。2.2.1 最低网络互操作性配置文件Minimal Profile【翻译】2.2.1 最低网络互操作性配置文件符合最低网络互操作性配置文件要求符合本规范的以下章节“使用 TypeIdentifier 和 TypeObject 表示类型”第 7.3.4 节出自“DDS 对类型系统的使用”第 7.6 节“主题模型”第 7.6.1 节“发现与端点匹配”第 7.6.3 节但不包括“内置 TypeLookup 服务”第 7.6.3.3 节第 7.6.3.1.1 节“DataRepresentationQosPolicy概念模型”其支持仅限于版本 2 编码version 2 encoding。“带 Key 值的 Topic 的互操作性”第 7.6.8 节“扩展 CDR 表示法编码版本 2”第 7.4.2 节“扩展 CDR 编码虚拟机”第 7.4.3 节附录 B使用 TypeObject 表示类型附录 DDDS 内置 Topic 数据类型【技术解释】这是网络互通的底线要求青铜段位。它强制要求产品在网络上必须能实现以下几件事能发送和接收TypeIdentifier和TypeObject节点在网络上广播自己时必须能在报文里带上自己数据结构的“数字指纹”Identifier和“完整蓝图”Object。支持“版本 2 编码”Encoding V2必须使用 XTypes 1.2 引入的全新Extended CDR (v2)来序列化数据。我们在最前面探讨的复杂的对齐、封装头如PLAIN_CDR、DELIMITED_CDR等全部属于这个 v2 编码的范畴。基本的端点匹配Endpoint Matching在节点互相发现Discovery阶段能基本的对上暗号。但这里豁免了“内置 TypeLookup 服务”因为最低要求下大家只靠发现阶段交换的信息就够了。为什么需要它在“最低配置文件”中如果发布方的数据结构非常庞大它的TypeObject二进制蓝图也会非常大。如果在发现阶段直接把这么大的蓝图广播出去会极大地吃掉网络带宽。因此通常只广播一个很小的“数字指纹”TypeIdentifier。Basic Profile 怎么做当接收方收到指纹后如果发现本地没有这个结构体的蓝图它会通过TypeLookup 服务单独向发送方发起一个点对点的请求“兄弟我收到你的类型指纹了但我本地没有这个模型请把你的TypeObject蓝图发我一份。” 拿到蓝图后DDS 在后台自动比对类型兼容性确认没问题了两个节点才正式建立连接Matching。这极大地提升了网络运行效率和类型安全性。如果你的产品只实现了 2.2.1 和 2.2.2那它只能和同样支持 XTypes 1.2 的新设备聊天只懂 v2 语言。如果你实现了 2.3 节意味着你的协议栈不仅懂最新的 v2 语言还能向下兼容用老旧的v1 编码version 1 encoding去和那些好几年没升级过、停留在 XTypes 1.1 时代的老设备无缝通信。Minimal大家必须统一使用新的Extended CDR v2 格式来传数据确保 Padding、变长等新特性在网络层能跑通。Basic引入TypeLookup RPC 服务。大家先发指纹发现对不上时再通过网络按需索取完整的结构体蓝图确保类型安全Type Safety。XTYPES 1.1 Optional额外支持v1 编码确保新老系统混用时网络通信不会中断。2.4 可选的 XML Data Representation 配置文件【翻译】2.4 可选的 XML Data Representation 配置文件此配置文件增加了对XML Data Representation格式的支持。 符合此配置文件要求符合本规范的以下章节“XML Type Representation”第 7.3.2 节“XSD Type Representation”第 7.3.3 节“XML Data Representation”第 7.4.4 节由 附录 A 定义的 XML 架构“XML Type Representation Schema”【技术解释】在默认情况下DDS XTypes 在网络上跑的都是二进制流即前面提到的PLAIN_CDR或PL_CDR因为二进制的解析效率最高、占用带宽最小。但是XTypes 规范非常有远见地引入了XML 支持。如果一个 DDS 产品实现了这个 Profile意味着它同时打通了“用 XML 描述结构”和“用 XML 传输数据”的全链路能力XML / XSD Type Representation (7.3.2 7.3.3):允许系统直接使用 XML 文件或者 XSD (XML Schema Definition) 文件来代替传统的*.idl文件来定义 Topic 的数据结构。XML Data Representation (7.4.4):这是最核心的区别。它意味着在网络传输RTPS Wire Protocol时Data Submessage 里的 Payload有效载荷不再是密密麻麻的二进制 CDR 字节流而是一段纯文本的 XML 字符串Annex A (XML 架构定义):协议栈必须内置符合附录 A 规定的标准 XML 校验规则Schema确保收发双方生成的 XML 报文格式是绝对合规和统一的。与企业级 Web 系统集成很多上层的 IT 系统、Web 服务或云端数据库并不懂底层的 CDR 二进制对齐规则但它们对 XML 或 JSON 的支持是天生的。使用 XML 格式可以让 DDS 数据无需复杂的转换直接对接到企业网关。极佳的可读性与调试性Debugging二进制流如果不结合 IDL 抓包如用 Wireshark 配合插件人类是完全无法直接肉眼阅读的。但如果切换到 XML 模式网络上传输的报文直接就是MyMessagem11/m1m2100/m2/MyMessage调试和抓包分析变得极其简单。动态配置与存储当数据需要持久化存储到文件中比如保存某些配置信息或历史日志XML 格式天然自带结构描述非常方便后续的读取和人工修改。