Three major issues found for Cyclone. about cyclonedds HOT 5 CLOSED

Hi,

Thanks for trying and especially for asking: the situation is not as bad as it may seem at first (though there are certainly a number of issues that need fixing):

1. Domain id

Whenever you specify DDS_DOMAIN_DEFAULT, the domain id you get is whatever is specified as the value for the CycloneDDS/Domain/Id element in the configuration XML file. Without a configuration file, it defaults to 0. The CYCLONEDDS_URI environment variables specifies the configuration to use. It is a URI, but I'm pretty sure at the moment it only supports either plain file names or the file protocol — in other words, something like file:///home/baz/cyclonedds/etc/cyclonedds.xml. There is an example in etc/cyclonedds.xml.

It will also accept the domain id that is given by that configuration file. Without specifying a configuration file, it defaults the domain id to 0 and only accepts DDS_DOMAIN_DEFAULT and 0. If, for example, you have a configuration file specifying domain id 1, then DDS_DOMAIN_DEFAULT and 1 are allowed values for the domain id in dds_create_participant.

And yes, this is a bit bizarre and undesirable behaviour. (I know how it came to be this way, but I'll spare you the history …) Fortunately, it is pretty easy to fix. I'll see what I can do, but in the meantime, please try using a configuration file. Also note that the configuration file can use environment variable expansion, in case you want to be able to change it with relative ease.

2. Publisher, subscriber and topic Instance handles

You're right, these calls are not yet implemented. In my view, the bigger issue here is that built-in topics are not properly implemented yet (only DCPSParticipant, but even that's a bit problematic). The usefulness of the instance handles for these three entities is rather limited without having built-in topics. (I'm actually working on getting built-in topics fully supported — but that I am doing so is rather invisible at the moment …)

For the time being, perhaps you could make do with the dds_entity_t you get when you create them? Instance handles are also local to the domain participant, so you're not losing out on much if you do that.

3. Status conditions

These are actually supported, though it works slightly differently than how it is described in the OMG DDS specification. Cyclone simply has the status flags as part of the entity:

• dds_get_enabled_status, dds_set_enabled_status allow you to manipulate the set of enabled statuses (in the OMG specification, these are operations on the StatusCondition)
• dds_get_status_changes simply gives you the current set of status flags
• dds_read_status, dds_take_status allow you to read a subset of the flags; read leaves them unchanged and take resets them, analogous to the data reader read/take operations

in addition to that, the waitsets simply accept entities. So you can do, e.g.,

rd = dds_create_datareader(...);
dds_set_enabled_status(rd, DDS_DATA_AVAILABLE_STATUS);
ws = dds_create_waitset(...);
dds_waitset_attach(ws, rd, rd);

and then the waitset will be triggered whenever the DDS_DATA_AVAILABLE_STATUS is raised.

So it is basically the same as in the OMG specification, except that you do not need to first gain access to the StatusCondition 😊.

from cyclonedds.

Thank you so much for explanation!
One more question about ddsi source code. For participant struct in ddsi, I find it contains a pointer to a struct called nn_plist_t. This struct contains so many variables. However, when creating a new participant, only qos is set into the nn_plist. What is this nn_plist used for? Thanks!

from cyclonedds.

Good question: the nn_plist_t is basically the internal representation for all the parameter lists that DDSI uses in the standard default "simple" discovery protocol, but there can't be many settings used beside the QoS (in nn_xqos_t) in the local entities (not just the participant), though some are definitely relevant to proxy entities (addressing information, for example). Anyway, it is quite practical to have the ability to store anything related to discovery data in each entity, but there is also definitely something to be said in favour of a more compact representation. Only a few of the settings are relevant in the normal data path, so a more compact structure with slightly less efficient access to the individual fields would be an improvement.

P.S. One more thing about the domain id: it currently can handle only one domain at a time, currently you can't have a participant in domain A and a participant in domain B at the same time in a single process. This simply because it still stores the full configuration in global variables, which itself is a decision that goes back to the days of OpenSplice 5.x: and which is where this DDSI implementation was born. Fixing this is in principle straightforward, it is just a lot of boring work.

from cyclonedds.

Thanks! That helps a lot.

from cyclonedds.

Created #43 to cover the outstanding issue.

from cyclonedds.