The :ref:`configuration` section shows how to configure entity attributes using XML profiles, but this section goes deeper on it, explaining each field with its available values and how to compound the complete XML files.
eProsima Fast RTPS permits to load several XML files, each one containing XML profiles. In addition to the API functions to load user XML files, at initialization eProsima Fast RTPS tries to locate and load several default XML files. eProsima Fast RTPS offers the following options to use default XML files:
- Using an XML file with the name DEFAULT_FASTRTPS_PROFILES.xml and located in the current execution path.
- Using an XML file which location is defined in the environment variable FASTRTPS_DEFAULT_PROFILES_FILE.
An XML profile is defined by a unique name (or <transport_id>
label
in the :ref:`transportdescriptors` case) that is used to reference the XML profile
during the creation of a Fast RTPS entity, :ref:`comm-transports-configuration`, or :ref:`dynamic-types`.
An XML file can contain several XML profiles. The available profile types are :ref:`transportdescriptors`, :ref:`xmldynamictypes`, :ref:`participantprofiles`, :ref:`publisherprofiles`, and :ref:`subscriberprofiles`.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->PROFILES-TRANSPORT-DESCRIPTORS<--> :lines: 1-6, 43-63
The Fast-RTPS XML format uses some structures along several profiles types. For readability, the :ref:`commonxml` section groups these common structures.
Finally, The :ref:`examplexml` section shows an XML file that uses all the possibilities. This example is useful as a quick reference to look for a particular property and how to use it. This XSD file can be used as a quick reference too.
Before creating any entity, it's required to load XML files using Domain::loadXMLProfilesFile
function.
createParticipant
, createPublisher
and createSubscriber
have a version
that expects the profile name as an argument. eProsima Fast RTPS searches the XML profile using
this profile name and applies the XML profile to the entity.
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-LOAD-APPLY-PROFILES :end-before: //!--
To load dynamic types from its declaration through XML see the :ref:`Usage` section of :ref:`xmldynamictypes`.
This section is devoted to general settings that are not constraint to specific entities
(like participants, subscribers, publishers) or functionality (like transports or types).
All of them are gathered under the library_settings
profile.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->CONF-LIBRARY-SETTINGS<--> :end-before: <!--><-->
Currently only the :ref:`intraprocess-delivery` feature is comprised here.
This section allows creating transport descriptors to be referenced by the :ref:`participantprofiles`. Once a well-defined transport descriptor is referenced by a Participant profile, every time that profile is instantiated it will use or create the related transport.
The following XML code shows the complete list of configurable parameters:
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->CONF-TRANSPORT-DESCRIPTORS<--> :lines: 1, 11-39, 53
The XML label <transport_descriptors>
can hold any number of <transport_descriptor>
.
Name | Description | Values | Default |
---|---|---|---|
<transport_id> |
Unique name to identify each transport descriptor. | string |
|
<type> |
Type of the transport descriptor. | :class:`UDPv4`, :class:`UDPv6`, :class:`TCPv4`, :class:`TCPv6`, :class:`SHM` | :class:`UDPv4` |
<sendBufferSize> |
Size in bytes of the socket send buffer. If the value is zero then FastRTPS will use the default size from the configuration of the sockets, using a minimum size of 65536 bytes. | uint32 |
0 |
<receiveBufferSize> |
Size in bytes of the socket receive buffer. If the value is zero then FastRTPS will use the default size from the configuration of the sockets, using a minimum size of 65536 bytes. | uint32 |
0 |
<TTL> |
Time To Live, only for UDP transports . | uint8 |
1 |
<non_blocking_send> |
Whether to set the non-blocking send mode on the socket | bool |
false |
<maxMessageSize> |
The maximum size in bytes of the transport's message buffer. | uint32 |
65500 |
<maxInitialPeersRange> |
The maximum number of guessed initial peers to try to connect. | uint32 |
4 |
<interfaceWhiteList> |
Allows defining :ref:`whitelist-interfaces`. | :ref:`whitelist-interfaces` | |
<wan_addr> |
Public WAN address when using TCPv4 transports. This field is optional if the transport doesn't need to define a WAN address. |
|
|
<output_port> |
Port used for output bound. If this field isn't defined, the output port will be random (UDP only). | uint16 |
0 |
<keep_alive_frequency_ms> |
Frequency in milliseconds for sending :ref:`RTCP<rtcpdefinition>` keep-alive requests (TCP only). | uint32 |
50000 |
<keep_alive_timeout_ms> |
Time in milliseconds since sending the last keep-alive request to consider a connection as broken. (TCP only). | uint32 |
10000 |
<max_logical_port> |
The maximum number of logical ports to try during :ref:`RTCP<rtcpdefinition>` negotiations. (TCP only) | uint16 |
100 |
<logical_port_range> |
The maximum number of logical ports per request to try during :ref:`RTCP<rtcpdefinition>` negotiations. (TCP only) | uint16 |
20 |
<logical_port_increment> |
Increment between logical ports to try during :ref:`RTCP<rtcpdefinition>` negotiation. (TCP only) | uint16 |
2 |
<listening_ports> |
Local port to work as TCP acceptor for input connections. If not set, the transport will work as TCP client only (TCP only). | List <uint16> |
|
<tls> |
Allows to define TLS related parameters and options (TCP only). | :ref:`tcp-tls` | |
<segment_size> |
Size (in bytes) of the shared-memory segment. (OPTIONAL, SHM only). | uint32 |
262144 |
<port_queue_capacity> |
Capacity (in number of messages) available to every Listener (OPTIONAL, SHM only). | uint32 |
512 |
<healthy_check_timeout_ms> |
Maximum time-out (in milliseconds) used when checking whether a Listener is alive & OK (OPTIONAL, SHM only). | uint32 |
1000 |
<rtps_dump_file> |
Complete path (including file) where RTPS messages will be stored for debugging purposes. An empty string indicates no trace will be performed (OPTIONAL, SHM only). | string |
empty |
RTCP is the control protocol for communications with RTPS over TCP/IP connections.
There are more examples of transports descriptors in :ref:`comm-transports-configuration`.
Fast-RTPS allows configuring TLS parameters through the <tls>
tag of its Transport Descriptor.
The full list of options is listed here:
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-TCP-TLS<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<password> |
Password of the private_key_file if provided (or RSA). | string |
|
<private_key_file> |
Path to the private key certificate file. | string |
|
<rsa_private_key_file> |
Path to the private key RSA certificate file. | string |
|
<cert_chain_file> |
Path to the public certificate chain file. | string |
|
<tmp_dh_file> |
Path to the Diffie-Hellman parameters file | string |
|
<verify_file> |
Path to the CA (Certification- Authority) file. | string |
|
<verify_mode> |
Establishes the verification mode mask. | VERIFY_NONE ,
VERIFY_PEER ,
VERIFY_FAIL_IF_NO_PEER_CERT ,
VERIFY_CLIENT_ONCE |
|
<options> |
Establishes the SSL Context options mask | DEFAULT_WORKAROUNDS ,
NO_COMPRESSION ,
NO_SSLV2 ,
NO_SSLV3 ,
NO_TLSV1 ,
NO_TLSV1_1 ,
NO_TLSV1_2 ,
NO_TLSV1_3 ,
SINGLE_DH_USE |
|
<verify_paths> |
Paths where the system will look for verification files. | string |
|
<verify_depth> |
Maximum allowed depth for verify intermediate certificates. | uint32 |
|
<default_verify_path> |
Default paths where the system will look for verification files. | boolean |
false |
<handshake_role> |
Role that the transport will
take on handshaking.
On default, the acceptors act as
SERVER and the connectors as
CLIENT . |
DEFAULT ,
SERVER ,
CLIENT |
DEFAULT |
XML Dynamic Types allows creating eProsima Fast RTPS Dynamic Types directly defining them through XML. It allows any application to change TopicDataTypes without modifying its source code.
The XML Types definition (<types>
tag) can be placed similarly to the profiles tag inside the XML file.
It can be a stand-alone XML Types file or be a child of the Fast-RTPS XML root tag (<dds>
).
Inside the types tag, there must be one or more type tags (<type>
).
Stand-Alone:
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-- STAND ALONE TYPES START --> :end-before: <!-- STAND ALONE TYPES END -->
Rooted:
.. literalinclude:: ../code/XMLTesterAux.xml :language: xml :start-after: <!-- ROOTED TYPES START --> :end-before: <!-- ROOTED TYPES END -->
Finally, each <type>
tag can contain one or more :ref:`Type definitions <Type definition>`.
Defining several types inside a <type>
tag or defining each type in its <type>
tag has the same result.
Enum
The <enum>
type is defined by its name
and a set of enumerators
,
each of them with its name
and its (optional) value
.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-DYN-ENUM<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-DYN-ENUM :end-before: //!-- |
Typedef
The <typedef>
type is defined by its name
and its value
or an inner element for complex types.
<typedef>
corresponds to :class:`Alias` in Dynamic Types glossary.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-TYPEDEF<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-TYPEDEF :end-before: //!-- |
Struct
The <struct>
type is defined by its name
and inner members.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-STRUCT<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-STRUCT :end-before: //!-- |
Structs can inherit from another structs:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-STRUCT-INHERIT<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-STRUCT-INHERIT :end-before: //!-- |
Union
The <union>
type is defined by its name
, a discriminator
and a set of cases
.
Each case
has one or more caseDiscriminator
and a member
.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-UNION<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-UNION :end-before: //!-- |
Bitset
The <bitset>
type is defined by its name
and inner bitfields.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-BITSET<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-BITSET :end-before: //!-- |
A bitfield without name is an inaccessible set of bits. Bitfields can specify their management type to ease their modification and access. The bitfield's bit_bound is mandatory and cannot be bigger than 64.
Bitsets can inherit from another bitsets:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-BITSET-INHERIT<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-BITSET-INHERIT :end-before: //!-- |
Bitmask
The <bitmask>
type is defined by its name
and inner bit_values.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-BITMASK<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-BITMASK :end-before: //!-- |
The bitmask can specify its bit_bound, this is, the number of bits that the type will manage. Internally will be converted to the minimum type that allows to store them. The maximum allowed bit_bound is 64. Bit_values can define their position inside the bitmask.
Member types are any type that can belong to a <struct>
or a <union>
, or be aliased by a <typedef>
.
Basic types
The identifiers of the available basic types are:
boolean |
int64 |
float128 |
byte |
uint16 |
string |
char |
uint32 |
wstring |
wchar |
uint64 |
|
int16 |
float32 |
|
int32 |
float64 |
All of them are defined as follows:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-GENERIC<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-GENERIC :end-before: //!-- |
Arrays
Arrays are defined in the same way as any other member type but add the attribute arrayDimensions
.
The format of this dimensions attribute is the size of each dimension separated by commas.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-ARRAYS<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-ARRAYS :end-before: //!-- |
It's IDL analog would be:
long long_array[2][3][4];
Sequences
Sequences are defined by its name
, its content type
, and its sequenceMaxLength
.
The type of its content should be defined by its type
attribute.
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-SEQUENCES<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-SEQUENCES :end-before: //!-- |
The example shows a sequence with sequenceMaxLength
3
of sequences with sequenceMaxLength
2
with <int32>
contents.
As IDL would be:
sequence<sequence<long,2>,3> my_sequence_sequence;
Note that the inner sequence has been defined before.
Maps
Maps are similar to sequences, but they need to define two types instead of one.
One type defines its key_type
, and the other type defines its elements types.
Again, both types can be defined as attributes or as members, but when defined
as members, they should be contained in another XML element (<key_type>
and <type>
respectively).
Example:
XML | C++ |
---|---|
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-MAPS<--> :end-before: <!--><--> |
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-MAPS :end-before: //!-- |
Is equivalent to the IDL:
map<long,map<long,long,2>,2> my_map_map;
Complex types
Once defined, complex types can be used as members in the same way a basic or array type would be.
Example:
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-COMPLEX<--> :end-before: <!--><-->
In the application that will make use of XML Types, it's mandatory to load the XML file that defines
the types before trying to instantiate DynamicPubSubTypes of these types.
It's important to remark that only <struct>
types generate usable DynamicPubSubType instances.
.. literalinclude:: ../code/CodeTester.cpp :language: cpp :start-after: //XML-USAGE :end-before: //!--
Participant profiles allow declaring :ref:`participantconfiguration` from an XML file.
All the configuration options for the participant belong to the <rtps>
label.
The attribute profile_name
will be the name that the Domain
will associate to the profile to load it
as shown in :ref:`loadingapplyingprofiles`.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-PARTICIPANT<--> :end-before: <!--><-->
Note
- :class:`LOCATOR_LIST` means it expects a :ref:`LocatorListType`.
- :class:`PROPERTIES_POLICY` means that the label is a :ref:`PropertiesPolicyType` block.
- :class:`DURATION` means it expects a :ref:`DurationType`.
- For :class:`BUILTIN` details, please refer to :ref:`builtin`.
- For :class:`ALLOCATION` details, please refer to :ref:`ParticipantAllocationType`.
List with the possible configuration parameter:
Name | Description | Values | Default |
---|---|---|---|
<name> |
Participant's name.
It's not the same
field that profile_name . |
string_255 |
|
<defaultUnicastLocatorList> |
List of default input unicast locators. It expects a :ref:`LocatorListType`. | LocatorListType |
|
<defaultMulticastLocatorList> |
List of default input multicast locators. It expects a :ref:`LocatorListType`. | LocatorListType |
|
<sendSocketBufferSize> |
Size in bytes of the output socket buffer. If the value is zero then FastRTPS will use the default size from the configuration of the sockets, using a minimum size of 65536 bytes. | uint32 |
0 |
<listenSocketBufferSize> |
Size in bytes of the input socket buffer. If the value is zero then FastRTPS will use the default size from the configuration of the sockets, using a minimum size of 65536 bytes. | uint32 |
0 |
<builtin> |
Built-in parameters. Explained in the :ref:`builtin` section. | :ref:`builtin` | |
<port> |
Allows defining the port parameters and gains related to the RTPS protocol. Explained in the Port section. | Port | |
<participantID> |
Participant's identifier.
Typically it will be
automatically generated
by the Domain . |
int32 |
0 |
<throughputController> |
Allows defining a maximum throughput. Explained in the Throughput section. | Throughput | |
<userTransports> |
Transport descriptors to be used by the participant. | List <string> |
|
<useBuiltinTransports> |
Boolean field to indicate to
the system that the participant
will use the default builtin
transport independently of its
<userTransports> . |
bool |
true |
<propertiesPolicy> |
Additional configuration properties. It expects a :ref:`PropertiesPolicyType`. | :ref:`PropertiesPolicyType` | |
<allocation> |
Configuration regarding allocation behavior. It expects a :ref:`ParticipantAllocationType` | :ref:`ParticipantAllocationType` |
Port Configuration
Name | Description | Values | Default |
---|---|---|---|
<portBase> |
Base port . |
uint16 |
7400 |
<domainIDGain> |
Gain in domainId . |
uint16 |
250 |
<participantIDGain> |
Gain in participantId . |
uint16 |
2 |
<offsetd0> |
Multicast metadata offset. | uint16 |
0 |
<offsetd1> |
Unicast metadata offset. | uint16 |
10 |
<offsetd2> |
Multicast user data offset. | uint16 |
1 |
<offsetd3> |
Unicast user data offset. | uint16 |
11 |
This section of the :class:`Participant's rtps` configuration allows defining parameters related with allocation behavior on the participant.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-PARTICIPANT-ALLOCATION<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<max_unicast_locators> |
Maximum number of unicast locators expected on a remote entity. It is recommended to use the maximum number of network interfaces found on any machine the participant will connect to. | UInt32 |
4 |
<max_multicast_locators> |
Maximum number of multicast locators expected on a remote entity. May be set to zero to disable multicast traffic. | UInt32 |
1 |
<total_participants> |
Participant :ref:`CommonAlloc` related to the total number of participants in the domain (local and remote). | :ref:`CommonAlloc` | |
<total_readers> |
Participant :ref:`CommonAlloc` related to the total number of readers on each participant (local and remote). | :ref:`CommonAlloc` | |
<total_writers> |
Participant :ref:`CommonAlloc` related to the total number of writers on each participant (local and remote). | :ref:`CommonAlloc` | |
<max_partitions> |
Maximum size of the partitions submessage. Zero for no limit. See :ref:`MessageMaxSize`. | UInt32 |
|
<max_user_data> |
Maximum size of the user data submessage. Zero for no limit. See :ref:`MessageMaxSize`. | UInt32 |
|
<max_properties> |
Maximum size of the properties submessage. Zero for no limit. See :ref:`MessageMaxSize`. | UInt32 |
This section of the :class:`Participant's rtps` configuration allows defining built-in parameters.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-BUILTIN<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<discovery_config> |
This is the main tag where discovery-related settings can be configured. | :ref:`discovery_config <dconf>` | |
<avoid_builtin_multicast> |
Restricts metatraffic multicast traffic to PDP only. | Boolean |
:class:`true` |
<use_WriterLivelinessProtocol> |
Indicates to use the WriterLiveliness protocol. | Boolean |
:class:`true` |
<domainId> |
DomainId to be used by the RTPSParticipant. | UInt32 |
0 |
<metatrafficUnicastLocatorList> |
Metatraffic Unicast Locator List | |loclist| | |
<metatrafficMulticastLocatorList> |
Metatraffic Multicast Locator List | |loclist| | |
<initialPeersList> |
Initial peers. | |loclist| | |
<readerHistoryMemoryPolicy> |
Memory policy for builtin readers. | |mempol| | |mempoldefault| |
<writerHistoryMemoryPolicy> |
Memory policy for builtin writers. | |mempol| | |mempoldefault| |
<readerPayloadSize> |
Maximum payload size for builtin readers. | UInt32 |
512 |
<writerPayloadSize> |
Maximum payload size for builtin writers. | UInt32 |
512 |
<mutation_tries> |
Number of different ports to try if reader's physical port is already in use. | UInt32 |
100 |
discovery_config
Name | Description | Values | Default |
---|---|---|---|
<discoveryProtocol> |
Indicates which kind of PDP protocol the participant must use. | |protocol| | :class:`SIMPLE` |
<ignoreParticipantFlags> |
Restricts metatraffic using several filtering criteria. | |filterlist| | :class:`NO_FILTER` |
<EDP> |
|
:class:`SIMPLE`, :class:`STATIC` | :class:`SIMPLE` |
<simpleEDP> |
Attributes of the SimpleEDP protocol | :ref:`simpleEDP <sedp>` | |
<leaseDuration> |
Indicates how long this RTPSParticipant should consider remote RTPSParticipants alive. | :ref:`DurationType` | 20 s |
<leaseAnnouncement> |
The period for the RTPSParticipant to send its Discovery Message to all other discovered RTPSParticipants as well as to all Multicast ports. | :ref:`DurationType` | 3 s |
<initialAnnouncements> |
Allows the user to configure the number and period of the initial RTPSparticipant's Discovery messages. | :ref:`Initial Announcements <InitAnnounce>` | |
<staticEndpointXMLFilename> |
StaticEDP XML filename.
Only necessary if <EDP>
is set to :class:`STATIC` |
string |
ignoreParticipantFlags
Possible values | Description |
---|---|
:class:`NO_FILTER` | All Discovery traffic is processed |
:class:`FILTER_DIFFERENT_HOST` | Discovery traffic from another host is discarded |
:class:`FILTER_DIFFERENT_PROCESS` | Discovery traffic from another process on the same host is discarded |
:class:`FILTER_SAME_PROCESS` | Discovery traffic from participant's own process is discarded. |
:class:`FILTER_DIFFERENT_PROCESS | FILTER_SAME_PROCESS` | Discovery traffic from participant's own host is discarded. |
simpleEDP
Name | Description | Values | Default |
---|---|---|---|
<PUBWRITER_SUBREADER> |
Indicates if the participant must use Publication Writer and Subscription Reader. | Boolean |
:class:`true` |
<PUBREADER_SUBWRITER> |
Indicates if the participant must use Publication Reader and Subscription Writer. | Boolean |
:class:`true` |
Initial Announcements
Name | Description | Values | Default |
---|---|---|---|
<count> |
Number of Discovery Messages to send at the
period specified by <period> .
After these announcements, the
RTPSParticipant will continue sending its
Discovery Messages at the
<leaseAnnouncement> rate. |
Uint32 |
5 |
<period> |
The period for the RTPSParticipant to send
its first <count> Discovery Messages. |
:ref:`DurationType` | 100 ms |
Publisher profiles allow declaring :ref:`Publisher configuration <pubsubconfiguration>` from an XML file.
The attribute profile_name
is the name that the Domain
associates to the profile to load it
as shown in the :ref:`loadingapplyingprofiles` section.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-PUBLISHER<--> :end-before: <!--><-->
Note
- :class:`LOCATOR_LIST` means it expects a :ref:`LocatorListType`.
- :class:`PROPERTIES_POLICY` means that the label is a :ref:`PropertiesPolicyType` block.
- :class:`DURATION` means it expects a :ref:`DurationType`.
- For :class:`QOS` details, please refer to :ref:`CommonQOS`.
- :class:`TOPIC_TYPE` is detailed in section :ref:`TopicType`.
Name | Description | Values | Default |
---|---|---|---|
<topic> |
:ref:`TopicType` configuration of the publisher. | :ref:`TopicType` | |
<qos> |
Publisher :ref:`CommonQOS` configuration. | :ref:`CommonQOS` | |
<times> |
It allows configuring some time related parameters of the publisher. | :ref:`Times <pubtimes>` | |
<unicastLocatorList> |
List of input unicast locators. It expects a :ref:`LocatorListType`. | List of :ref:`LocatorListType` | |
<multicastLocatorList> |
List of input multicast locators. It expects a :ref:`LocatorListType`. | List of :ref:`LocatorListType` | |
<throughputController> |
Limits the output bandwidth of the publisher. | Throughput | |
<historyMemoryPolicy> |
Memory allocation kind for publisher's history. | :ref:`historyMemoryPolicy <mempol>` | :class:`PREALLOCATED` |
<propertiesPolicy> |
Additional configuration properties. | :ref:`PropertiesPolicyType` | |
<userDefinedID> |
Used for StaticEndpointDiscovery. | Int16 |
-1 |
<entityID> |
EntityId of the endpoint. | Int16 |
-1 |
<matchedSubscribersAllocation> |
Publisher :ref:`CommonAlloc` related to the number of matched subscribers. | :ref:`CommonAlloc` |
Times
Name | Description | Values | Default |
---|---|---|---|
<initialHeartbeatDelay> |
Initial heartbeat delay. | :ref:`DurationType` | ~45 ms |
<heartbeatPeriod> |
Periodic HB period. | :ref:`DurationType` | 3 s |
<nackResponseDelay> |
Delay to apply to the response of a ACKNACK message. | :ref:`DurationType` | ~45 ms |
<nackSupressionDuration> |
This time allows the RTPSWriter to ignore nack messages too soon after the data has been sent. | :ref:`DurationType` | 0 ms |
Subscriber profiles allow declaring :ref:`Subscriber configuration <pubsubconfiguration>` from an XML file.
The attribute profile_name
is the name that the Domain
associates to the profile to load it
as shown in :ref:`loadingapplyingprofiles`.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-SUBSCRIBER<--> :end-before: <!--><-->
Note
- :class:`LOCATOR_LIST` means it expects a :ref:`LocatorListType`.
- :class:`PROPERTIES_POLICY` means that the label is a :ref:`PropertiesPolicyType` block.
- :class:`DURATION` means it expects a :ref:`DurationType`.
- For :class:`QOS` details, please refer to :ref:`CommonQOS`.
- :class:`TOPIC_TYPE` is detailed in section :ref:`TopicType`.
Name | Description | Values | Default |
---|---|---|---|
<topic> |
:ref:`TopicType` configuration of the subscriber. | :ref:`TopicType` | |
<qos> |
Subscriber :ref:`CommonQOS` configuration. | :ref:`CommonQOS` | |
<times> |
It allows configuring some time related parameters of the subscriber. | :ref:`Times <subtimes>` | |
<unicastLocatorList> |
List of input unicast locators. It expects a :ref:`LocatorListType`. | List of :ref:`LocatorListType` | |
<multicastLocatorList> |
List of input multicast locators. It expects a :ref:`LocatorListType`. | List of :ref:`LocatorListType` | |
<expectsInlineQos> |
It indicates if QOS is expected inline. | Boolean |
:class:`false` |
<historyMemoryPolicy> |
Memory allocation kind for subscriber's history. | :ref:`historyMemoryPolicy <mempol>` | :class:`PREALLOCATED` |
<propertiesPolicy> |
Additional configuration properties. | :ref:`PropertiesPolicyType` | |
<userDefinedID> |
Used for StaticEndpointDiscovery. | Int16 |
-1 |
<entityID> |
EntityId of the endpoint. | Int16 |
-1 |
<matchedPublishersAllocation> |
Subscriber :ref:`CommonAlloc` related to the number of matched publishers. | :ref:`CommonAlloc` |
Times
Name | Description | Values | Default |
---|---|---|---|
<initialAcknackDelay> |
Initial AckNack delay. | :ref:`DurationType` | ~45 ms |
<heartbeatResponseDelay> |
Delay to be applied when a heartbeat message is received. | :ref:`DurationType` | ~4.5 ms |
In the above profiles, some types are used in several different places. To avoid too many details, some of that places have a tag like :class:`LocatorListType` that indicates that field is defined in this section.
It represents a list of :class:`Locator_t`.
LocatorListType is normally used as an anonymous type, this is, it hasn't its own label.
Instead, it is used inside other configuration parameter labels that expect a list of locators and give it sense,
for example, in <defaultUnicastLocatorList>
.
The locator kind is defined by its own tag and can take the values <udpv4>
, <tcpv4>
, <udpv6>
, and
<tcpv6>
:
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-LOCATOR-LIST<--> :end-before: <!--><-->
In this example, there are one locator of each kind in <defaultUnicastLocatorList>
.
Let's see each possible Locator's field in detail:
Name | Description | Values | Default |
---|---|---|---|
<port> |
RTPS port number of the locator. Physical port in UDP, logical port in TCP. | Uint32 |
0 |
<physical_port> |
TCP's physical port. | Uint32 |
0 |
<address> |
IP address of the locator. | string with expected format |
"" |
<unique_lan_id> |
The LAN ID uniquely identifies the LAN the locator belongs to (TCPv4 only). | string (16 bytes) |
|
<wan_address> |
WAN IPv4 address (TCPv4 only). | string with IPv4 Format |
:class:`0.0.0.0` |
PropertiesPolicyType (XML label <propertiesPolicy>
) allows defining a set of generic properties.
It's useful at defining extended or custom configuration parameters.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-PROPERTIES-POLICY<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<name> |
Name to identify the property. | string |
|
<value> |
Property's value. | string |
|
<propagate> |
Indicates if it is going to be serialized along with the object it belongs to. | Boolean |
:class:`false` |
DurationType expresses a period of time and it's commonly used as an anonymous type, this is, it hasn't its own label.
Instead, it is used inside other configuration parameter labels that give it sense, like <leaseAnnouncement>
or
<leaseDuration>
.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-DURATION<--> :end-before: <!--><-->
Duration time can be defined through <sec>
plus <nanosec>
labels (see table below). An infinite value can be
specified by using the values :class:`DURATION_INFINITY`, :class:`DURATION_INFINITE_SEC` and
:class:`DURATION_INFINITE_NSEC`.
Name | Description | Values | Default |
---|---|---|---|
<sec> |
Number of seconds. | Int32 |
0 |
<nanosec> |
Number of nanoseconds. | UInt32 |
0 |
The topic name and data type are used as meta-data to determine whether Publishers and Subscribers can exchange messages. There is a deeper explanation of the "topic" field here: :ref:`Topic_information`.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-TOPIC<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<kind> |
It defines the Topic's kind | :class:`NO_KEY`, :class:`WITH_KEY` | :class:`NO_KEY` |
<name> |
It defines the Topic's name. Must be unique. | string_255 |
|
<dataType> |
It references the Topic's data type. | string_255 |
|
<historyQos> |
It controls the behavior of Fast RTPS when the value of an instance changes before it is finally communicated to some of its existing DataReader entities. | :ref:`HistoryQos <hQos>` | |
<resourceLimitsQos> |
It controls the resources that Fast RTPS can use in order to meet the requirements imposed by the application and other QoS settings. | :ref:`ResourceLimitsQos <rLsQos>` |
HistoryQoS
It controls the behavior of Fast RTPS when the value of an instance changes before it is finally communicated to some of its existing DataReader entities.
Name | Description | Values | Default |
---|---|---|---|
<kind> |
See description below. | :class:`KEEP_LAST`, :class:`KEEP_ALL` | :class:`KEEP_LAST` |
<depth> |
UInt32 |
1000 |
<kind>
is set to :class:`KEEP_LAST`, then Fast RTPS will only attempt to keep the latest values of the
instance and discard the older ones.<kind>
is set to :class:`KEEP_ALL`, then Fast RTPS will attempt to maintain and deliver all the values
of the instance to existing subscribers.<depth>
must be consistent with the :ref:`ResourceLimitsQos <rLsQos>`
<max_samples_per_instance>
.
For these two QoS to be consistent, they must verify that depth <= max_samples_per_instance
.ResourceLimitsQos
It controls the resources that Fast RTPS can use in order to meet the requirements imposed by the application and other QoS settings.
Name | Description | Values | Default |
---|---|---|---|
<max_samples> |
It must verify that
max_samples >= max_samples_per_instance . |
UInt32 |
5000 |
<max_instances> |
It defines the maximum number of instances. | UInt32 |
10 |
<max_samples_per_instance> |
It must verify that :ref:`HistoryQos <hQos>`
depth <= max_samples_per_instance . |
UInt32 |
400 |
<allocated_samples> |
It controls the maximum number of samples to be stored. | UInt32 |
100 |
The quality of service (QoS) handles the restrictions applied to the application.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-QOS<--> :end-before: <!--><-->
Name | Description | Values | Default |
---|---|---|---|
<durability> |
It is defined in :ref:`SettingDataDurability` section. | :class:`VOLATILE`, :class:`TRANSIENT_LOCAL` :class:`TRANSIENT` | :class:`VOLATILE` |
<liveliness> |
Defines the liveliness of the publisher. | :ref:`liveliness-qos` | |
<reliability> |
It is defined in :ref:`reliability` section. | :class:`RELIABLE`, :class:`BEST_EFFORT` | :class:`RELIABLE` |
<partition> |
It allows the introduction of a logical partition concept inside the physical partition induced by a domain. | List <string> |
|
<deadline> |
It is defined in :ref:`deadline-qos` section. | Deadline period as a :ref:`DurationType` | :class:`c_TimeInfinite` |
<lifespan> |
It is defined in :ref:`lifespan-qos` section. | Lifespan duration as a :ref:`DurationType` | :class:`c_TimeInfinite` |
<disablePositiveAcks> |
It is defined in section :ref:`disable-positive-acks-qos` | It is disabled by
default and
duration is set
to
:class:`c_TimeInfinite` |
Throughput Configuration allows to limit the output bandwidth.
Name | Description | Values | Default |
---|---|---|---|
<bytesPerPeriod> |
Packet size in bytes that this controller will allow in a given period. | UInt32 |
4294967295 |
<periodMillisecs> |
Window of time in which no more than <bytesPerPeriod>
bytes are allowed. |
UInt32 |
0 |
Allocation Configuration allows to control the allocation behavior of internal collections for which the number of elements depends on the number of entities in the system.
For instance, there are collections inside a publisher which depend on the number of subscribers matching with it.
See :ref:`realtime-allocations` for detailed information on how to tune allocation related parameters.
Name | Description | Values | Default |
---|---|---|---|
<initial> |
Number of elements for which space is initially allocated. | UInt32 |
0 |
<maximum> |
Maximum number of elements for which space will be allocated. | UInt32 |
0 (means no limit) |
<increment> |
Number of new elements that will be allocated when more space is necessary. | UInt32 |
1 |
While some submessages have a fixed size (for example, SequenceNumber), others have a variable size depending on the data they contain. Processing a submessage requires having a memory chunk large enough to contain a copy of the submessage data. That is easy to handle when dealing with fixed variable submessages, as size is known and memory can be allocated beforehand. For variable size submessages on the other hand, two different strategies can be used:
- Set a maximum size for the data container, which will be allocated beforehand during the participant's setup. This avoids dynamic allocations during message communication. However, any submessages with a larger payload than the defined maximum will not fit in, and will therefore be discarded.
- Do not set any maximum size for the data container, and instead allocate the required memory dynamically upon submessage arrival (according to the size declared on the submessage header). This allows for any size of submessages, at the cost of dynamic allocations during message decoding.
Controls the allocation behavior of the change histories.
- PREALLOCATED: As the history gets larger, memory is allocated in chunks. Each chunk accommodates a number of changes, and no more allocations are done until that chunk is full. Provides minimum number of dynamic allocations at the cost of increased memory footprint. Maximum payload size of changes must be appropriately configured, as history will not be able to accommodate changes with larger payload after the allocation.
- PREALLOCATED_WITH_REALLOC: Like PREALLOCATED, but preallocated memory can be reallocated to accommodate changes with larger payloads than the defined maximum.
- DYNAMIC: Every change gets a fresh new allocated memory of the correct size. It minimizes the memory footprint, at the cost of increased number of dynamic allocations.
- DYNAMIC_REUSABLE: Like DYNAMIC, but instead of deallocating the memory when the change is removed from the history, it is reused for a future change, reducing the amount of dynamic allocations. If the new change has larger payload, it will be reallocated to accommodate the new size.
In this section, there is a full XML example with all possible configuration. It can be used as a quick reference, but it may not be valid due to incompatibility or exclusive properties. Don't take it as a working example.
.. literalinclude:: ../code/XMLTester.xml :language: xml :start-after: <!-->XML-EXAMPLE<--> :end-before: <!--><--> :lines: 2,4-