RTI Connext Traditional C++ API Version 7.1.0
DDS_PartitionQosPolicy Struct Reference

Set of strings that introduces logical partitions in DDSDomainParticipant, DDSPublisher, or DDSSubscriber entities. More...

Public Attributes

struct DDS_StringSeq name
 A list of partition names. More...
 

Detailed Description

Set of strings that introduces logical partitions in DDSDomainParticipant, DDSPublisher, or DDSSubscriber entities.

This QoS policy is used to set string identifiers that are used for partitioning entities that would otherwise be connected to and exchange data with each other:

Entity:
DDSPublisher, DDSSubscriber, DDSDomainParticipant
Properties:
RxO = NO
Changeable = YES

Usage

The Partition QoS policy provides another way to control which entities will match—and thus communicate with—which other entities. It can be used to prevent entities that would have otherwise matched from talking to each other. Much in the same way that only applications within the same DDS domain will communicate with each other, only entities that belong to the same partition can talk to each other.

The Partition QoS policy allows you to add one or more strings, "partitions", to an entity:

  • A DataWriter and DataReader for the same topic are only considered matched if their Publishers and Subscribers have partitions in common (intersecting partitions).
  • DomainParticipants (with the same domain ID and domain tag) are visible to each other only if they have at least one partition in common.

Since the set of partitions for an entity can be dynamically changed, the Partition QoS policy is useful for creating temporary separation groups among entities that would otherwise be connected to and exchange data with each other.

DomainParticipant partitions and Publisher/Subscriber partitions are independent of each other. You can use both features independently or in combination to provide the right level of isolation.

Failure to match partitions is not considered an incompatible QoS and does not trigger any listeners or conditions. A change in this policy can potentially modify the "match" of existing DataReader and DataWriter entities. It may establish new "matches" that did not exist before, or break existing matches.

Partition strings are usually directly matched via string comparisons. However, partition strings can also contain wildcard symbols so that partitions can be matched via pattern matching. As long as the partitions or wildcard patterns of an entity intersect with the partitions or wildcard patterns of otherwise matching entities, the entities match; otherwise they do not.

These partition name patterns are regular expressions as defined by the POSIX fnmatch API (1003.2-1992 section B.6). A DDSDomainParticipant, DDSPublisher, or DDSSubscriber entity may include regular expressions in partition names, but no two names that both contain wildcards will ever be considered to match. This means that although regular expressions may be used on the entities, RTI Connext will not try to match two regular expressions.

Each entity must belong to at least one logical partition. A regular expression is not considered to be a logical partition. If an entity has not specified a logical partition, it is assumed to be in the default partition. The default partition is defined to be an empty string (""). Put another way:

  • An empty sequence of strings in this QoS policy is considered equivalent to a sequence containing only a single string, the empty string.
  • A string sequence that contains only regular expressions and no literal strings, it is treated as if it had an additional element, the empty string.

Partitions are different from creating DDSEntity objects in different domains in several ways.

  • First, entities belonging to different domains are completely isolated from each other; there is no traffic, meta-traffic or any other way for an application or RTI Connext itself to see entities in a domain it does not belong to.
  • Second, a DDSEntity can only belong to one domain whereas a DDSEntity can be in multiple partitions.
  • Finally, as far as RTI Connext is concerned, each unique data instance is identified by the tuple (DomainID, domain tag, DDSTopic, key). Therefore two DDSEntity objects in different domains cannot refer to the same data instance. On the other hand, the same data instance can be made available (published) or requested (subscribed) on one or more partitions.

For more information, see the "PARTITION QosPolicy" section of the Core Libraries User's Manual.

Member Data Documentation

◆ name

struct DDS_StringSeq DDS_PartitionQosPolicy::name

A list of partition names.

Several restrictions apply to the partition names in this sequence. A violation of one of the following rules will result in a DDS_RETCODE_INCONSISTENT_POLICY when setting a DDSPublisher's or DDSSubscriber's QoS.

  • A partition name string cannot be NULL, nor can it contain the reserved comma character (',').

The memory for the strings in this sequence is managed according to the conventions described in String Conventions. In particular, be careful to avoid a situation in which RTI Connext allocates a string on your behalf and you then reuse that string in such a way that RTI Connext believes it to have more memory allocated to it than it actually does.

[default] Empty sequence (zero-length sequence). Since no logical partition is specified, RTI Connext will assume the entity to be in default partition (empty string partition "").

[range] List of partition name with above restrictions