RTPS TypeObject in proprietary field?

3 posts / 0 new
Log in or register to post comments
Last post
Mon, 03/01/2021 - 06:28
#1
seairth
Offline
Last seen: 11 months 12 hours ago
Joined: 02/07/2020
Posts: 21
RTPS TypeObject in proprietary field?

I'm working on getting an RTI app (Connext 6.0.1) workinng with  another vendor.  I noticed that the type-matching was only using TypeName, but I was expecting them to use the TypeObject.  I ran a wireshark capture and am a little confused about what I'm seeing.  Connext seems to be encoding the type_object in a prorprietary field (0x8021) instead of the one defined by the XTypes spec (0x0072).

What would be causing this, and what can I do to make sure the TypeObject field has the correct ID?

 

Keywords:
Top
Mon, 03/01/2021 - 09:15
johnb@rti.com
Offline
Last seen: 7 months 3 weeks ago
Joined: 01/16/2015
Posts: 3

Hi Seairth,

A new feature introduced with Connext DDS Pro 6.0 is the ability to send TypeObjects in a compressed format.  This improves discovery performance when interacting with other participants that share this capability.  The compression can be disabled.  Please see this section in the Connext DDS Pro 6.0 Migration Guide:

https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/manuals/migration_guide/general.html#section-general-wire-rep-typeobject

-John-

Top
Mon, 03/01/2021 - 09:46
seairth
Offline
Last seen: 11 months 12 hours ago
Joined: 02/07/2020
Posts: 21

Thanks, that looks exactly like the problem we are encountering.  We'll try disabling the compression.

In the meantime, I have a related question:  while I understand that the other vendor's software wouldn't perform the strong type-matching, shouldn't Connext still have done it correctly?  I get that the on-the-wire encoding is a different field, but their type object was still available and could have still been compared.  Why would compression have made any difference for that test?

Top