DDS每个数据包和域ID大小的数据开销

1- DDS Connext v 5.2.0的数据开销是多少？ 我读了一篇关于它的文件（https://www.rti.com/hubfs/docs/DDS_Over_Low_Bandwidth.pdf），它说是56字节。但我想知道每个数据包的动态数据和动态类型的存储位置。 我认为他们肯定需要更多空间。

2-是否可以增加域ID大小？ 它是8位（0到232加保留ID）（例如将其增加到16位字）

数据类型通常（假设默认设置和合理大小的数据类型）在发现阶段通过网络发送，从而使您无需每次都发送它。

尽力而为的基本qos通道（假设您使用最终可扩展性）的开销实际上只是rtps标头，其中包括编写器的ID，序列号以及该机制使用的一些其他数据。

然而，使用可靠性迫使你发送acknacks（你可以控制它但它是机制的一部分），使用生动力迫使你发送心跳，即使你不做前者，rti的正常行为是定期发布多播发现数据（尽管如此，它几乎没有影响）

如果您选择使用可变类型（而不是使用最终可扩展性），则会有更多开销，因为每个样本必须包含存在哪些字段的数据。

如上所述，大约1KB的数据的rti开销最多是微不足道的（如果你可以利用批处理并且具有64KB大小的数据包，那么它甚至会好得多，尽管在这些情况下延迟可能会受到一些影响）

编辑：罗伊打败了我的答案，但我已经输入了大部分内容，所以即使它复制了他已经说过的一些内容，它仍然会发生...

（1）数据开销

动态类型不随每条数据消息一起发送。 相反，它只是在发现时与DataReader或DataWriter的声明一起发送，因此它不算作“数据开销”的一部分。

我不确定你的“动态数据”是什么意思。 数据以序列化形式发送。 如果应用程序没有编译时知识，“DynamicData”只是一个访问它的API。 但无论访问API如何，线路上的格式始终相同。 它是DDS-XTYPES规范中定义的名为XCDR的二进制格式。

开销没有单一的答案。 有多种情况和配置选项会影响它。 我将在下面解释它，但是数字56字节是一个很好的近似帽子，你会在常见的情况下看到。 如果有疑问，最简单的可能是运行wireshark并查看您在特定场景中获得的开销。

根据DDS-RTPS协议，在线路上发送应用数据的“最小”开销是48字节。 这是UDP / IP传输头的补充。 我在下面复制了DDS-RTPS规范中线路格式的草图：

0               8               16              24              32     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 000 |      ‘R’      |      ‘T’      |      ‘P’      |      ‘S’      |     +---------------+---------------+---------------+---------------+ 004 |           protocolVersion     |     vendorId                  |     +---------------+---------------+---------------+---------------+ 008 |                                                               |     +                                                               + 012 |                       guidPrefix   (12 bytes)                 |     +                                                               + 016 |                                                               |     +---------------+---------------+---------------+---------------+ 020 |    DATA       |X|X|X|X|K|D|Q|E|     octectsToNextHeader       |     +---------------+---------------+---------------+---------------+ 024 |           extraFlags          |     octectsToInlineQos        |     +---------------+---------------+---------------+---------------+ 028 |                       readerId              (4 Bytes)         |     +---------------+---------------+---------------+---------------+ 032 |                       writerId              (4 Bytes)         |     +---------------+---------------+---------------+---------------+ 036 |                                                               |     +                       writerSequenceNumber  (8 Bytes)         + 040 |                                                               |     +---------------+---------------+---------------+---------------+ 040 |                                                               |     ~                       inlineQos     (ommitted if Q==0)        ~ 040 |                                                               |     +---------------+---------------+---------------+---------------+ 044 |   encapsulationIdentifier     |     encapsulationOptions      |     +   -   -   -   +   -   -   -   +   -   -   -   +   -   -   -   + 048 |                                                               |     ~                       serializedData                          ~     |                                                               |     +---------------+---------------+---------------+---------------+

但是有几件事情。 通常，数据还包括源时间戳。 虽然它可以在同一个RTPS消息中的多个“DATA”消息中共享，但您需要至少有一个。 这又增加了12个字节（见下文）：

0               8               16              24              32     +---------------+---------------+---------------+---------------+ 000 |    INFO_TS    |X|X|X|X|X|X|I|E|     octectsToNextHeader       |     +---------------+---------------+---------------+---------------+ 004 |                                                               |     +                       timeStamp  (8 Bytes)                    + 008 |                                                               |     +---------------+---------------+---------------+---------------+

最后，对于键控数据，通常在“inlineQos”部分中发送KeyHash。 这又增加了16个字节，见下文：

1 2 3 4 5 6 7 8 9 10

0               8               16              24              32     +---------------+---------------+---------------+---------------+ 000 |           PID_KEYHASH         |     length = 8                |     +---------------+---------------+---------------+---------------+ 004 |                                                               |     +                       keyHash  (8 Bytes)                      + 008 |                                                               |     +---------------+---------------+---------------+---------------+ 012 |           PID_SENTINEL        |     padding                   |     +---------------+---------------+---------------+---------------+

通常，多个DATA可以适合相同的RTPS消息。 在这种情况下，RTPS报头和INFO_TS是共享的，每条消息的“额外”开销是28字节（或者带有KeyHash的44）。考虑到所有这些，我会说开销是60到76个字节。 但这是您在RTPS消息中发送单个DATA项。

最后，还有一个“批处理”功能，可以在Connext DDS中配置，它将在同一个DATA消息中组合多个有效负载。 使用此功能，每个数据消息的“开销”可以低至8个字节（没有时间戳或KeyHash ），16个字节（带有时间戳 ），24个字节（带有KeyHash）或32个字节（带有时间戳和KeyHash）。

（2）DomainId大小的增加

你能解释一下你的目标吗？ domainId本身是32个字节。 但是，由于端口号保留，DDS-RTPS将域限制在0到200之间。 每个域保留250个端口的范围，以允许最多124个域参与者在具有确定性分配和非冲突端口号的单个IP地址上运行。

如果您要做的是增加域的数量，并且在同一IP地址上不需要这么多参与者，则可以更改这些默认的RTPS端口映射。我非常有兴趣了解你的用例，因为我们正在实现一个名为“虚拟域”的新功能，这可能有助于以更清洁的方式做类似的事情。