Why does communication fail when I use one of the built-in QoS profiles?

If you are inheriting from either the BuiltinQosLibExp::Generic.HighThroughput or the BuiltinQosLibExp::Generic.AutoTuning built-in QoS profiles, your DataWriters and DataReaders may fail to communicate if you are writing small samples. In version 5.1.0, if you were writing samples smaller than 384 bytes you would run into this problem. In version 5.2.0 onward, you will experience this problem when writing samples smaller than 120 bytes. The rest of this article is written assuming RTI Connext version 5.2.0 or later, therefore if you are running version 5.1.0 numbers referred to will be different but the concepts and solutions are still applicable.

The reason that this communication failure happens is because of an interaction between the batching QoS settings in the Generic.HighThroughput profile and the DataReader's max_samples resource limit of 256, set in the BuiltinQosLibExp::Generic.StrictReliable profile. The size of the batches that the DataWriter writes are limited to 30720 bytes (see max_data_bytes). This means that if you are writing samples with size smaller than 120 bytes, each batch will have more than 256 samples in it. Because the DataReader's max_samples resource limit is set to 256, the DataReader cannot handle a batch with more than 256 samples and the batch will be dropped.

There are a number of ways to fix this problem, the most straightforward of which is to overwrite the DataReader's max_samples resource limit. You should use a higher value in your own QoS profile that accommodates the number of samples that will be sent in each batch. (Simply divide 30720 by the size of your samples).

You could also limit the size of the batches based on max_samples, by decreasing the batch.max_samples limit from LENGTH_UNLIMITED to any value smaller than the DataReader's max_samples resource limit. Decreasing the size of the batches, however, may also decrease your throughput.