How to know if a sample was filtered on the writer side when using Content FilteredTopics

ContentFilteredTopics allow a DataReader to receive only samples that pass a filter expression. The user application doesn’t know whether a sample has been filtered; nor does it know one detail that may affect performance: the filtering can be applied on either the DataWriter side or the DataReader side.

When the DataReader filters:

  • The DataReader will have to spend some extra CPU cycles in order to apply the filter.

  • Some data was transferred through the network, although it was of no interest to the DataReader. The processing of this data needlessly wastes network resources and could result in a loss of network performance.

The DataWriter applies the filter if certain conditions are met, as described in the Core Libraries User’s Manual (section “5.4.2 Where Filtering is Applied—Publishing vs. Subscribing Side”).

So, how can you tell if the filter is being applied by the DataReader or the DataWriter?

The DataWriter adds a signature to the RTPS packet to tell the DataReader that the sample was already filtered on the DataWriter side, and there is no need to apply it on the DataReader side. This signature is contained within the RTPS packet, under DATA/inlineQoS/PID_CONTENT_FILTER_INFO/filterSignature.

There is no public API for accessing this information (although DDS_DataReaderProtocolStatus provides statistics on filtered samples on the DataReader side), so you need to rely on Wireshark for the information. If filterSignature appears in a sample, the sample was filtered on the DataWriter side. If filterSignature doesn’t appear in a sample, the sample was not filtered on the DataWriter side (either there was no ContentFilteredTopic or it was filtered on the DataReader side). Additionally, the filterSignature changes when the ContentFilteredTopic changes.