Sequence type enforcement and dds.type_consistency.ignore_sequence_bounds

2 posts / 0 new
Log in or register to post comments
Last post
Wed, 11/08/2017 - 04:51
#1
mmcbroom
Offline
Last seen: 5 months 2 weeks ago
Joined: 10/23/2013
Posts: 43
Sequence type enforcement and dds.type_consistency.ignore_sequence_bounds

Hello,

I am looking for a more detailed explanation of how type consistency enforcement works when the writer sequence max length is greater than the reader and the topic type has nested sequences.    The documentation for QoS parameter dds.type_consistency.ignore_sequence_bounds indicates that this parameter will disable enforcement as long as the used length in a particular sample is <= max length of the reader.  However, for nested sequences, I have found that this does not work.  Consider the following example IDL:

struct SubSubBus
   {
        long                    i32;
        sequence<long, 6>       seqi32;
   }; 

struct SubBus
   {
        unsigned long           u32;
        sequence<SubSubBus, 4>  subSubBus;
   }; 

struct TopBus
   {
        long                    id;
        sequence<SubBus, 12>    subBus;
   };

 

What I have found is that the above mentioned QoS parameter only allows samples to be received when the max length of the top sequence in the hierarchy differs between writer and reader (i.e. writer changed to  <SubBus, 15>  ). 

However, if I make the max length of one of the nested sequences longer in the writer ( <SubSubBus, 6>, the QoS parameter does not allow reader to receive samples, even though the actual length of the sequence sent is <= 4.

For my particular application, I need to support a writer built with nested sequences in which all max lengths are longer than the reader.  Is this possible?  Is there a bug in the code for dds.type_consistency.ignore_sequence_bounds?

Thanks.

Mark.

Organization:
Keywords:
Top
Tue, 11/14/2017 - 05:34
ajimenez
ajimenez's picture
Offline
Last seen: 2 years 5 months ago
Joined: 09/29/2017
Posts: 21

Hi Mark,

I have already answered you through the support portal. However, this comment could be useful for other customers.

I was able to reproduce your scenario with nested sequences, it is a bug with the following ID CORE-8338. Please, keep this ID for future references.

The goal is to enable the communication between the entities with different types. For the moment, a workaround is to not send the TypeObject and TypeCode for discovery and the matching will be done through the type name. You can find more information in this knowledge base article: link

It can be done through the XML configuration file:

    <participant_qos>
       <resource_limits>
            <type_code_max_serialized_length>0</type_code_max_serialized_length>
            <type_object_max_serialized_length>0</type_object_max_serialized_length>
        </resource_limits>
    </participant_qos>

Best,

Antonio

Top