RTI Connext C API  Version 5.0.0
Filter Use Cases

Working with data filters. More...

Working with data filters.


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 FooDataReader_read_w_condition or FooDataReader_take_w_condition functions. (Conditions may also be used with the APIs FooDataReader_read_next_instance_w_condition and FooDataReader_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, futher specifies the values of the data which the DDS_DataReader wishes to receive.

Custom filters may also be constructed and utilized as described in the Creating Custom Content Filters module.

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 processs.

If the DDS_DataWriter allows (by DDS_DataWriterResourceLimitsQosPolicy::max_remote_reader_filters) and the number of filtered DDS_DataReader is less than or equal to 32, and the DDS_DataReader 's DDS_TransportMulticastQosPolicy is empty, then the DDS_DataWriter will performing filtering and send to the DDS_DataReader only those samples that meet the filtering criteria.

If disallowed by the DDS_DataWriter, or if more than 32 DDS_DataReader require filtering, 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.

Although the filter_expression cannot be changed once the DDS_ContentFilteredTopic has been created, 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 field 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 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.

RTI Connext C API Version 5.0.0 Copyright © Thu Aug 30 2012 Real-Time Innovations, Inc