双向配置 mutable 时 FastDDS 无法订阅 RTIDDS 发布的消息

[l-yuanc]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

在 RTIDDS（RTI Connext DDS）与 FastDDS 的跨厂商通信场景中，发现 mutable 配置影响fastdds数据订阅行为

Current behavior

通过IDL配置双方为 mutable，即在结构体前加@mutable
具体表现为：
当双方均配置为 mutable 时：
FastDDS 作为订阅方，无法接收到 RTIDDS 发布的消息；
FastDDS 自身作为发布方时，消息发布正常（可被RTIDDS 订阅方接收）。
当双方均不配置 mutable 时：
FastDDS 可正常订阅 RTIDDS 发布的消息。
发布也是正常

Steps to reproduce

环境信息

FastDDS 版本：eProsima_Fast-DDS-v3.2.2-Linux
RTIDDS 版本：rti_connext_dds-7.3.0-eval-x64Linux4gcc7.3.0.run
操作系统：Ubuntu 22.04
通信配置：双方使用 相同的 IDL 和 QoS 策略
IDL:

@mutable

struct HelloWorld {
@id(0)    int32 value;
@id(1) unsigned long long bring_up_time_;

@id(2) unsigned long long current_system_time_;

@id(3) octet msg_ddsrolling_counter_;
};

fastddsgen -example CMake ./HelloWorld.idl
/opt/rti_connext_dds-7.3.0/bin/rtiddsgen -example x64Linux4gcc7.3.0 -language c++11 -platform x64Linux4gcc7.3.0 ./HelloWorld.idl

Fast DDS version/commit

tag:v3.2.2

Platform/Architecture

Ubuntu Focal 20.04 amd64

Transport layer

UDPv4

Additional context

No response

XML configuration file

subscriber_->get_default_datareader_qos(reader_qos);
reader_qos.reliability().kind = ReliabilityQosPolicyKind::RELIABLE_RELIABILITY_QOS;
reader_qos.durability().kind = DurabilityQosPolicyKind::VOLATILE_DURABILITY_QOS;
reader_qos.history().kind = HistoryQosPolicyKind::KEEP_ALL_HISTORY_QOS;

Relevant log output

�[37;1m2025-05-27 03:51:19.798 �[33;1m[�[37;1mRTPS_MSG_IN�[33;1m Warning] �[37m(ID:135323807901248) Received message too short, ignoring�[34;1m -> Function �[36mprocessCDRMsg�[m
�[37;1m2025-05-27 03:51:19.814 �[33;1m[�[37;1mHelloWorldSubscriberApp�[33;1m Warning] �[37mHelloWorld Subscriber matched.�[34;1m -> Function �[36mon_subscription_matched�[m
�[37;1m2025-05-27 03:51:19.913 �[33;1m[�[37;1mRTPS_MSG_IN�[33;1m Warning] �[37m(ID:135323782723136) Received message too short, ignoring�[34;1m -> Function �[36mprocessCDRMsg�[m
�[37;1m2025-05-27 03:51:24.170 �[33;1m[�[37;1mHelloWorldSubscriberApp�[33;1m Warning] �[37mHelloWorld Subscriber unmatched.�[34;1m -> Function �[36mon_subscription_matched�[m

Network traffic capture

[l-yuanc]

在代码中打桩加了一些日志，发现是在这一步失败的，报了false
deserialize_sample

[l-yuanc]

继续对代码打桩，报错点在 HelloWorldPubSubType::deserialize
在最后这一步报错了， 跳到了catch

        // Deserialize the object.
        deser >> *p_type;

Exception的内容是这个：
Exception caught during deserialization: Member size provided by member header is not equal to the real decoded member size -> Function deserialize

[l-yuanc]

当双方均配置为 mutable 时，FastDDS 作为发布方时，消息发布正常，RTIDDS 订阅方接收也正常
但抓包发现报文格式解析异常，而且多了很长一串数据

[MiguelCompany]

The distance between two parameter IDs should be a multiple of four.
It seems Wireshark is not taking into account the alignment rule that the DDS-XTypes 1.3 standard mandates.

[l-yuanc]

The distance between two parameter IDs should be a multiple of four. It seems Wireshark is not taking into account the alignment rule that the DDS-XTypes 1.3 standard mandates.

原因分析

有一部分原因是这个，但是主要原因是fastdds 与 rtidds 对长度的描述不一致，
对于一个octet变量，虽然两边都做了4字节对齐(给了4个字节去存储)，但是对长度的描述有区别

• rtidds 发出来的报文中这个成员变量的长度定义是4
  
• fastdds 发出来的报文中这个成员变量的长度定义是1
  

由于这点差异导致fastdds在订阅rti消息时反序列化失败，rti中的长度与实际数据类型不一致：Exception caught during deserialization: Member size provided by member header is not equal to the real decoded member size -> Function deserialize

临时措施

我将IDL 中的 @id(3) octet msg_ddsrolling_counter_; 改为 @id(3) unsigned longmsg_ddsrolling_counter_; 后，fastdds反序列化就可以完成，并成功收到了消息回调

长久措施

所以从fastdds的角度，如何去兼容这一个差异点呢？有没有人可以提供一些帮助