Publlished Topic has additional element to topic

2 posts / 0 new
Last post
Last seen: 1 week 5 days ago
Joined: 07/10/2024
Posts: 1
Publlished Topic has additional element to topic


I have a question in regards to topic version differences between the publishing application and the subscribing application...

If I add an additional XML element to particular topic in the QOS configuration for the Publisher side (newer version of the topic)  but do not add that same additional element to the QOS Configuration for the Subscriber (current version of the topic)  what happens?

What happens when the Publisher sends a sample with that new element?

Does the DataWriter send that element to the Subscriber?

If the DataWriter DOES send the additional new element in the sample, what will the DataReader with the unknown element?

Will the DataReader strip it out before sending to the Subscribing application?

Is there a way (return code, etc) to determine that the element was removed from the sample on the subscribing side?


Thanks for any information!

dseltz41's picture
Last seen: 1 week 4 days ago
Joined: 07/21/2016
Posts: 2

Connext DDS by default will do type checking between a reader and a writer to make sure there is a match.  If there is not a match then the connection will fail.  You can turn off type checking:

 DDS_TypeConsistencyEnforcementQosPolicy type_consistency;
 type_consistency.force_type_validation = DDS_BOOLEAN_FALSE;

However, be aware that if the types have the same name but are not assignable, DataReaders may fail to deserialize incoming data samples.

But...  If you have have extensible types enabled (either @appendable or @mutable) then the reader and writer can still communicate and the reader that was defined without the new element will only receive the fields it knows about.  

You can read more from the the manual on Extensible types here:

Here is an example from RTI's new Connext Chatbot:

Example Usage Scenario

Consider a scenario where you have a GPS vehicle tracking system. Initially, the VehicleData type may provide position information such as latitude and longitude. Later, you may want to add speed information. By defining the type as appendable, you can add the speed field at the end without breaking existing applications.

Initial Definition

@appendable struct VehicleData { float latitude; float longitude; };

Extended Definition

@appendable struct VehicleData { float latitude; float longitude; float speed; // New field added };

Type Consistency

When using appendable types, the middleware ensures that DataReaders and DataWriters can still communicate even if the DataWriter's type has additional fields appended. The TypeConsistencyEnforcementQosPolicy can be used to customize the behavior of applications when using extensible types.


There is a lot more to Extensible Types and I would be glad to go over it with you.  Just contact me at