7. Propagating Content Filters

Routing Service can be configured to propagate the content filter information associated with user DataReaders to the user DataWriters.

When this functionality is enabled, the user DataWriters receive information about the data sets subscribed to by the user DataReaders. The DataWriters can use that information to do writer-side filtering [1] and propagate only the samples belonging to the subscribed data sets. This results in more efficient bandwidth usage as well as in less CPU consumption in the Routing Service instances and user DataReaders.

Figure 7.1 shows a scenario where communication between DataWriters and DataReaders is relayed through one or more Routing Services that do not propagate content filters. The user DataWriters will send on the wire all the samples they publish, since they cannot make assumptions about what the user DataReaders want. This default behavior incurs unnecessary bandwidth and CPU utilization since the filtering will occur on the DDS DataWriter SWN.

Communication without propagation of content filters

Figure 7.1 Without propagation, user DataWriters send all the samples; filtering occurs on the last route’s StreamWriter

Enabling filter propagation makes it possible to perform writer-side filtering from the user DataWriters, since they receive a composed filter that represents the data set subscribed to by all the user DataReaders, as shown in Figure 7.2.

System Behavior with Filter Propagation

Figure 7.2 With propagation, user DataWriters receive a composed filter that allows writer-side filtering, thus sending only the samples of interest to the DataReaders

[1]The ability to perform writer-side filtering is subject to some restrictions. For the sake of this discussion, we will assume that the configuration of DataReaders, DataWriters, and Routing Services is such that writer-side filtering is allowed

7.1. Enabling Filter Propagation

Filter propagation is disabled by default in Routing Service. You can enable filter propagation with the <filter_propagation> tag available under the TopicRoute configuration (see Section 3.5.6) and AutoTopicRoute configuration (see Section 3.5.8).

7.2. Filter Propagation Behavior

Without filter propagation, the only way to enforce writer-side filtering in a scenario involving one or more Routing Services between the user DataWriters and user DataReaders is by statically configuring the content filter individually for each DDS StreamReader. This method has two main disadvantages:

  1. It requires knowing beforehand the data set subscribed to by the user DataReaders.
  2. The filters in the StreamReaders are not automatically updated based on changes to the filters in the user DataReaders. This may affect not only bandwidth utilization but also correctness. For example, a user DataReader may not receive a sample because it has been filtered out by one of the StreamReaders.

Filter propagation can address the above issues by dynamically updating the StreamReaders filters. The composed filter associated with a StreamReader in a Route is built by aggregating the filter information associated with all DataReaders that match the Route’s StreamWriter, as shown in Figure 7.3.

Filter Propagation Through Routing Service

Figure 7.3 Filter Propagation Through Routing Service

The composed filter (CF) is the union of the matching DataReaders filters; it allows passing any sample that passes at least one of the DataReader filters.

\[CF = {F_1 \cup F_2 ... } \cup F_N\]

For the SQL filter, the union operator is OR:

\[CF_{SQL} = {F_{SQL1} \cup F_{SQL2} ...} \cup F_{SQLN}\]

Filter propagation occurs within a Route as follows: the Route output StreamWriter gathers the filter information coming from all of its matching DataReaders and provides the resulting composed filter to the Route input StreamReader, whose DataReader is responsible for sending this information to all of its matching DataWriters.

7.3. Filter Propagation Events

These events will cause a StreamReader’s filter to be updated and propagated:

  • Route StreamReader creation: The initial filter is set to the stop-band filter, which is a special kind of filter that does not let any sample pass. This filter is propagated upon SR creation and it will remain unchanged until a matching DataReader to the Route StreamWriter is discovered.
  • Discovery of a matching DataReader in a DataReader: The filter of the discovered DataReader will be aggregated to the existing StreamReader’s filter, which will be propagated after being updated. If the discovered DataReader does not have a filter (subscribes to all the samples) or it has a non-SQL filter, the StreamReader’s filter is set to the all-pass filter (a special filter that lets all sample pass). The all-pass filter will remain set until there are no matching DataReaders to the Route StreamWriter without a filter or with a non-SQL filter.
  • A matching DataReader changes its filter, either in the expression or in the parameters: The StreamReader’s filter is updated to incorporate the latest changes and is propagated afterwards.

7.4. Restrictions

Filter propagation cannot be enabled when:

  • Using Routes or AutoRoutes, since they are meant to work with other adapters different than the builtin DDS one.
  • A transformation is present in the TopicRoute’s output.
  • Using remote administration, if the TopicRoute was enabled and started with the functionality initially disabled.
  • If the StreamReader’s content filter class is not the builtin SQL filter. Filter propagation is not currently supported with other filter classes.