본문 바로가기

Networking/DDS

Why is my VxWorks application unable to discover other RTI Data Distribution Service applications after a restart?

결론 : GUID를 재시작할때마다 Unique하게 만들자!!


Relevant versions: RTI Data Distribution Service 4.x


For dynamic discovery to work properly, RTI Data Distribution Service relies on a "globally unique identifier" (GUID) that uniquely identifies each instance of a participant in the network. By default, RTI Data Distribution Service will automatically choose values for the host ID and app ID that will generate unique GUIDs for different participant instances. This is documented in the WIRE_PROTOCOL QosPolicy (See [DomainParticipantQoS]).

Currently, RTI Data Distribution Service bases the host ID on the IPv4 address of the host (although this might change in the future). The app ID is calculated from the process (or task) ID and a counter that is incremented per new participant created in the process.

Note that the app ID is not based upon the participant index. When restarting an application with the same participant index, the application should announce itself as a new participant (with a different GUID) on the network, so other participants can respond with their configuration info. Therefore, RTI Data Distribution Service will assign it a different app ID, even if the participant uses the same participant index (and ports). After all, it is a different instance of this participant. If the app ID were unchanged, remote participants would simply interpret the announcement as an "I am still alive" message and not reply with their own information.

On many real-time operating systems, and even on some non-real-time operating system, when a node is rebooted, and applications are automatically started, process ids are deterministically assigned. That is, when the system restarts or if an application dies and is restarted, the application will be reassigned the same process or task ID. If this occurs before other applications in the system can detect that the previous application has died, the new application will appear to be the same as the previous application due to their identical GUIDs.

In such cases, to prevent duplicate GUIDs, you can set the host ID and/or app ID manually using the WIRE_PROTOCOL QosPolicy before creating the participant.

In publisher_main):

struct DDS_DomainParticipantQos participant_qos;

...

// Initialize participant_qos with default values

DDS_DomainParticipantFactory_get_default_participant_qos(

 

               DDS_TheParticipantFactory,

               &participant_qos);

 

// set the rtps host and/or app id.

participant_qos.wire_protocol.rtps_host_id = aRandomOrIncrementingValue;

participant_qos.wire_protocol.rtps_app_id = aRandomOrIncrementingValue;

 

// Create participant using modified DDS_DomainParticipantQos

participant = DDS_DomainParticipantFactory_create_participant(

 

      DDS_TheParticipantFactory, domainId, &participant_qos,

      NULL /* listener */, DDS_STATUS_MASK_NONE);

 

When the application is restarted, RTI DDS assigns it a different host and app ID -- in which case the GUID becomes unique and other applications will recognize this as a new instance of an application and will exchange discovery information.

 

Displaying the GUID

One can observe the GUID using RTI Protocol Analyzer with Wireshark or by turning on high verbosity output level for both the subscriber and publisher.

 

Set the NDDS_Config_LogCategory to NDDS_CONFIG_LOG_CATEGORY_ENTITIES to log messages pertaining to local and remote entities and to the discovery process.

 

NDDS_Config_Logger_set_verbosity_by_category(        NDDS_Config_Logger_get_instance(), NDDS_CONFIG_LOG_CATEGORY_ENTITIES,       NDDS_CONFIG_LOG_VERBOSITY_STATUS_ALL);

 

Look for the following line in output from both subscriber and publisher applications:

DISCDynamicParticipantSelfAnnouncer_enable:announcing participant: 0x7F000001,0x00100001,0x000001C1

 

The GUID is composed of three parts:

1. host ID: identifies the host on which the participant is running

2. app ID: uniquely identifies a particular instance of a participant on this host

3. object ID: has a fixed value in the case of a participant. Will be used to uniquely identify entities (pubs, subs) that belong to the participant.