DDS_PartitionQosPolicy Struct Reference

Set of strings that introduces a logical partition among the topics visible by a DDSPublisher and a DDSSubscriber. More...

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

Detailed Description

Set of strings that introduces a logical partition among the topics visible by a DDSPublisher and a DDSSubscriber.

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

A DDSDataWriter within a DDSPublisher only communicates with a DDSDataReader in a DDSSubscriber if (in addition to matching the DDSTopic and having compatible QoS) the DDSPublisher and DDSSubscriber have a common partition name string.

Entity:

DDSPublisher, DDSSubscriber

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 DDSPublisher or DDSSubscriber 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 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, 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.

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

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