Get Info about participants losts

The Participant that is deleted can be identified by reading the ParticipantBuiltinTopic as you indicated.  You are right in that the participantData is empty at the time you get the notofication of it being deleted.  All the available information is in the DDS SampleInfo. Within the SampleInfo the remote Participant is uniquely identified by the instance_handle attibute.  So you will need to save the Participant Information when you discover it, put it in some sort of lookup table associated with the instance_handle, and then later lookup the information using the  instance_handle.

Gerardo

Gerardo:

What does DDSDomainParticipant::get_discovered_participant_data() return when passed the instance handle of a disconnected/deleted participant?   Using your suggestion of maintaining a table of instance handles it would seem that it is possible to use this get_ function to poll for active participants.  

I am interested in this as it seems likely that a deleted participant would be missed when using the on-liveliness-changed() interface given that the status provided by that interface contains the instance handle of the last changed participant - whether up or down.  Several status changes in a system over a short time span would result it missing a change - or is there a point I am missing here.

Thank you for any attention you can spare for this.

B. Paul Bockstege

Hello

I am just finding this thread which is discussion the same question(s) I have (posted) in http://community.rti.com/forum-topic/how-can-i-react-participant-going-stale, especially about the question of how to identify the participant that just went stale.

@ Gerardo: Do I read your comment correctly in that the GUID is not recoverable from any liveliness_changed/lost status and that only the participant instance_handle is available?

@ Paul: As you seem to have successfully found a way to react to a liveliness change of a participant, could you potentially have a look at my thread at http://community.rti.com/forum-topic/how-can-i-react-participant-going-stale and tell me where I am doing it wrong?

Thanks to both of you for any hints/comments/feedback.

Claus

Hello Claus,

To answer your question:

@ Gerardo: Do I read your comment correctly in that the GUID is not recoverable from any liveliness_changed/lost status and that only the participant instance_handle is available? 

As far as I know is indeed the case using the public APIs. However there is a way if you know the structure of InstanceHandle_t.

The only places where the Participant GUID appear as such are:

• the ParticipantBuiltinTopicData key attribute
• the PublicationBuiltinTopicData  participant_key attribute.
• the SubscriptionBuiltinTopicData  participant_key attribute.

By the time you get notified that the DomainParticipant has dissapeared these data-objects have been removed from the corresponding builtin DataReader, and all you have is their InstanceHandle_t 

That said, RTI's implementation of the InstanceHandle_t embeds the actual value of the GUID. So if you know how to interpret this reference you could get the GUID. The issue is that we hide the declaration of the InstanceHandle_t from the public header files so that applications do not depend on this as it is considered an implementation detail. This would be fine if we also offered a helper function like compute_guid_from_instance_handle(). But we don't as of today...

However if you really need this functionality you could use this hack:

 

struct GUID_t  {
       char guid[16];
};

void convert_buitin_topic_instance_handle_to_guid(struct GUID_t  *output,  struct InstanceHandle_t *input) 
{
        struct GUID_t *input_as_guid = (struct GUID_t *)input;
        *output = *input_as_guid;
}

In Java unfortunately it is trickier. But you can call the toString() operation on the InstanceHandle_t. This prints the bytes as separate integers. You could parse them and build the GUID from that. Gerardo