DDS::PartitionQosPolicy Class Reference

Set of strings that introduces a logical partition among the topics visible by a DDS::Publisher and a DDS::Subscriber. More...

#include <managed_infrastructure.h>

Static Public Member Functions
static System::String ^	get_partition_qos_policy_name ()
	Stringified human-readable name for DDS::PartitionQosPolicy. More...

Public Attributes
StringSeq ^	name
	A list of partition names. More...

Detailed Description

Set of strings that introduces a logical partition among the topics visible by a DDS::Publisher and a DDS::Subscriber.

This QoS policy is used to set string identifiers that are used for matching DataReaders and DataWriters for the same Topic.

A DDS::DataWriter within a DDS::Publisher only communicates with a DDS::DataReader in a DDS::Subscriber if (in addition to matching the DDS::Topic and having compatible QoS) the DDS::Publisher and DDS::Subscriber have a common partition name string.

Entity:

DDS::Publisher, DDS::Subscriber

Properties:

RxO = NO
Changeable = YES

Usage

This policy allows the introduction of a logical partition concept inside the 'physical' partition induced by a domain.

Usually DataReaders and DataWriters are matched only by their topic (so that data are only sent by DataWriters to DataReaders for the same topic). The Partition QoS policy allows you to add one or more strings, "partitions", to a Publisher and/or Subscriber. If partitions are added, then a DataWriter and DataReader for the same topic are only considered matched if their Publishers and Subscribers have partitions in common (intersecting partitions).

Since the set of partitions for a publisher or subscriber can be dynamically changed, the Partition QoS policy is useful to control which DataWriters can send data to which DataReaders and vice versa – even if all of the DataWriters and DataReaders are for the same topic. This facility is useful for creating temporary separation groups among entities that would otherwise be connected to and exchange data each other.

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 a Publisher intersect with the partitions or wildcard patterns of a Subscriber, their DataWriters and DataReaders of the same topic are able to match; otherwise they are not.

These partition name patterns are regular expressions as defined by the POSIX fnmatch API (1003.2-1992 section B.6). Either DDS::Publisher or DDS::Subscriber 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 both at publisher as well as subscriber side, RTI Connext will not try to match two regular expressions (between publishers and subscribers).

Each publisher and subscriber must belong to at least one logical partition. A regular expression is not considered to be a logical partition. If a publisher or subscriber has not specify 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 DDS::Entity 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 DDS::Entity can only belong to one domain whereas a DDS::Entity can be in multiple partitions.
• Finally, as far as RTI Connext is concerned, each unique data instance is identified by the tuple (DomainID, DDS::Topic, key). Therefore two DDS::Entity 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.

Member Data Documentation

name

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_InconsistentPolicy when setting a DDS::Publisher's or DDS::Subscriber's QoS.

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

• The maximum number of partition name strings allowable in a DDS::PartitionQosPolicy is specified on a domain basis in DDS::DomainParticipantResourceLimitsQosPolicy::max_partitions. The length of this sequence may not be greater than that value.

• The maximum cumulative length of all partition name strings in a DDS::PartitionQosPolicy is specified on a domain basis in DDS::DomainParticipantResourceLimitsQosPolicy::max_partition_cumulative_characters.

[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

Referenced by get_partition_qos_policy_name().