결론 : 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.
