3.2.7. RTI Limited Bandwidth Endpoint Discovery Plugin

In Connext 7.0.0, the XML Schema Definition (XSD) of the XML file that LBED uses changed to meet the OMG’s DDS Consolidated XML Syntax (DDS-XML), a standard that determines how to represent and describe DDS entities and resources using XML. In addition, other changes were made to improve ease of use and LBED functionality. See the DDS-XML format for Limited Bandwidth Endpoint Discovery Plugin for further information about the improvements made.

An application using LBED in Connext 7.0.0 and later Connext 7 releases is able to communicate with an application using previous versions of the LBED plugin. To continue using a 6.1.2.x or earlier LBED application with Connext 7 releases, however, you will need to rewrite your existing LBED XML configuration files using the DDS-XML syntax. This document will guide you through the overall process. It explains the steps to follow for a single XML file. Repeat them for all LBED XML files in your system.

Note

Before continuing with the steps below, it is recommended that you look at the Limited Bandwidth Endpoint Discovery Plugin User’s Manual. Understanding the new configuration and schema of the plugin will help you modify your existing applications.

Use the following points to help you create a new LBED XML file (after reading the Limited Bandwidth Endpoint Discovery Plugin User’s Manual to get a basic understanding of the new configuration and schema).

  • Create a new XML file. Name it as you want, preferably with a name similar to the old file name.

  • For each of your endpoints that you specified in your old XML file, create a QoS profile in the new file containing the QoS policies you specified for it. While doing so, keep in mind the following:

    • The syntax between the old XSD and the DDS-XML XSD is different for certain QoS policies, such as the PROPERTY QosPolicy. Having XML validation while editing will help you detect and fix the inconsistencies. For that, it is enough to add the XSD to the <dds> tag as explained above. You can also check the documentation of the specific policy in All QoS Policies, in the RTI Connext Core Libraries User’s Manual.

    • In previous releases, you specified everything inside the <datareader_qos> and <datawriter_qos> tags for your endpoints. In DDS-XML, some QoS are not specified inside <datareader_qos> or <datawriter_qos> tags; some belong to <publisher>, <subscriber>, <participant>, or <topic> tags (for example, the PARTITION QoSPolicy is specified for Publishers and Subscribers). See Supported QoS, in the Limited Bandwidth Endpoint Discovery Plugin User’s Manual for more information on which QoSes LBED supports and to which Entities they apply.

    • If the endpoints in your old file share the same QoS (or part of them), reuse the same profile or use inheritance between profiles. (The old LBED XML could not make use of inheritance, but now that you are using DDS-XML, you can. See QoS Profile Inheritance and Composition, in the RTI Connext Core Libraries User’s Manual for more information.)

    • If a QoS policy in your old file was specified with the default value, you can remove it (although you don’t have to). Default values are assumed for policies not specified in the profile (unless the profile inherits from another one that specifies a non-default value for the policy).

  • The rtps_object_id is specified inside the DATA_WRITER_PROTOCOL QosPolicy and DATA_READER_PROTOCOL QosPolicy. In the old LBED file, the rtps_object_id was always mandatory. Now, if your application uses RTI Connext XML-Based Application Creation for creating local entities, you don’t need to specify an RTPS Object ID for each endpoint. (This is a new feature introduced in Connext 7.0.0.)

  • The <topic_keyed> tag does not exist in DDS-XML. To check whether the type being used by the endpoint is keyed or not, LBED in Connext 7 releases will look at the type definition. For user-defined types, you need to provide that definition to LBED. There are two alternatives:

    • Add the XML type definition of your type to the new XML file (recommended).

    • Let LBED automatically use the definition of the type with the same name that is registered in the local DomainParticipant. Using this approach may require changes in code.

    See Add the types used by the endpoints, in the Limited Bandwidth Endpoint Discovery Plugin User’s Manual for further information.

  • Specify the main structure of the DDS Entities in the new XML file. For that, DDS-XML uses a <domain_participant_library>. For example, note the structure of the following LBED 6.1.2 XML file:

    <LBEDiscoveryPluginProfile>
    <participant name="Publisher">
        <datawriter>
             ...
        </datawriter>
     </participant>
</LBEDiscoveryPluginProfile>

    In DDS-XML, the structure looks like this:

    <domain_participant_library name="...">
<domain_participant name="Publisher" domain_ref="...">
    <publisher name="...">
        <data_writer name="..." topic_ref="...">
        </data_writer>
    </publisher>
</domain_participant>
</domain_participant_library>

    See Add the DomainParticipants’ topology, in the Limited Bandwidth Endpoint Discovery Plugin User’s Manual for further information.

  • Finally, modify your XML QoS profile file (i.e., USER_QOS_PROFILES.xml) so the LBED config_file property points to the newly created file instead of the old one.

  • Note the following further considerations:

    • The <rtps_protocol_version> tag does not exist in DDS-XML. LBED will now automatically fill the RTPS Protocol Version using the value received in the participant announcements of the discovered DomainParticipants.

    • In DDS-XML, it is not possible to specify the locator’s IP address for the TRANSPORT_UNICAST QosPolicy. LBED will now automatically fill the unicast locators’ IP addresses using the default unicast locators’ addresses received in the participant announcements of the discovered DomainParticipants.