DDS_MultiChannelQosPolicy Struct Reference

Configures the ability of a DataWriter to send data on different multicast groups (addresses) based on the value of the data. More...

Public Attributes
struct DDS_ChannelSettingsSeq	channels
	A sequence of DDS_ChannelSettings_t used to configure the channels' properties. If the length of the sequence is zero, the QoS policy will be ignored. More...
char *	filter_name
	Name of the filter class used to describe the filter expressions of a MultiChannel DataWriter. More...

Detailed Description

Configures the ability of a DataWriter to send data on different multicast groups (addresses) based on the value of the data.

This QoS policy is used to partition the data published by a DDSDataWriter across multiple channels. A channel is defined by a filter expression and a sequence of multicast locators.

Entity:

DDSDataWriter

Properties:

RxO = N/A
Changeable = NO

Usage

By using this QoS, a DDSDataWriter can be configured to send data to different multicast groups based on the content of the data. Using syntax similar to those used in Content-Based Filters, you can associate different multicast addresses with filter expressions that operate on the values of the fields within the data. When your application's code calls FooDataWriter::write, data is sent to any multicast address for which the data passes the filter.

Multi-channel DataWriters can be used to trade off network bandwidth with the unnecessary processing of unwanted data for situations where there are multiple DataReaders that are interested in different subsets of data that come from the same data stream (Topic). For example, in Financial applications, the data stream may be quotes for different stocks at an exchange. Applications usually only want to receive data (quotes) for only a subset of the stocks being traded. In tracking applications, a data stream may carry information on hundreds or thousands of objects being tracked, but again, applications may only be interested in a subset.

The problem is that the most efficient way to deliver data to multiple applications is to use multicast, so that a data value is only sent once on the network for any number of subscribers to the data. However, using multicast, an application will receive all of the data sent and not just the data in which it is interested, thus extra CPU time is wasted to throw away unwanted data. With this QoS, you can analyze the data-usage patterns of your applications and optimize network vs. CPU usage by partitioning the data into multiple multicast streams. While network bandwidth is still being conserved by sending data only once using multicast, most applications will only need to listen to a subset of the multicast addresses and receive a reduced amount of unwanted data.

Your system can gain more of the benefits of using multiple multicast groups if your network uses Layer 2 Ethernet switches. Layer 2 switches can be configured to only route multicast packets to those ports that have added membership to specific multicast groups. Using those switches will ensure that only the multicast packets used by applications on a node are routed to the node; all others are filtered-out by the switch.

Member Data Documentation

channels

struct DDS_ChannelSettingsSeq DDS_MultiChannelQosPolicy::channels

A sequence of DDS_ChannelSettings_t used to configure the channels' properties. If the length of the sequence is zero, the QoS policy will be ignored.

A sequence length of zero indicates the DDS_MultiChannelQosPolicy is not in use.

The sequence length cannot be greater than DDS_DomainParticipantResourceLimitsQosPolicy::channel_seq_max_length.

[default] Empty sequence.

filter_name

char* DDS_MultiChannelQosPolicy::filter_name

Name of the filter class used to describe the filter expressions of a MultiChannel DataWriter.

The following builtin filters are supported:

• DDS_SQLFILTER_NAME
• DDS_STRINGMATCHFILTER_NAME

Warning

The value for this field can be one of the constants above or a string allocated with DDS_String_dup() to specify your own filter. You should not assign a string literal. When you assign a new value with DDS_String_dup(), first check if the current value is one of the constants above. If it is, simply replace it; if it's not, you have to release the current string and assign the new one. Here is an example of such an approach:

struct DDS_DataWriterQos writer_qos;
char *filter_name = NULL;
DDS_DataWriterQos_initialize(&writer_qos);
...
DDS_Publisher_get_default_datawriter_qos(publisher, &writer_qos);
...

filter_name = writer_qos.multi_channel.filter_name;

if (filter_name == DDS_SQLFILTER_NAME
        || filter_name == DDS_STRINGMATCH_FILTER_NAME) {
    // Since the value was never on the heap, this won't leak memory
    filter_name = NULL;
} else {
    // This means the value is present on the heap
    DDS_String_free(filter_name);
}

// New value using DDS_String_dup() or one of the predefined constants
filter_name = DDS_String_dup("My custom filter name");

. . .

DDS_DataWriterQos_finalize(&writer_qos);

The strings allocated with DDS_String_dup() are released when writer_qos is finalized.

More information about string handling can be found under String Conventions.

[default] DDS_STRINGMATCHFILTER_NAME