OpenDDS icon indicating copy to clipboard operation
OpenDDS copied to clipboard

Behavior of create_topic with calling it multiple times with the same topic_name

Open jwillemsen opened this issue 4 years ago • 5 comments

We think the create_topic should fail when it is called multiple times with the same topic_name. The spec is not concrete at it, I see that for example RTI Connext DDS doesn't allow this (see https://community.rti.com/rti-doc/500/ndds.5.0.0/doc/html/api_cpp/classDDSDomainParticipant.html#a7f249829f7ee94d1461d371800398a21), did report an issue on the DDS spec for this

jwillemsen avatar Nov 16 '20 17:11 jwillemsen

I don't see a reason to do this. The spec doesn't require it, so completely valid user code would start to break.

mitza-oci avatar Nov 23 '20 16:11 mitza-oci

I opened an issue on the DDS spec for clarification, some other DDS vendors disallow this, see https://issues.omg.org/issues/DDS15-317

jwillemsen avatar Nov 23 '20 17:11 jwillemsen

XTypes actually explicitly says topics can have the same name in 1.3 7.6.4.1. I'm not sure we're following it exactly though because it also says the QoS must consistent.

iguessthislldo avatar Dec 22 '22 22:12 iguessthislldo

Some assorted thoughts I had while revisiting this:

Since I created a way to link to the spec sections, I might as well use them. The relevant XTypes section I mentioned before is here. It is odd that it says there's a restriction in the spec while there's not as Johnny already mentioned. It does say in DDS 2.2.1.2.1 that:

A Topic is meant to fulfill that purpose: it associates a name (unique in the domain), a data-type, and QoS related to the data itself.

Maybe that's what XTypes is talking about, but if that's the case it should mention what create_topic does in that case.

Back to the XTypes spec behavior though, since that's what we should be following since it supersedes the DDS spec behavior. The important part is:

The Service may instantiate multiple objects of the same name, provided that all of them represent type-based subsets of “the same” network topic; therefore, they must have consistent QoS with one another.

I'm trying to figure out exactly what it means by this. Right now we are just checking if the QoS is equal, not "consistent", which I'm assuming isn't what the specs consider "consistent" Topic QoS to be.

https://github.com/OpenDDS/OpenDDS/blob/62ad206a8eb81313e0b630d21f186e8f6ce11007/dds/DCPS/DomainParticipantImpl.cpp#L504-L541

Then what does the XTypes spec mean by "type-based subsets"? Are we still making sure the registered topic type name is the same, maybe doing a type consistency check, or just ignoring the type all together?

Another thing I wanted to note is that we're returning the same object, where as the XTypes spec assumes we're creating multiple objects. Does any other create_* call have this sort of behavior?

I see that for example RTI Connext DDS doesn't allow this (see https://community.rti.com/rti-doc/500/ndds.5.0.0/doc/html/api_cpp/classDDSDomainParticipant.html#a7f249829f7ee94d1461d371800398a21), did report an issue on the DDS spec for this

That link is from 2012, the year of the first XTypes spec was published. Does Connext DDS still have that behavior?

iguessthislldo avatar May 02 '24 22:05 iguessthislldo

RTI still has the same behavior in 7.3.0 which was released April 2024, see https://community.rti.com/static/documentation/connext-dds/7.3.0/doc/api/connext_dds/api_cpp/classDDSDomainParticipant.html#a429c2e4de82957e2ea01dd6d16560e2f

jwillemsen avatar May 03 '24 06:05 jwillemsen