Configuration of RTI DDS and RTI services.
Defines types that can be used by
RTI Replay
Specifies a QoS library and profiles. The
contents of this tag are specified in the same
manner as for an RTI Data Distribution Service
QoS profile file
This element allows configuring DDS Replay
When this option is set, Replay will use the partition information in the database,
in the DCPSPublication table. Replay will no longer create one only writer per
recorded table (topic), but it will create a representative of every writer and publisher
discovered by Recorder whose data was recorded into the table. So, for example, if
two writers were writing topic Square on the same domain, Replay will create two
writers, each one representing an original writer.
One of the implications of this behaviour is that Replay will generate more endpoint
discovery traffic.
Important note: this feature needs the publication key, publisher key and partition
information to have been recorded by Recorder (not the default behaviour!). See the
"Recording fields for partition replication in Replay" section in the User's Manual.
Describes the time synchronization to be used in replaying the entity.
The rate of replay.
AS_FAST_AS_POSSIBLE = as fast as possible.
DEFAULT = as specified by parent.
When replay should begin relative to other topics.
If not specified, immediate replay is assumed.
The reference time for this data stream to be replayed.
If not specified, relative time is assumed.
The time of the first sample to be replayed. If not specified, zero is assumed.
The time of the last sample to be replayed. If not specified, no end is assumed.
The offset applied to starting time, if needed by the mode.
Specifies the relationship of timestamps in the topic being replayed.
Default: AUTOMATIC
Replay of the entity begins automatically.
(For subordinate entities, replay begins when parent replay starts).
Replay of the selected section begins on manual control.
Replay of the selected section begins automatically,
and is restarted immediately after the last data sample.
Replay begins after each child DDS DataWriter has detected
at least one matched reader.
[ CURRENTLY UNSUPPORTED ]
Specifies the relationship of start and stop timestamps in the topic being replayed.
Default: DATABASE_RELATIVE
The time values are relative to the first
timestamp of the topic.
The time values are relative to the first
timestamp of the database.
The time values are relative to the first
timestamp of the service.
The time value are matched absolutely.
Time specified in seconds and nanoseconds
Specifies the source database containing DDS samples.
Controls several aspects of the memory management
performed by Replay Service.
This field should contain the path to the file(s) being
replayed, plus the name of the file without the set or
segment information
Controls the size of the buffers used to store
samples in Replay's Data Writers associated with
this domain object.
This value is used when creating the DynamicData
type support serialization properties, specifically,
the minimum size of the buffer used to hold the
serialized data for a DynamicData object.
It's also used to set some Data Writer QoS values,
like the "pool_buffer_max_size", which determines if
the buffer for a sample is obtained from a
pre-allocated buffer or dynamically allocated.
For Replay to work fine with unbounded sequences
and strings, the default value of this property is
set to 4KB.
Controls how buffers to hold dynamic data samples
are reallocated. The DynamicData serialization
property "trim_to_size" is set directly using this
value.
When true, this value causes that the buffer used to
hold the DynamicData sample will be reallocated to
just fit the size of the sample. The reallocated
buffer's size cannot be smaller than the minimum
serialized size of the buffer.
When false, the buffer for the DynamicData sample
will only be reallocated if the size of the sample
is bigger than the size of the buffer.
The default for this property is set to false in
Replay.
Security settings for Recording Service.
When a database uses security (there are encrypted
tables) then this setting allows Replay to select
the moment the decryption of the encrypted samples
is performed: during startup, before any sample is
published into DDS; or on the fly, Replay will
decrypt samples as it reads them from the database.
This setting allows to select the method used to
provide cryptography material to Replay.
This cryptography type can be used to tell Replay to
use the file specified to get a password to generate
the keys used in the recording session.
This cryptography type can be used to tell Replay the
path of a file containing a serialized version of the
master key to be used in the recording session. The key
must be stored in binary format directly, no text of any
kind. There is no need for a new line.
This cryptography type can be used to tell Replay
that all cryptographic material will be provided by a
dynamic library for creating entities of type
RTIRecorder_CryptoProvider. This class exposes
functions to obtain the master key, as well as to
obtain a new key for a table being created.
This cryptography type is useful to connect with
existing crypto key providing systems and serves as a
bridge between Recorder and they key provisioning
system.
The name of the dynamic library where the functions for
creating and deleting RTIRecorder_CryptoProvider
instances, as well as the implementation of the methods
in these instances.
The library must be in the current application path to
be loaded by Recorder correctly (e.g. it has to be in
the LD_LIBRARY_PATH on Linux).
This method creates an instance of the
RTIRecorder_CryptoProvider interface to be used by
Recorder to obtain cryptographic material.
The method must be present in the dynamic library
specified as the 'dynamic_library' parameter above.
This method deletes a previously existing instance of
the RTIRecorder_CryptoProvider interface.
The method must be present in the dynamic library
specified as the 'dynamic_library' parameter above.
Sets the domain ID associated with the participant.
Database participant configuration.
Defines a single-threaded context for data replay.
Sets the mask, priority and stack size of the
thread associated with this session.
Sets the mask. Default: MASK_DEFAULT
Sets the thread priority.
Default: O.S. default
Sets the thread stack size.
Default: O.S. default
Defines the stored topic to be replayed.
Defines the topic, type, and attributes of the stored data to be replayed.
The topic name used in recording the data, of the data to be replayed.
The type name used in recording the data, of the data to be replayed.
The record group name used in recording the data.
The domain name used in recording the data.
Optionally defines the topic name, type name, DDS QoS,
and attributes of DDS DataWriter to use in replaying the data.
The topic name to be used in replaying the topic.
If not specified, the input topic name will be used.
The type name to be used in replaying the topic.
If not specified, the input type name will be used.
Sets the DDS DataWriter QoS. Default: DDS defaults
Sets the DDS Topic QoS. Default: DDS defaults
Remote access configuration.
Configuration settings for Distributed Logger.
This decryption mode will decrypt any encrypted
tables into an auxiliary table and then replay that
table. This mode is slower at start up but more
efficient afterwards. Recommended when Replay's
startup time is not critical.
This method is somewhat equivalent to using
Converter with the -keepDecrypted option active,
which will export the data but also keep the
decrypted files and tables. Then Replay could be
used normally with the resulting decrypted
files/tables.
This mode is the default when no decryption mode is
specified.
This decryption mode will decrypt samples as they
are being replayed. This option provides faster
startup time then the other option but it will incur
some throughput penalty because the samples will be
decrypted as they are to be published.
If replaying high-throughput data it's recommended
that the DECRYPT_ON_STARTUP option is used instead,
or using Converter first to decrypt the data and
then using Replay with the resulting files/tables.
The type configuration for this Replay Service database.
The XML type configuration for this domain group.
Whether or not to reigster the top-level types with
their canonical names.
Default: True
The default value to use when there are unbounded strings in a type.
Default: 256
The default value to use when there are unbounded
sequences in a type. Default: 256
A list of the paths to be used when searching for the type files.
A path that is used when searching for the type
files.
A list of File Groups associated with this Domain Group. A file
group is parsed into a single Document Object Model (DOM).
A logical group of files.
A list of File Groups associated with this Domain Group. A file
group is parsed into a single Document Object Model (DOM).
Whether or not to reigster the top-level types with
their canonical names. If present overrides the
parent.
The default value to use when there are unbounded
strings in a type. If present overrides the
parent.
The default value to use when there are unbounded
sequences in a type. If present overrides the parent.
A file name.
A collection of type registration properties. These
properties include specific registration names and
topic names to be associated with type definitions found
in the file described in "file_name".
A name of a file containing XML type definitions to be
used by Recorder. The file should exist in any of the
paths for the file group.
A type registration definition.
Whether or not to register the top-level types
with their canonical names. If present overrides
the parent.
Name of the canonical type (as defined in the
XML type-definition file) to be registered.
Collection of DDS registration names to register
the type definition with. If the type definition
defined by "type_name" can have different names
in the wire, this list should contain the
different names that can be recorded.
A collection of Posix expressions defining topic names
that will be bound to the type version defined by
"type_name" when discovered by DDS.
String representing the DDS type name to register the type
with.
A Posix expression to match topic names that will be
associated with the type version defined with "type_name"
when recording.
This type is deprecated use byte instead
This type is deprecated use int32 instead
This type is deprecated use float32 instead
This type is deprecated use float64 instead
This type is deprecated use char8 instead
This type is deprecated use wchar instead
This type is deprecated use char16 instead
This type is deprecated use int16 instead
This type is deprecated use uint16 instead
This type is deprecated use uint32 instead
This type is deprecated use int64 instead
This type is deprecated use uint64 instead
This type is deprecated use float128 instead
<xs:boolean>
<xs:string>
<xs:integer>
<xs:nonNegativeInteger>
<xs:positiveInteger>
<xs:string>
Uses a byte-oriented encoding wich successive bytes separates by comma and each byte represented
either using a decimal or hexadecimal notation. White space is allowed between bytes.
For example:
34, 44, 56,0x44,127,0xf3,
44,233,122, 122, 44, 222
<xs:string>
Name that uniquely identifies this element.
<xs:string>
A QoS Profile can inherit its values from other QoS Profiles described in the XML file
using this attribute.
<xs:string>
It can only be 255 characters in length.
<xs:string>
It can only be 255 characters in length.
<xs:string>
The name of the Property.
<xs:string>
RTI Connext will select a QoS based on the evaluation of this filter expression on the topic name.
<BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS|BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS>
<INSTANCE_SCOPE_DESTINATIONORDER_QOS|TOPIC_SCOPE_DESTINATIONORDER_QOS>
<AUTOMATIC_TRANSPORT_MULTICAST_QOS|UNICAST_ONLY_TRANSPORT_MULTICAST_QOS>
<VOLATILE_DURABILITY_QOS|TRANSIENT_LOCAL_DURABILITY_QOS|TRANSIENT_DURABILITY_QOS|PERSISTENT_DURABILITY_QOS>
<KEEP_LAST_HISTORY_QOS|KEEP_ALL_HISTORY_QOS>
<AUTOMATIC_LIVELINESS_QOS|MANUAL_BY_PARTICIPANT_LIVELINESS_QOS|MANUAL_BY_TOPIC_LIVELINESS_QOS>
<INSTANCE_PRESENTATION_QOS|TOPIC_PRESENTATION_QOS|GROUP_PRESENTATION_QOS>
<INSTANCE_PRESENTATION_QOS|TOPIC_PRESENTATION_QOS|GROUP_PRESENTATION_QOS|HIGHEST_OFFERED_PRESENTATION_QOS>
<DDS_NO_SERVICE_QOS|DDS_PERSISTENCE_SERVICE_QOS|DDS_QUEUING_SERVICE_QOS|DDS_ROUTING_SERVICE_QOS|RECORDING_SERVICE_QOS|REPLAY_SERVICE_QOS|DATABASE_INTEGRATION_SERVICE_QOS>
<BEST_EFFORT_RELIABILITY_QOS|RELIABLE_RELIABILITY_QOS>
<PROTOCOL_ACKNOWLEDGMENT_MODE|APPLICATION_AUTO_ACKNOWLEDGMENT_MODE|APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE>
<SHARED_OWNERSHIP_QOS|EXCLUSIVE_OWNERSHIP_QOS>
<NO_REPLACEMENT_IGNORED_ENTITY_REPLACEMENT|NOT_ALIVE_FIRST_IGNORED_ENTITY_REPLACEMENT>
<UNREGISTERED_INSTANCE_REPLACEMENT|ALIVE_INSTANCE_REPLACEMENT|DISPOSED_INSTANCE_REPLACEMENT|ALIVE_THEN_DISPOSED_INSTANCE_REPLACEMENT|DISPOSED_THEN_ALIVE_INSTANCE_REPLACEMENT|ALIVE_OR_DISPOSED_INSTANCE_REPLACEMENT>
<RTPS_AUTO_ID|xs:string>
A valid IP address
<SYNCHRONOUS_PUBLISH_MODE_QOS|ASYNCHRONOUS_PUBLISH_MODE_QOS>
<NONE_REFILTER_QOS|ALL_REFILTER_QOS|ON_DEMAND_REFILTER_QOS>
<LIVELINESS_BASED_REMOTE_PARTICIPANT_PURGE|NO_REMOTE_PARTICIPANT_PURGE>
<UDPv4|UDPv6|SHMEM|MASK_DEFAULT|MASK_NONE|MASK_ALL> [|<UDPv4|UDPv6|SHMEM>| ... ]
<RTPS_AUTO_ID_FROM_IP|RTPS_AUTO_ID_FROM_MAC|RTPS_AUTO_ID_FROM_UUID>
<MASK_DEFAULT|MASK_NONE|MASK_ALL|BUILTIN_UNICAST|BUILTIN_MULTICAST|USER_UNICAST|USER_MULTICAST> [|<BUILTIN_UNICAST|BUILTIN_MULTICAST|USER_UNICAST|USER_MULTICAST>| ... ]
<MASK_DEFAULT|FLOATING_POINT|STDIO|REALTIME_PRIORITY|PRIORITY_ENFORCE> [|<FLOATING_POINT|STDIO|REALTIME_PRIORITY|PRIORITY_ENFORCE>| ... ]
(See Platform Notes for platform specific details)
<SDP|EDS|SPDP|SEDP|MASK_NONE|MASK_ALL|MASK_DEFAULT> [|<SDP|EDS|SPDP|SEDP>| ... ]
<ZERO_CDR_PADDING|NOT_SET_CDR_PADDING|AUTO_CDR_PADDING>
<LENGTH_UNLIMITED|xs:nonNegativeInteger>
<DURATION_INFINITE_SEC|DURATION_ZERO_SEC|xs:nonNegativeInteger>
<DURATION_INFINITE_NSEC|DURATION_ZERO_NSEC|xs:nonNegativeInteger>
<DURATION_INFINITE_SEC|DURATION_ZERO_SEC|DURATION_AUTO_SEC|xs:nonNegativeInteger>
<DURATION_INFINITE_NSEC|DURATION_ZERO_NSEC|DURATION_AUTO_NSEC|xs:nonNegativeInteger>
<LENGTH_UNLIMITED|xs:positiveInteger>
<LENGTH_AUTO|xs:positiveInteger>
<AUTO_MAX_TOTAL_INSTANCES|xs:positiveInteger>
<THREAD_PRIORITY_DEFAULT|THREAD_PRIORITY_BELOW_NORMAL|THREAD_PRIORITY_LOW|THREAD_PRIORITY_NORMAL|THREAD_PRIORITY_ABOVE_NORMAL|THREAD_PRIORITY_HIGH|xs:positiveInteger>
(See Platform Notes for platform specific details)
<THREAD_STACK_SIZE_DEFAULT|xs:positiveInteger>
(See Platform Notes for platform specific details)
<GUID_AUTO|xs:string>
<DEFAULT_FLOW_CONTROLLER_NAME|FIXED_RATE_FLOW_CONTROLLER_NAME|ON_DEMAND_FLOW_CONTROLLER_NAME|xs:string>
<ENCAPSULATION_ID_CDR_LE|ENCAPSULATION_ID_CDR_BE|ENCAPSULATION_ID_CDR_NATIVE|xs:unsignedShort>
<METP_ENCAPSULATION_ID_SHMEM_LE|METP_ENCAPSULATION_ID_SHMEM_BE|METP_ENCAPSULATION_ID_SHMEM|xs:unsignedShort>
<METP_ENCAPSULATION_ID_IB_RDMA_READ_LE|METP_ENCAPSULATION_ID_IB_RDMA_READ_BE|METP_ENCAPSULATION_ID_IB_RDMA_READ|xs:unsignedShort>
TODO
<SILENT|ERROR|WARNING|LOCAL|REMOTE|ALL>
<PLATFORM|COMMUNICATION|DATABASE|ENTITIES|API|ALL>
<DEFAULT|TIMESTAMPED|VERBOSE|VERBOSE_TIMESTAMPED|DEBUG|MINIMAL|MAXIMAL>
Time specified in seconds and nanoseconds
Time specified in seconds and nanoseconds
Declares a sequence of elements, which correspond to different xs:string.
Sequence number specified in high and low, or as a 64-bit decimal value
Resource allocation settings.
A sequence of elements with valid IP addresses.
RTPS well-known port mapping configuration.
RTI Connext uses the RTPS wire protocol.
The discovery protocols defined by RTPS rely on well-known ports to initiate discovery.
These well-known ports define the multicast and unicast ports on which a Participant will listen for discovery
metatraffic from other Participants.
The discovery metatraffic contains all the information required to establish the presence of remote DDS entities in the network.
The well-known ports are defined by RTPS in terms of port mapping expressions with several tunable parameters,
which allow the user to customize what network ports are used by the middleware.
In order for all Participants in a system to correctly
discover each other, it is important that they all use the
same port mapping expressions.
QoS related to reliable reader protocol defined in RTPS.
It is used to configure a reliable reader according to the
RTPS protocol.
QoS related to the reliable writer protocol defined in RTPS.
It is used to configure a reliable writer according to RTPS protocol.
The reliability protocol settings are applied to batches instead of individual data samples when batching is enabled.
The virtual GUID (Global Unique Identifier).
The virtual GUID is used to uniquely identify different incarnations of the same DataReader.
The association between a DataReader and its persisted state is done using the virtual GUID.
A sequence of elements of non-negative integers
<THREAD_SETTINGS_CPU_NO_ROTATION|THREAD_SETTINGS_CPU_RR_ROTATION>
(See Platform Notes for platform specific details)
The properties of a thread of execution.
(See Platform Notes for platform specific details)
Type representing a list of unicast locators.
A unicast locator specifies a transport class, a unicast address, and a unicast port number on which messages can be received by an entity.
Type representing a function defined into an external library.
Type representing a list of addresses associeted with a topic expression.
Declares a sequence of elements, which correspond to different TransportUnicastSettings_t
entities.
Declares a sequence of elements, which correspond to different TransportMulticast_t
entities.
Type representing a list of multicast locators.
A multicast locator specifies a transport class, a multicast address, and a multicast port number on which messages can be received by an entity.
Declares a sequence of elements, which correspond to different TransportMulticastSettings_t
entities.
Type used to configure the properties of a channel.
Declares a sequence of elements, which correspond to different ChannelSettings_t
entities.
Properties are name/value pairs objects.
Declares a sequence of elements, which correspond to different Property_t
entities.
Declares a sequence of encapsulations.
Type representing a list of transport encapsulations associated to a set of transports.
Declares a sequence of elements, which correspond to different TransportEncapsulationSettings_t
entities.
Endpoint groups are identified by a role_name and a quorum_count.
Declares a sequence of elements, which correspond to different EndpointGroup_t
entities.
On a DataWriter, this QoS policy states the maximum period in
which the application
expects to call write() on the DataWriter, thus publishing a new sample. The application
may call write() faster than the rate set by this QoS policy.
On a DataReader, this QoS policy states the maximum period in
which the application
expects to receive new values for the Topic. The application may receive data faster than
the rate set by this QoS policy.
This policy controls how each subscriber resolves the final value of a data instance that
is written by multiple DataWriters.
The Durability QoS policy controls whether or not, and how,
published samples are
stored by the DataWriter application for DataReaders that are found after the samples
were initially written.
This QoS policy is only used if the DURABILITY QoS policy is
PERSISTENT or TRANSIENT
and you are using RTI Persistence Service, an optional product which may be
purchased separately.
The Entity Factory QoS policy is a mechanism whereby a user can indicate whether entities
should be automatically enabled upon creation by their factory or whether
enabling should be deferred to a later time of the user's own choosing.
This QoS policy provides an area where your application can
store additional information
related to the Publisher and Subscriber. This information is passed between applications
during discovery using built-in topics.
This QoS policy configures the number of samples that RTI
Data Distribution Service will
store locally for DataWriters and DataReaders.
This QoS policy is used to suggest the maximum acceptable delay that is acceptable
between when data is written and when data is received.
The purpose of this QoS is to avoid delivering stale data to the application. Each data
sample written by a DataWriter has an associated expiration time, beyond which the
data should not be delivered to any application. Once the sample expires, the data will
be removed from the DataReader caches, as well as from the transient and persistent
information caches.
The LIVELINESS QoS policy specifies how RTI Data Distribution
Service determines
whether a DataWriter is "alive". A DataWriter's liveliness is used in combination with
the OWNERSHIP QoS policy to maintain ownership of an instance
(note that the DEADLINE QoS policy
is also used to change ownership when a DataWriter is still alive)
The OWNERSHIP QoS policy specifies whether a DataReader will
see changes to an
instance of a Topic from multiple DataWriters. For non-keyed Topics, there is only one
instance of the Topic.
The OWNERSHIP_STRENGTH QoS policy is used to rank DataWriters
of the same
instance of a Topic, so that RTI Connext can decide which DataWriter will
have ownership of the instance when the OWNERSHIP QoS policy
(Section 6.5.13) is set
to EXCLUSIVE.
The PARTITION QoS provides another way to control which DataWriters will match
and thus communicate with which DataReaders. It can be used to prevent DataWriters
and DataReaders that would have otherwise matched with the same Topic and compatible
QoS policies from talking to each other. Much in the same way
that only applications
within the same DDS domain will communicate with each other, only DataWriters and
DataReaders that belong to the same partition can talk to each other.
Since data samples are sent independently over networks that may deliver packets out
of order, the PRESENTATION QoS policy allows you to control
how a Subscriber sorts
and orders the received samples in the DataReader's queue.
Since data samples are sent independently over networks that may deliver packets out
of order, the PRESENTATION QoS policy allows you to control
how a Subscriber sorts
and orders the received samples in the DataReader's queue.
This policy controls the behavior of the DataReader with regards to the lifecycle of the
data instances it manages, that is, the data instances that have been received and for
which the DataReader maintains some internal resources.
This RELIABILITY QoS policy determines whether or not data
published by a
DataWriter will be reliably delivered by RTI Connext to matching
DataReaders.
This SERVICE QoS policy Service QoS policy is used to indicate
what kind of service is associated with the DDS entity.
This QoS policy determines the DataWriter's publishing mode,
either asynchronous or synchronous.
The publishing mode controls whether data is written synchronously in the context of
the user thread when calling write(), or asynchronously in the context of a separate
thread internal to RTI Connext.
The RESOURCE_LIMITS QoS policy controls the memory resources
that RTI Data Distribution
Service allocates and uses for DataWriter or DataReader. One of the most important
fields is max_samples, which sets the size and causes memory to be allocated for the
send or receive queues.
This TIME_BASED_FILTER QoS policy allows you to specify that
data should not be delivered more than once per-specified
period for each data instance, regardless of how fast
DataWriters are publishing new samples of the data instance.
This QoS policy provides an area where your application can
store additional information
related to the Topic. This information is passed between applications during discovery
using built-in topics.
How this information is used will be up to user code. RTI Connext does
not do anything with the information stored as TOPIC_DATA except to pass it to other
applications.
The TRANSPORT_PRIORITY QoS policy allows the user application
to take advantage
of transports that are capable of sending messages with different priorities.
This QoS policy provides an area where your application can
store additional information
related to a DomainParticipant, DataWriter, or DataReader. This information is passed
between applications during discovery using built-in-topics. How this information is used
will be up to user code.
RTI Connext does not do anything with the information stored as
USER_DATA except to pass it to other applications.
This QoS policy determines if the DataWriter will dispose an instance when it is unregistered.
When a DataWriter unregisters an instance, it means that this particular DataWriter has
no more information/data on this instance. When an instance is disposed, it means that
the instance is "dead"-there will no more information/data from any DataWriter on
this instance.
<<RTI Extension>>
<<RTI Extension>>
Resource limits that apply only to DataReader instances.
<<RTI Extension>>
Resource limits that apply only to DataWriter instances.
<<RTI Extension>>
This QoS policy is used to partition the data published by a
DataWriter across multiple
channels . A channel is defined by a filter expression and a sequence of multicast locators.
<<RTI Extension>>
The PROPERTY QoS policy can be used to associate a set of
properties in the form of
(name,value) pairs with a DataReader, DataWriter, or DomainParticipant. This is similar to
the USER_DATA QoS policy, except this policy uses
(name, value) pairs, and you can
select whether or not a particular pair should be propagated
(included in the built-in topic).
<<RTI Extension>>
The purpose of this QoS is to allow the user to attach naming information to created
Entity objects.
It can only be 255 characters in length.
<<RTI Extension>>
Protocol that applies only to DataReader instances.
<<RTI Extension>>
<<RTI Extension>>
Protocol that applies only to DataWriter instances.
<<RTI Extension>>
This QoS policy can be used to decrease the amount of
communication overhead associated
with the transmission and (in the case of reliable communication) acknowledgment
of small samples in order to increase throughput.
<<RTI Extension>>
The DISCOVERY QoS configures how DomainParticipants discover each other on the
network.
<<RTI Extension>>
The DISCOVERY_CONFIG QoS policy is used to tune the discovery
process. It controls
how often to send discovery packets, how to determine when participants are alive or
dead, and resources used by the discovery mechanism.
<<RTI Extension>>
The DOMAIN_PARTICIPANT_RESOURCE_LIMITS QoS policy configures
the
resources used by a DomainParticipant. Many of these resources are used by the internal
RTI Connext database to store information about locally and remotely
created DDS Entities. Some of the parameters configure the data structures used to
search through the database efficiently. Finally, there are parameters that limit the sizes
of variable-length data fields.
<<RTI Extension>>
The WIRE_PROTOCOL QoS policy configures some Real-Time
Publish Subscribe
(RTPS) protocol-related properties for the DomainParticipant. The open RTPS protocol is
used by RTI Connext to format and interpret messages between Domain-
Participants.
<<RTI Extension>>
The EVENT QoS policy configures the internal RTI Data
Distribution Service Event thread.
The purpose of the Event thread is described in Event Thread.
<<RTI Extension>>
The RECEIVER_POOL QoS policy configures the internal RTI Data
Distribution Service
thread used to process the data received from a transport.
<<RTI Extension>>
Built-in topic reader's resource limits.
Defines the resources that can be used for a built-in-topic data reader.
A built-in topic data reader subscribes reliably to built-in topics containing
declarations of new entities or updates to existing entities in the domain.
Keys are used to differentiate among entities of the same type.
RTI Connext assigns a unique key to each entity in a domain.
<<RTI Extension>>
This QoS policy is used to enable or disable asynchronous
publishing and asynchronous
batch flushing for the Publisher.
If enabled, the Publisher will spawn two threads, one for asynchronous publishing and
one for asynchronous batch flushing.
<<RTI Extension>>
The DATABASE QoS policy configures the internal "database"
(thread and data structures)
used by RTI Connext to hold information about locally created
DDS entities and remote entities that are discovered through the discovery process.
<<RTI Extension>>
This QoS policy controls the creation and use of Exclusive
Areas. An exclusive area (EA)
is a mutex with built-in deadlock protection when multiple EAs are in use. It is used to
provide mutual exclusion among different threads of execution. Multiple EAs allow
greater concurrency by the internal and user threads when executing RTI Data Distribution
Service code.
<<RTI Extension>>
The TRANSPORT_BUILTIN QoS policy specifies which built-in
transports can be used
by the DomainParticipant. RTI Connext provides two built-in transports,
UDPv4 and shared memory. UDPv4 uses the IPv4 UDP protocol to send and receive
messages. The shared memory transport uses system shared memory for inter-process
communications.
<<RTI Extension>>
The TRANSPORT_SELECTION QoS policy allows you to select the
transports that have
been installed with the DomainParticipant to be used by the DataWriter or DataReader.
<<RTI Extension>>
The TRANSPORT_UNICAST QoS policy allows you to specify
unicast network
addresses to be used by DomainParticipant, DataWriters and DataReaders for receiving
messages. DomainParticipants receive messages to support the discovery process.
DataWriters may receive ACK/NACK messages to support the reliable protocol.
<<RTI Extension>>
The MULTICAST_MAPPING QoS policy allows you to specify
a list of multicast addresses
to be used by DataReaders for receiving
messages. The address is choosed using the topicname.
<<RTI Extension>>
This QoS policy allows you to specify network multicast
addresses to be used by
DataWriters when sending data samples to this DataReader.
<DISALLOW_TYPE_COERCION|ALLOW_TYPE_COERCION>
The DataWriter and the DataReader must support the same data type
in order for them to communicate.
The DataWriter and the DataReader need not support the same data type
in order for them to communicate as long as the reader’s type is assignable from the writer’s type
The Type Consistency Enforcement QoS Policy defines the rules for determining whether the type used
to publish a given data stream is consistent with that used to subscribe to it.
<<RTI Extension>>
This QoS policy allows you to associate encapsulation formats
to transport destinations.
<<RTI Extension>>
The Logging QoS policy configures the NDDS Config Logger.
<<RTI Extension>>
QoS policies related to DomainParticipants.
QoS policies related to DomainParticipantFactory.
QoS policies related to Publishers.
QoS policies related to Subscribers.
QoS policies related to Topics.
QoS policies related to DataReaders.
QoS policies related to DataWriters.
This profile groups the QoS policies related to DomainParticipants.
This profile groups the QoS policies related to DomainParticipantFactory.
This profile groups the QoS policies related to Topics.
This profile groups the QoS policies related to Publishers.
This profile groups the QoS policies related to Subscribers.
This profile groups the QoS policies related to DataWriters.
This profile groups the QoS policies related to DataReaders.
This profile groups the QoS policies related to DomainParticipants.
This profile groups the QoS policies related to DomainParticipantFactory.
This profile groups the QoS policies related to Topics.
This profile groups the QoS policies related to Publishers.
This profile groups the QoS policies related to Subscribers.
This profile groups the QoS policies related to DataWriters.
This profile groups the QoS policies related to DataReaders.
A QoS profile groups a set of related QoS.
The Qos Library provides a way to group a set of related QoS under a namespace.
The Qos inside a library are further organized into Qos Profiles.
Enumeration type for the specification of Distributed Logger's filter level.
Silent filter level
Fatal filter level
Severe filter level
Error filter level
Warning filter level
Notice filter level
Info filter level
Debug filter level
Trace filter level
Main type for the definition of Distributed Logger configuration.
The filter level to apply to the log messages.
Whether the remote administration of Distributed
Logger is active (true) or not (false).
Whether Distributed Logger should echo log messages to the standard output (true) or not (false).
Whether Distributed Logger should log infrastructure messages.
Thread settings for Distributed Logger.
Size of the Distributed Logger queue for incoming log messages to be written.