3.5 Add the DDS-XML Definition of the Entities
If you followed the previous steps in this chapter, you should have an application in which each DomainParticipant has a non-null name, each created endpoint has a predefined RTPS object ID, and both DomainParticipants use the LBED Plugin for the Endpoint Discovery phase. However, if you were to run the Publisher and the Subscriber now, you would see error messages similar to the following:
$ ./ExampleLBED_subscriber
…
ERROR [0x01016E46,0x8484F58C,0x5EBD43BE:0x000100C7{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x00000000,0x00000000,0x00000000:0x000100C2|REGISTER DP
"ExampleLBEDParticipantPublisher"|LC:DISC]DDS_LBEDiscoveryPlugin_registerParticipant:The
discovered DomainParticipant [guid=0x01013049,0xFA1254B0,0x6D982A45:0x000001C1] is not in
the file.
ERROR [0x01016E46,0x8484F58C,0x5EBD43BE:0x000100C7{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x00000000,0x00000000,0x00000000:0x000100C2|LC:DISC]DDS_LBEDiscoveryPlugin_
afterRemoteParticipantEnabled:The DomainParticipant "ExampleLBEDParticipantPublisher" cannot
be registered.
…
$ ./ExampleLBED_publisher
…
ERROR [0x01013049,0xFA1254B0,0x6D982A45:0x000100C7{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x00000000,0x00000000,0x00000000:0x000100C2|REGISTER DP
"ExampleLBEDParticipantSubscriber"|LC:DISC]DDS_LBEDiscoveryPlugin_registerParticipant:The
discovered DomainParticipant [guid=0x01016E46,0x8484F58C,0x5EBD43BE:0x000001C1] is not in
the file.
ERROR [0x01013049,0xFA1254B0,0x6D982A45:0x000100C7{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x00000000,0x00000000,0x00000000:0x000100C2|LC:DISC]DDS_LBEDiscoveryPlugin_
afterRemoteParticipantEnabled:The DomainParticipant "ExampleLBEDParticipantSubscriber"
cannot be registered.
…
In addition, no data is exchanged between the Publisher and the Subscriber applications. This is because the endpoints are not being discovered. We are missing the most important requirement of the Limited Bandwidth Endpoint Discovery Plugin: the XML definition of the endpoints that should be discovered (the remote configuration).
The Publisher requires the XML definition of the Subscriber’s endpoints. When the Publisher discovers the Subscriber DomainParticipant, the Publisher will use the name of the Subscriber to look for its definition in the XML file, and will register all the Subscriber’s endpoints with their associated QoS, Topics, and types. In the same way, the Subscriber requires the XML definition of the Publisher’s endpoints. The error messages above tell us that the definition of “ExampleLBEDParticipantSubscriber” and “ExampleLBEDParticipantPublisher” could not be found in the XML file (by default, the USER_QOS_PROFILES.xml if the config_file property in Table 4.1 LBED Configuration Properties for Connext was not specified). Therefore, their endpoints could not be registered.
To define the Publisher and Subscriber DomainParticipants information, the LBED Plugin uses the OMG’s DDS Consolidated XML Syntax (DDS-XML), a standard that determines how to represent and describe DDS entities and resources using XML. This is the same standard that XML-Based Application Creation uses. For more information about DDS-XML, it is recommended to read XML Tags for Configuring Entities, in the RTI Connext Core Libraries XML-Based Application Creation Getting Started Guide or the OMG’s DDS Consolidated XML Syntax (DDS-XML) specification.
There are two ways of specifying the DDS-XML definition of the entities for LBED: directly in the USER_QOS_PROFILES.xml (in 3.5.1 Using the USER_QOS_PROFILES.xml) or by creating a separate XML file for each DomainParticipant (in 3.5.2 Using a Separate XML File). Choose one way for your application.
3.5.1 Using the USER_QOS_PROFILES.xml
If the config_file property was not specified when enabling LBED in a DomainParticipant (see 3.4.2 Using the LBED Plugin Properties), the plugin will look for the DDS-XML definition of the endpoints in USER_QOS_PROFILES.xml by default. By using this approach, no additional XML files are required. Your USER_QOS_PROFILES.xml will contain the definition of the QoS used by your entities, as well as the DDS-XML static definition of the endpoints required by LBED. In other words, the file will contain both local and remote configurations.
LBED needs to know the following information about the entities:
- For each DomainParticipant using LBED whose endpoints need to be statically-discovered, LBED must know the DomainParticipant's topology: how many Publishers/Subscribers it has, how many DataWriters/DataReaders there are per Publisher/Subscriber, and if the endpoints are using an implicit Publisher/Subscriber.
- For the entities above, which QoS they are using.
- The Topic to which each endpoint is attached.
- The type that each Topic uses.
You will learn how to add each one of these requirements to the USER_QOS_PROFILES.xml file in the following sections.
To get XML file validation and autocompletion during editing, change the USER_QOS_PROFILE.xml's XSD from rti_dds_qos_profiles.xsd to rti_dds_profiles.xsd:
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="file:///<NDDSHOME>/resource/schema/rti_dds_profiles.xsd">
...
3.5.1.1 Add the types used by the endpoints
Your application Topics use the ExampleLBED type that was generated from the IDL in 3.1 Generate Connext Project. You need to specify the XML type definition of that type in the USER_QOS_PROFILES.xml file using the <types> tag.
If your application uses a Built-in Data Type instead (see Built-in Data Types, in the RTI Connext Core Libraries User's Manual), this definition is not required and you can skip this step.
It is possible to convert from an IDL file to XML using Code Generator (rtiddsgen):
$ rtiddsgen -convertToXml ExampleLBED.idl
This will generate a file called ExampleLBED.xml. Copy and paste the <types> tag and its content into the USER_QOS_PROFILES.xml after the <qos_library> section:
<types>
<struct name= "ExampleLBED">
<member name="data" type="int32"/>
</struct>
</types>
This step is optional but recommended when using user-defined types.
If the definition of the type is not provided in the XML file, the LBED plugin will automatically check if there is a type with the same name registered in the DomainParticipant of the local application (the one that created the plugin instance) and will use its definition. This check works out if the type in the local DomainParticipant is the same as the one used by the endpoints that need to be discovered, which would be true in correct system configurations. But if you have different types with the same name, you may get undefined behaviors in LBED (e.g., no discovery).
Therefore, if you decide to not add the XML type definition, to avoid errors, it is recommended that you create the DomainParticipant disabled, register the type in the application, and then enable the DomainParticipant. That way, you ensure LBED does not start registering endpoints until the type has been registered in the participant.
To create a DomainParticipant disabled, set autoenable_created_entities in the DomainParticipantFactory ENTITYFACTORY QosPolicy to false. See Enabling DDS Entities, in the RTI Connext Core Libraries User's Manual for information about how to enable the DomainParticipant. See Data Types and DDS Data Samples, in the RTI Connext Core Libraries User's Manual for information about registering types.
3.5.1.2 Add the Topics
The endpoints of the generated application use a single Topic called "Example ExampleLBED". In DDS-XML, Topics are specified inside a domain tag which, in turn, is specified inside a domain_library. This exercise assumes the application uses domain ID 0, but you can use whichever ID you prefer.
Copy and paste the following XML snippet in your USER_QOS_PROFILES.xml file after the types tag you added in the previous step (modify the domain_id attribute if you want to use another ID):
<domain_library name="ExampleLBED_Domain_Library">
<domain name="ExampleLBED_Domain" domain_id="0">
<register_type name="ExampleLBED" type_ref="ExampleLBED"/>
<topic name="Example ExampleLBED" register_type_ref="ExampleLBED"/>
</domain>
</domain_library>
Regarding the snippet above:
- The names of the domain_library and domain tags are just examples. You can use any names you like.
- Make sure the name attribute of the topic tag is the same as the name with which the Topic is created in the application.
- The LBED plugin uses the register_type tag for associating a Topic with its XML type definition. Therefore:
- If your application uses a Built-in Data Type instead (see Built-in Data Types, in the RTI Connext Core Libraries User's Manual), the register_type tag is not required and you can put the name of the Built-in Data Type directly in the Topic’s register_type_ref attribute. For example:
- If you decided to not add the XML type definition to the file in 3.5.1.1 Add the types used by the endpoints, the register_type tag is not required and you can put the name of your type directly in the Topic’s register_type_ref attribute. For example:
<domain name="ExampleLBED_Domain" domain_id="0">
<topic name="Example ExampleLBED" register_type_ref="DDS::String"/>
</domain>
<domain name="ExampleLBED_Domain" domain_id="0">
<topic name="Example ExampleLBED" register_type_ref="ExampleLBED"/>
</domain>
- The register_type tag is also used for specifying the name with which the type referenced by type_ref (which must be an existing type under the types tag) is registered in the application. In this case, the XML type definition you added in 3.5.1.1 Add the types used by the endpoints (named "ExampleLBED") is registered in the application with the same name. You must make sure the name attribute of the register_type tag is the same as the name with which the type is registered in the application code.
3.5.1.3 Add the DomainParticipants’ topology
The generated application has two DomainParticipants: the ExampleLBEDParticipantPublisher and ExampleLBEDParticipantSubscriber. If you open the ExampleLBED_publisher.cxx program, you will see that ExampleLBEDParticipantPublisher has a single Publisher and a single DataWriter. The same happens for ExampleLBEDParticipantSubscriber: it has a Subscriber and a DataReader. Both endpoints use the "Example ExampleLBED" Topic and the ExampleLBED type.
The information above is what we call “topology,” and we need to represent it using DDS-XML. For that, use the domain_participant_library. Copy and paste the following XML snippet in your USER_QOS_PROFILES.xml file after the domain_library tag you added in the previous step:
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantPublisher"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<publisher name="Pub">
<data_writer name="DW" topic_ref="Example ExampleLBED"></data_writer>
</publisher>
</domain_participant>
<domain_participant name="ExampleLBEDParticipantSubscriber"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<subscriber name="Sub">
<data_reader name="DR" topic_ref="Example ExampleLBED"></data_reader>
</subscriber>
</domain_participant>
</domain_participant_library>
Regarding the snippet above:
- The name of the domain_participant_library is just an example. You can use any name you like.
- Make sure the name attributes of the domain_participant tags are the same as the names you specified for each DomainParticipant in 3.2 Add Name to Each DomainParticipant. This is the field that LBED uses to look for the DomainParticipants’ definition in the XML file.
- Make sure the domain_ref attribute of each DomainParticipant links to the correct domain tag added in 3.5.1.2 Add the Topics (that is, the domain that these participants use).
- Although LBED does not use the name attribute for Publishers, Subscribers, and endpoints, it is required by the DDS-XML standard, and Connext's internal XML parser imposes a restriction on the name attribute:
The name attribute must be unique within the same parent tag (e.g., two <data_writer> elements under the same <publisher> cannot have the same name attribute).
Note: If your application has two or more entities that are essentially the same (e.g., your Publisher has two or more identical DataWriters with the same QoS, Topic, and type) and you are using XML-Based Application Creation, then you don’t need to duplicate the information of the same entity several times in DDS-XML but with different names. You can use the multiplicity attribute instead to indicate how many entities use the same configuration (see the "Domain Participant Tag" table, in the "Participant Library" section, of the RTI Connext Core Libraries XML-Based Application Creation Getting Started Guide for more information about the multiplicity attribute, which applies to Publishers, Subscribers, and endpoints). If you are using LBED without XML-Based Application Creation, then you need to list each endpoint separately (with a different name attribute) and assign a different RTPS object ID to each one.
- Make sure the topic_ref attribute of each endpoint links to the correct Topic tag added in 3.5.1.2 Add the Topics (that is, the Topic these endpoints use in the application).
- If your endpoints use the implicit Publisher or Subscriber, then the publisher or subscriber tag is not required. The data_reader and data_writer tags can live directly under the domain_participant tag.
3.5.1.4 Add the required QoS profiles to the entities
In the DDS-XML definition from the previous step, no entity specifies which QoS profile it is using, so the default QoS profile (a profile marked as is_default_qos="true" or the default QoS values if there is none) will be assumed for all of them. However, if any of your entities use a QoS profile different than the default one and it contains information that LBED needs to know (see 4.3 Supported QoS for more information about which QoS policies LBED needs to be aware of), you must explicitly define the QoS profile that entity is using in the XML file.
For example, in this exercise, only the endpoints use a non-default QoS profile that specifies something LBED needs to know (the rtps_object_id), so we need to specify in DDS-XML which profiles the endpoints are using. You must make sure that the QoS profile you specify for a given entity is the same one that this entity uses when it is created in the application, because QoS policies are used for determining the matching between entities.
This is the same XML snippet from the previous section. See the QoS profiles in bold that you need to add:
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantPublisher"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<publisher name="Pub">
<data_writer name="DW" topic_ref="Example ExampleLBED">
<datawriter_qos
base_name="ExampleLBED_Library::ExampleLBED_Publisher_Profile"/>
</data_writer>
</publisher>
</domain_participant>
<domain_participant name="ExampleLBEDParticipantSubscriber"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<subscriber name="Sub">
<data_reader name="DR" topic_ref="Example ExampleLBED">
<datareader_qos
base_name="ExampleLBED_Library::ExampleLBED_Subscriber_Profile"/>
</data_reader>
</subscriber>
</domain_participant>
</domain_participant_library>
After following this tutorial, your XML file should look similar to the following. This file can also be found in <path to examples>/connext_dds/c++11/limited_bandwidth_plugins/lbediscovery/USER_QOS_PROFILES.xml.
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="file:///<NDDSHOME>/resource/schema/rti_dds_profiles.xsd">
<qos_library name="ExampleLBED_Library">
<!-- The QoS profile used by the publishing entities -->
<qos_profile name="ExampleLBED_Publisher_Profile">
<domain_participant_qos>
<discovery_config>
<builtin_discovery_plugins>DPSE</builtin_discovery_plugins>
</discovery_config>
<participant_name>
<name>ExampleLBEDParticipantPublisher</name>
</participant_name>
</domain_participant_qos>
<datawriter_qos>
<protocol>
<rtps_object_id>100</rtps_object_id>
</protocol>
</datawriter_qos>
</qos_profile>
<!-- The QoS profile used by the subscribing entities -->
<qos_profile name="ExampleLBED_Subscriber_Profile">
<domain_participant_qos>
<discovery_config>
<builtin_discovery_plugins>DPSE</builtin_discovery_plugins>
</discovery_config>
<participant_name>
<name>ExampleLBEDParticipantSubscriber</name>
</participant_name>
</domain_participant_qos>
<datareader_qos>
<protocol>
<rtps_object_id>200</rtps_object_id>
</protocol>
</datareader_qos>
</qos_profile>
</qos_library>
<types>
<struct name= "ExampleLBED">
<member name="data" type="int32"/>
</struct>
</types>
<domain_library name="ExampleLBED_Domain_Library">
<!-- IMPORTANT: change the domain_id value if you plan to use a
domain different than 0 -->
<domain name="ExampleLBED_Domain" domain_id="0">
<register_type name="ExampleLBED" type_ref="ExampleLBED"/>
<topic name="Example ExampleLBED" register_type_ref="ExampleLBED"/>
</domain>
</domain_library>
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantPublisher"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<publisher name="Pub">
<data_writer name="DW" topic_ref="Example ExampleLBED">
<datawriter_qos
base_name="ExampleLBED_Library::ExampleLBED_Publisher_Profile"/>
</data_writer>
</publisher>
</domain_participant>
<domain_participant name="ExampleLBEDParticipantSubscriber"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<subscriber name="Sub">
<data_reader name="DR" topic_ref="Example ExampleLBED">
<datareader_qos
base_name="ExampleLBED_Library::ExampleLBED_Subscriber_Profile"/>
</data_reader>
</subscriber>
</domain_participant>
</domain_participant_library>
</dds>
3.5.2 Using a Separate XML File
The config_file property (see Table 4.1 LBED Configuration Properties for Connext) can be used to specify a separate XML file (different from USER_QOS_PROFILES.xml) that exclusively contains the DDS-XML static definition of the endpoints that LBED requires. By following this approach, your USER_QOS_PROFILES.xml file will contain the local configuration and the separate XML file the remote one.
The structure and information of that XML file is the same as explained in 3.5.1 Using the USER_QOS_PROFILES.xml. It is highly recommended to read that section before continuing with the steps below. The only difference is that you don’t reuse the USER_QOS_PROFILES.xml file for LBED and you use a dedicated XML file instead.
In this exercise, we have chosen to create a separate XML file for each DomainParticipant (one for the Publisher and another for the Subscriber) but, if you prefer, you can create a single file that contains the LBED-required information for both.
The Publisher DomainParticipant will load the XML file with the information of the Subscriber DomainParticipant endpoints, and the Subscriber DomainParticipant will load the XML file with the information of the Publisher:
- Create two new XML files in the working directory. For example, you may want to name them LBEDPublisher.xml and LBEDSubscriber.xml. The first one will contain the information of the Publisher participant endpoints and, the second one, the information of the Subscriber.
- Modify the “ExampleLBED_Publisher_Profile” in USER_QOS_PROFILES.xml, adding the config_file property to the DomainParticipant QoS with the path to the LBEDSubscriber.xml file as value. Add it anywhere inside the <domain_participant_qos> tag.
- Modify the “ExampleLBED_Subscriber_Profile” in USER_QOS_PROFILES.xml, adding the config_file property to the DomainParticipant QoS with the path to the LBEDPublisher.xml file as value. Add it anywhere inside the <domain_participant_qos> tag.
- Start by creating the <dds> tag in both XML files (replace <NDDSHOME> with the actual path to your Connext installation directory):
- In LBEDPublisher.xml, create a qos_library and copy-paste "ExampleLBED_Publisher_Profile'' from USER_QOS_PROFILES.xml, since this is the profile that the entities of the Publisher participant use. Rename it, for example, to “ExampleLBED_Publisher_Profile_Static”. This is because your application will load both the USER_QOS_PROFILES.xml and LBEDPublisher.xml files, and there cannot be two profiles with the same name.
- Do the same for LBEDSubscriber.xml: create a qos_library and copy-paste the "ExampleLBED_Subscriber_Profile" from USER_QOS_PROFILES.xml. Rename it to "ExampleLBED_Subscriber_Profile_Static" and remove the non-required information:
- Since both Topics use the same type (ExampleLBED), copy and paste the ExampleLBED XML type definition (see 3.5.1.1 Add the types used by the endpoints) to both XML files.
- Since both endpoints use the same Topic (Example ExampleLBED), copy and paste the DDS-XML snippet from 3.5.1.2 Add the Topics (the contents of the <domain_library> tag) to both XML files. Don’t forget to modify the domain_id attribute if you plan to use another ID.
- Add a <domain_participant_library> and the Publisher DomainParticipant’s topology to LBEDPublisher.xml (see the XML snippet in 3.5.1.3 Add the DomainParticipants’ topology):
- Add a <domain_participant_library> and the Subscriber DomainParticipant’s topology to LBEDSubscriber.xml (see the XML snippet in 3.5.1.3 Add the DomainParticipants’ topology):
- Add the QoS profiles that the entities use, as explained in 3.5.1.4 Add the required QoS profiles to the entities, to both XML files. Keep in mind that you renamed the profiles (in step 5, above), so the specified base_name must match the new names.
<property>
<value>
<element>
<name>dds.discovery.endpoint.lbediscovery.config_file</name>
<value>LBEDSubscriber.xml</value>
</element>
</value>
</property>
<property>
<value>
<element>
<name>dds.discovery.endpoint.lbediscovery.config_file</name>
<value>LBEDPublisher.xml</value>
</element>
</value>
</property>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="file:///<NDDSHOME>/resource/schema/rti_dds_profiles.xsd">
</dds>
You can remove the <domain_participant_qos> element altogether, since the information it contains doesn’t need to be known by LBED (see 4.3 Supported QoS for more information about which QoS policies LBED needs to know). Your profile should look similar to the following:
<qos_library name="ExampleLBED_Library">
<qos_profile name="ExampleLBED_Publisher_Profile_Static">
<datawriter_qos>
<protocol>
<rtps_object_id>100</rtps_object_id>
</protocol>
</datawriter_qos>
</qos_profile>
</qos_library>
<qos_library name="ExampleLBED_Library">
<qos_profile name="ExampleLBED_Subscriber_Profile_Static">
<datareader_qos>
<protocol>
<rtps_object_id>200</rtps_object_id>
</protocol>
</datareader_qos>
</qos_profile>
</qos_library>
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantPublisher"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<publisher name="Pub">
<data_writer name="DW" topic_ref="Example ExampleLBED"></data_writer>
</publisher>
</domain_participant>
</domain_participant_library>
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantSubscriber"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<subscriber name="Sub">
<data_reader name="DR" topic_ref="Example ExampleLBED"></data_reader>
</subscriber>
</domain_participant>
</domain_participant_library>
This is the final LBEDPublisher.xml file (replace <NDDSHOME> with the actual path to your Connext installation directory):
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="file:///<NDDSHOME>/resource/schema/rti_dds_profiles.xsd">
<qos_library name="ExampleLBED_Library">
<qos_profile name="ExampleLBED_Publisher_Profile_Static">
<datawriter_qos>
<protocol>
<rtps_object_id>100</rtps_object_id>
</protocol>
</datawriter_qos>
</qos_profile>
</qos_library>
<types>
<struct name="ExampleLBED">
<member name="data" type="int32" />
</struct>
</types>
<domain_library name="ExampleLBED_Domain_Library">
<domain name="ExampleLBED_Domain" domain_id="0">
<register_type name="ExampleLBED" type_ref="ExampleLBED" />
<topic name="Example ExampleLBED" register_type_ref="ExampleLBED" />
</domain>
</domain_library>
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantPublisher"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<publisher name="Pub">
<data_writer name="DW" topic_ref="Example ExampleLBED">
<datawriter_qos
base_name="ExampleLBED_Library::ExampleLBED_Publisher_Profile_Static" />
</data_writer>
</publisher>
</domain_participant>
</domain_participant_library>
</dds>
This is the final LBEDSubscriber.xml file (replace <NDDSHOME> with the actual path to your Connext installation directory):
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="file:///<NDDSHOME>/resource/schema/rti_dds_profiles.xsd">
<qos_library name="ExampleLBED_Library">
<qos_profile name="ExampleLBED_Subscriber_Profile_Static">
<datareader_qos>
<protocol>
<rtps_object_id>200</rtps_object_id>
</protocol>
</datareader_qos>
</qos_profile>
</qos_library>
<types>
<struct name="ExampleLBED">
<member name="data" type="int32" />
</struct>
</types>
<domain_library name="ExampleLBED_Domain_Library">
<domain name="ExampleLBED_Domain" domain_id="0">
<register_type name="ExampleLBED" type_ref="ExampleLBED" />
<topic name="Example ExampleLBED" register_type_ref="ExampleLBED" />
</domain>
</domain_library>
<domain_participant_library name="ExampleLBED_DomainParticipant_Library">
<domain_participant name="ExampleLBEDParticipantSubscriber"
domain_ref="ExampleLBED_Domain_Library::ExampleLBED_Domain">
<subscriber name="Sub">
<data_reader name="DR" topic_ref="Example ExampleLBED">
<datareader_qos
base_name="ExampleLBED_Library::ExampleLBED_Subscriber_Profile_Static" />
</data_reader>
</subscriber>
</domain_participant>
</domain_participant_library>
</dds>