Giters

jhelovuo / RustDDS

Rust implementation of Data Distribution Service

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Interoperability problem with OpenDDS Shapes demo

ohuopio opened this issue · comments

commented

Data exchange does not work between current RustDDS main (97661f3) and OpenDDS shapes demo v. 3.24.1. Note that v. 3.24.1 is not the latest version of OpenDDS, but the latest OpenDDS Shapes demo which is available as a prebuilt binary.

Visible symptoms:

  • When RustDDS is publishing data, OpenDDS Shapes demo does not display anything
  • When OpenDDS is publishing data, RustDDS keeps logging the following error:

DataReader error Deserialization { reason: "Deserialization error: Unknown representation id RepresentationIdentifier { bytes: [0, 9] }., Topic = Square, Type = TypeDesc { my_name: "ShapeType" }" }

commented

This is very weird.

Does OpenDDS interop with e.g. FastDDS or Connext? What goes on the wire, i.e. contents of the SerializedPayload in DATA submessage?

commented

Does OpenDDS interop with e.g. FastDDS or Connext?

I tested OpenDDS vs. FastDDS, and it works only when FastDDS is publishing. When OpenDDS is publishing, data is not flowing. In both cases, OpenDDS prints the error message ERROR: deserialize_type_info deserialization of type information failed when FastDDS DataReader/Writer is created. I'm not sure if we can infer anything about our interop problem from that..

I also tested RustDDS vs. OpenDDS again. Results were otherwise the same (no data flow), but now RustDDS did not log about any DataReader Deserialization errors. I tested with both the latest RustDDS master commit and the one mentioned in the first post, so I must have changed something but don't really know what. Anyhow, RustDDS does become aware of OpenDDS publications and subscriptions, but this does not result to data being exhanged: I cannot even see any DATA messages (for this topic) on WireShark.

The DataReader error Deserialization in the first post contains this:

Unknown representation id RepresentationIdentifier { bytes: [0, 9] }

This RepresentationIdentifier is defined in the XTypes spec (Table 60 - RTPS encapsulation identifier) as:

  • Representation: XCDR
  • ExtensibilityKind: APPENDABLE
  • Encoding Version: 2
  • Endianess: Little Endian

RustDDS does not support XTypes / is not aware of this RepresentationIdentifier, so that's what resulted to the error.

I'll continue investigating this when/if I'll have time from more important tasks.

commented

The observation is correct. OpenDDS tries to use XCDR version 2 encoding by default, which is not supported in RustDDS.

OpenDDS Shapes Demo has an undocumented command line option -xcdr1 that switches to (X)CDR version 1 encoding. This results in sucecssful communication from OpenDDS publisher to RustDDS subscriber.

The other direction (RustDDS --> OpenDDS) does not yet work. RustDDS detects a joining OpenDDS Reader, and DATA submessages are sent, but OpenDDS Shapes Demo application does not show any received data.

commented

There was a bug in RustDDS's deserialization of DiscoveredReaderData (and similarly for Writers). The deserialization was looking for a wrong ParameterId in the parameter list.

OpenDDS announces valid user traffic Locators only when a Reader is created by the application, not yet at DomainParticipant creation time. This behaviour seems to be ok by the RTPS specification, but is different from FastDDS or Connext, so the bug did not have any symptoms with these DDS implementations.

This is now fixed in the current master branch.

In addition, OpenDDS announces Locators that point to the local loopback addresses. This is somewhat suspicious behaviour.

As stated above, OpenDDS Shapes Demo application uses the XCDR version 2 encoding by default, which is not understood by RustDDS. Start the OpenDDS Shapes Demo with
./ishapes -xcdr1 to use the backwards-compatible XCDR version 1.