RTI Connext .NET API (legacy)  Version 6.1.1
Filter Use Cases

Working with data filters. More...

Working with data filters.

Introduction

RTI Connext supports filtering data either during the exchange from DDS::DataWriter to DDS::DataReader, or after the data has been stored at the DDS::DataReader.

Filtering during the exchange process is performed by a DDS::ContentFilteredTopic, which is created by the DDS::DataReader as a way of specifying a subset of the data samples that it wishes to receive.

Filtering samples that have already been received by the DDS::DataReader is performed by creating a DDS::QueryCondition, which can then used to check for matching samples, be alerted when matching samples arrive, or retrieve matching samples through use of the DDS::TypedDataReader::read_w_condition or DDS::TypedDataReader::take_w_condition functions. (Conditions may also be used with the APIs DDS::TypedDataReader::read_next_instance_w_condition and DDS::TypedDataReader::take_next_instance_w_condition.)

Filtering may be performed on any topic, either keyed or un-keyed, except the Built-in Topics. Filtering may be perfomed on any field, subset of fields, or combination of fields, subject only to the limitations of the filter syntax, and some restrictions against filtering some sparse value types of the Dynamic Data API.

RTI Connext contains built in support for filtering using SQL syntax, described in the Queries and Filters Syntax module.

Overview of ContentFilteredTopic

Each DDS::ContentFilteredTopic is created based on an existing DDS::Topic. The DDS::Topic specifies the field_names and field_types of the data contained within the topic. The DDS::ContentFilteredTopic, by means of its filter_expression and expression_parameters, further specifies the values of the data which the DDS::DataReader wishes to receive.

Once the DDS::ContentFilteredTopic has been created, a DDS::DataReader can be created using the filtered topic. The filter's characteristics are exchanged between the DDS::DataReader and any matching DDS::DataWriter during the discovery process.

If the DDS::DataWriter allows (by DDS::DataWriterResourceLimitsQosPolicy::max_remote_reader_filters), and the DDS::DataReader 's DDS::TransportMulticastQosPolicy is empty, then the DDS::DataWriter will filter out samples that don't meet the filtering criteria.

If disallowed by the DDS::DataWriter, or the DDS::DataReader has set the DDS::TransportMulticastQosPolicy, then the DDS::DataWriter sends all samples to the DDS::DataReader, and the DDS::DataReader discards any samples that do not meet the filtering criteria.

The expression_parameters can be modified using DDS::ContentFilteredTopic::set_expression_parameters. Any changes made to the filtering criteria by means of DDS::ContentFilteredTopic::set_expression_parameters, will be conveyed to any connected DDS::DataWriter. New samples will be subject to the modified filtering criteria, but samples that have already been accepted or rejected are unaffected. However, if the DDS::DataReader connects to a DDS::DataWriter that re-sends its data, the re-sent samples will be subjected to the new filtering criteria.

Overview of QueryCondition

DDS::QueryCondition combine aspects of the content filtering capabilities of DDS::ContentFilteredTopic with state filtering capabilities of DDS::ReadCondition to create a reconfigurable means of filtering or searching data in the DDS::DataReader queue.

DDS::QueryCondition may be created on a disabled DDS::DataReader, or after the DDS::DataReader has been enabled. If the DDS::DataReader is enabled, and has already recevied and stored samples in its queue, then all data samples in the are filtered against the DDS::QueryCondition filter criteria at the time that the DDS::QueryCondition is created. (Note that an exclusive lock is held on the DDS::DataReader sample queue for the duration of the DDS::QueryCondition creation).

Once created, incoming samples are filtered against all DDS::QueryCondition filter criteria at the time of their arrival and storage into the DDS::DataReader queue.

The number of DDS::QueryCondition filters that an individual DDS::DataReader may create is set by DDS::DataReaderResourceLimitsQosPolicy::max_query_condition_filters, to an upper maximum of 32.

Filtering with ContentFilteredTopic

Filtering with Query Conditions

Filtering Performance

Although RTI Connext supports filtering on any field or combination of fields using the SQL syntax of the built-in filter, filters for keyed topics that filter solely on the contents of key fields have the potential for much higher performance. This is because for key-only filters, the DDS::DataReader caches the results of the filter (pass or not pass) for each instance. When another sample of the same instance is seen at the DDS::DataReader, the filter results are retrieved from the cache, dispensing with the need to call the filter function.

This optimization applies to all filtering using the built-in SQL filter, performed by the DDS::DataReader, for either DDS::ContentFilteredTopic or DDS::QueryCondition. This does not apply to filtering perfomed for DDS::ContentFilteredTopic by the DDS::DataWriter.