Userdata Qos usecase about cyclonedds HOT 8 CLOSED

The way to do that is to subscribe to the "DCPSParticipant" built-in topic. The support for the built-in topics is in a rather bad shape, but this particular topic is available. You can find an example of using it at

As to why it is in a bad shape and why that is relevant:

Firstly, only information on the participants is available. The specified built-in topics also cover readers, writers and topics, but these do not yet get generated. One could follow the same pattern as that used by the DCPSParticipant topic, and then they will work.

Secondly, there are still some issues with the relationship between the instance handles of the entity (as returned by dds_get_instance_handle) and the value you get in the sample info instance_handle field when reading the built-in topics.

Thirdly, while the format of the DCPSParticipant topic is entirely in line with the DDS specification, it is also thoroughly incompatible with this alternative API. In the DDS specification the representation of the QoS policies is consistent between the API and the built-in topics, but not today in Cyclone DDS because it doesn't follow the OMG-specified C API, as it is a completely disaster from a usability perspectiveI. (Cyclone DDS' API can do with a bit of refinement, but at least it is a lot better already.)

For example, in the specification, the reliability QoS is consistently represented using the ReliabilityQosPolicy type, with a ReliabilityQosPolicyKind. In Cyclone, there is a qos object with getters and setters, eliminating the policy type, and enumerated type for the kinds is dds_reliability_kind_t. Having the built-in topics use the OMG types and the rest of the API use something else is not nice ... Especially when you consider that the built-in topics allow doing things like writing a generic reader that subscribes to every topic for which there is a writer (like https://github.com/eboasson/opensplice-tools/blob/master/genreader.c does).

So the plan is to change the representation of the built-in topics to use the same QoS objects as the API. Those can't be represented in IDL, and hence the changes I did to abstract the sample representation. It should now be possible to have such topics in Cyclone.

So there will be a change in the representation of the DCPSParticipant topic in the near (should be near anyway) future. Once that change is in, instead of accessing the user data as sample->user_data.value._buffer you will then have to do something like dds_qget_userdata(sample->qos, &value, &length).

from cyclonedds.

Thank you so much for explanation!

from cyclonedds.

One more question. When I am debugging, I find that the function forward_builtin_participant doesn't work. Step into it until write_impl function, it shows that the builtin writers for both CMParticipantBuiltinTopicData and ParticipantBuiltinTopicData topics have no matched readers to send, which means the builtin writers don't match with the readers. Is there any plan to fix this problem?

from cyclonedds.

If you stepped through the first invocation of forward_builtin_participant, then there shouldn't be any readers yet. You can only create a reader once you have a participant, and so the first call to forward_builtin_participant necessarily occurs when there are none yet. This is not a problem because the data is transient-local, and hence it will be stored in the writer's history cache. When the reader (which should also be transient-local) is created it gets the data from there.

Does that answer your question?

from cyclonedds.

The participant discovery data of pub is sent Periodically, but I find the sub will just get the first participant discovery data of pub, I guess there is a checking about whether it is a new participant and then handle the data, can u tell me how u make this and where is the source code?

from cyclonedds.

You're right: pretty much the first thing it does when it receives an SPDP message is to check whether the participant is already known. It does that in handle_SPDP_alive, where it distinguishes four cases:

• a local participant (usually the multicasts are looped back, so you receive your own multicasts), in which case it ignores it; it is a local participant if ephash_lookup_participant_guid finds something;
• a known remote participant, in which case it renews the lease; this is if ephash_lookup_proxy_participant_guid finds something;
• a recently deleted participant (local or remote, so it can suppress rediscovery for some time), in which case it ignores it; this is checked by is_deleted_participant_guid
• an entirely unknown participant, in which case it creates a new proxy participant.

In case you wonder why there are these two lookups instead of a single one: there used to be separate hash tables for the different kinds of entities the DDSI stack deals with (participants, readers and writers for the local entities, and proxy participants, proxy readers and proxy writers for the remote entities), and so it used to be that ephash_lookup_participant_guid checked a different hash table than ephash_lookup_proxy_participant_guid. At some point I replaced the old implementation of those hash tables by a proper concurrent hash table implementation (an implementation of hopscotch hashing) and unified the 6 tables into a single one. The interface didn't get changed at that time.

Unifying them is possible because each entity has a unique GUID — the U stands for "unique", after all — and so the ability to store different kinds of entities under the same GUID was no longer useful once deliver_locally was added to deal with communication from a local writer to a local reader. Before that function got added, local communication would actually happen via the network, but that's way slower.

Note that communication via the network may be slower, but is also an clever hack that requires minimal effort to make such local communications work. Often there is but little communication between writers and readers from a single participant, and so it is not a bad hack per se. However, this particular DDSI stack is built to efficiently handle many participants in a single domain, and so is a very nice basis for running DDS-based microservices — and then local communication efficiency does become an issue.

from cyclonedds.

@raiars, I think this has been resolved.

What would perhaps be a good idea is to have a shortcut to getting the discovered remote entities and their QoS similar to the get_discovered_participants, get_matched_publication_data, &c., that exist in the DCPS specification. They don't add any functionality over reading from the built-in topics, but can be convenient to have (and are pretty trivial to implement). But that would deserve another issue.

from cyclonedds.

Presumed resolved

from cyclonedds.