Cyclone DDS CXX communicate with OpenDDS JS Binding

[luojinzhang]

Hi,

Thanks to the demo in this https://github.com/eboasson/i11eperf of @eboasson , I was able to get cyclonedds c++ publisher to work with opendds c++ subscriber. However, when I try to communicate between cyclonedds publisher with opendds jsbinding, I got this error message from the publisher:

1661987970.270809 [32] dq.builtin: invalid parameter list (vendor 1.3, version 2.4): pid 75 (TYPE_INFORMATION) invalid, input = 84,0,0,0,1,16,0,64,40,0,0,0,36,0,0,0,20,0,0,0,241,2,226,168,205,142,140,"j=XX",233,132,176,90,0,56,0,0,0,255,255,255,255,4,0,0,0,0,0,0,0,2,16,0,64,28,0,0,0,24,0,0,0,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0 1661987970.270891 [32] dq.builtin: Invalid SubscriptionBuiltinTopicData (vendor 1.3): invalid qos/parameters

Now I know that the error says qos so it must be the qos problem. But, it does not say which part is wrong and I have absolutely no idea what to do next. I tried using the opendds default qos but no luck either. I have same error when trying to use helloworld publisher from cyclone's example. So I wonder if anyone know what kind of error is this. Thanks.

[eboasson]

Yeah, it could be a bit more descriptive!

I think it is the same as this: https://github.com/eboasson/i11eperf/issues/2#issuecomment-1102224012 (the solution is in there as well). As an apology for producing such an implementors-might-find-this-useful-but-what-the-heck-does-it-mean message:

1661987970.270809 [32] dq.builtin: invalid parameter list (vendor 1.3, version 2.4):

"dq.builtin" is the thread processing incoming discovery messages, in this case one from vendor code 1.3 (which is OpenDDS) with advertised protocol version 2.4 (which is recent), and in doing so it ran into a parameter list (the term used in the DDS specs for the particular representation used for these messages) that was rejected by the validation implemented in Cyclone. In short, it claims OpenDDS is producing nonsense.

pid 75 (TYPE_INFORMATION) invalid,

It concerns parameter id 75, a.k.a. TYPE_INFROMATION. So the problem is with type discovery. In a way that's good, at least it is relatively new for both implementations.

input = 84,0,0,0,1,16,0,64,40,0,0,0,36,0,0,0,20,0,0,0,241,2,226,168,205,142,140,"j=XX",233,132,176,90,0,56,0,0,0,255,255,255,255,4,0,0,0,0,0,0,0,2,16,0,64,28,0,0,0,24,0,0,0,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0

The raw bytes in the parameter value. Something in here is being rejected. It would be nice if it is said "missing CompleteTypeIdentifier" (if my guess is correct), at least that would have given you a clue where to look in the OpenDDS manual.

Now Cyclone requires the CompleteTypeIdentifier to also be present, and if you look at the XTypes specification, section 7.6.3.2.1, page 219 (eliding some irrelevant bits for brevity):

The TypeInformation includes information on the data-type associated with the Endpoint (DataWriter or DataReader, i.e. the TopicType. It includes two fields, minimal and complete.

The field minimal contains the MINIMAL Hash TypeIdentifiers for the TopicType and types that it depends on:

• ...

The field complete contains the COMPLETE HashTypeIdentifiers for the TopicType and types that it depends on:

• The field _complete.typeid_withsize shall contain the COMPLETE Hash TypeIdentifier of the TopicType and the serialized size of the associated TypeObject.
• ...

(inconsistent formatting, including emphasis, missing parenthesis and typos from the spec) this information is required to be present and, again assuming that my guess is right, the type information provided by OpenDDS is correctly rejected. It is also not like OpenDDS can't generate it.

1661987970.270891 [32] dq.builtin: Invalid SubscriptionBuiltinTopicData (vendor 1.3): invalid qos/parameters

I'd have to check the tracing level if these always come in two or it is just at some tracing levels, but it just is a repeat with (even) less information.

[luojinzhang]

Thank you for very informative explanation, I've found a solution.