DomainParticipant ID PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Message/Author
Next message Will Castelnau  posted on Tuesday, January 29, 2008 - 05:54 am
Hi,

This may be a stupid question, but how can I correlate DCPSParticipant.key or DCPSPublication.partipant_key with a participant instance created with

participant = TheDomainParticipantFactory->create_participant(...);

I can't identify a way of correlating BuiltinTopicKey_t back on the participant itself with something like
participant.getID() or similar... I can find out about its domain ID, but no the participant ID itself...

Sorry again, I must be missing something quite simple....

Regards,
Will.
Next message Erik Hendriks  posted on Tuesday, January 29, 2008 - 02:50 pm
Hi Will,

The DDS spec does provide some mechanisms to navigate from Entity to builtintopic, but not vice-versa.

Every Entity has an operation called get_instance_handle, which returns the instance handle to the builtin topic sample that represents that instance. I can pass this handle directly to a read/take_instance operation on the builtin DataReader for the "DCPSParticipant" topic (accessable through the Builtin Subscriber) or, even simpler, I can pass the handle to the get_discovered_participant_data() operation of the DomainParticipant to directly obtain the builtin topic sample that represents it. From this sample I can then extract the key values from the field named "key".

Navigating the other way is much more difficult since the DDS spec provides no facilities for it. It is possible to obtain the instance handle for a given key field (use the lookup_instance operation on the builtin "DCPSParticipant" DataReader), but then I will have to compare this instance handle to the instance_handles of all the DomainParticipants in my application to see if they match, which is rather cumbersome.

Can you explain why you would want to navigate from a keyfield of a builtin topic to the actual DomainParticipant object that it represents? In most cases this kind of approach is used to solve a problem that can also be solved in a different way without resorting to builtin topics.

Regards,
Erik Hendriks.
Next message Will Castelnau  posted on Wednesday, January 30, 2008 - 12:58 am
Hi Erik,

Sure, I can provide some clarification on my use case:

Consider an app with multiple participants, spawning a number of publications/subscriptions. Before data exchange occurs, I would have liked to sync an initialisation block such that, for each local participant (given its ID???), I would ensure all expected DCPSParticipant.key and DCPSPublication.partipant_key are received to match my participant IDs I created earlier...

Hence my need to correlate keys to participant instances...

Is there a better way of doing this perhaps?

Regards,
Will.
Next message Hans van 't Hag  posted on Friday, February 08, 2008 - 02:17 pm
Hi Will,


I'm (still) a little confused w.r.t. what you're trying to accomplish. Is it related to some (proprietary/vendor-specific) 'features' of some DDS-vendors where applications have to provide system-wide unique ID's to participants required by their discovery implementation ?

In a fully compliant DDS implementation (such as PrismTech's OpenSplice DDS) there's no such requirement i.e. no need for applications to create unique participant ID's.

Thanks,
Hans
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: