Communication between opendds and fastdds Opendds sent data Fastdds did not receive it

[hong12234]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

192.168.225.32 send and 192.168.225.1 response，Communication between opendds and fastdds Opendds sent data Fastdds did not receive it，There were three interactions in this message, and the last interaction Fastdds did not receive any data。The figure shows the last packet of 192.168.225.32 data, but FASTDds did not receive the data。

The following figure shows：

Here are the captured network messages：

Current behavior

/

Steps to reproduce

/

Fast DDS version/commit

fastdds 2.1

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

UDPv4

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[hong12234]

1.zip

[hong12234]

Hello, I have caught both normal and abnormal network packets from both parties. The data type analysis is the same, but Fastdds cannot receive the data，Look at the picture,This is the log captured by sending and replying to the compound medicine separately.

[hong12234]

I still don't understand a question, why does fastdds reply with a dimainid of 115 instead of 1.Next, we will upload the network package。

[hong12234]

log.zip

[hong12234]

This is the code we receive data from

[JesusPoderoso]

Hi @hong12234 can you confirm if this is happening to you with Fast DDS v2.12.0? This interoperability issue was solved in that release.

[hong12234]

ban'b版本是这个，现在我尝试用2.12测试

[JesusPoderoso]

Hi @hong12234 , sorry for the previous message, I was wrong. Despite of Fast CDR v2.0.0 introduces the XCDR2 feature, it is not introduced yet in Fast DDS v2.12.0. The XTypes feature, wich is needed for introducing XCDR2 in Fast DDS, is WIP right now. It will be introduced soon in future releases (see our roadmap), and that will allow the interoperability with OpenDDS.

[MiguelCompany]

@hong12234 As an additional note, setting OpenDDS to use XCDR1 representation would make it interoperate with Fast DDS

[hong12234]

@hong12234作为附加说明，将 OpenDDS 设置为使用 XCDR1 表示形式将使其与 Fast DDS 互操作

Setting OpenDDS to use XCDR1 has already been set, otherwise communication would not be possible. However, now there will be multiple data transmissions from OpenDDS in communication, and most of the received data will be different from the actual sender, or the data sent by OpenDDS cannot be received by FastDDS.
Analyzing the RTPS layer, it can be found that the underlying data fastdds does indeed reply to ACKNACK packets, but cannot take the data. No response.

[hong12234]

Refer to this schematic diagram，

This data is two consecutive packets sent by Opendds.

It can also be seen from the heartbeat packet that two packets of data have been written，Fastdds also received data.


I don't understand why two consecutive pieces of data are sent here.And the first packet of data is still incorrect

[hong12234]

Here, Oepndds sends a packet of data, analyzing the underlying interaction between heartbeat packets and ACK packets. At this point, it is reasonable to say that fastdds has already received the data, but in reality, fastdds on_data_available No functions were called。

[hong12234]

ivi_1019_03.zip
This is the packet compression package shown in the screenshot above

[hong12234]

This is our data idl setting,Is it possible to interact with the subject_id The is related, and this data type is defined as @ key。
here are approximately 20 types of subject_id,This is my subscriber's initialization

[hong12234]

Also, here is my CDR version

[JLBuenoLopez]

@hong12234

Thanks for your report. Fast DDS roadmap includes support for XTypes v1.3 specification which includes complete XCDR encoding version 2 support. The intention is to ensure interoperability once XCDRv2 is supported through the OMG DDS interoperability repository (the interoperabilty test suite is run using XCDRv2). I am moving this issue to the support forum, as more work is still needed to find if there is a bug and in which side. Sorry for not being of help. You might consider contacting eProsima's commercial support team for premium support options if this is a need for your project.