Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Open Issues

  • Acronym: DDS
  • Issues Count: 55
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-50 Add name attribute to Entity DDS 1.2 open
DDS15-28 DDS Entities should have a name DDS 1.2 open
DDS15-13 DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038 DDS 1.2 open
DDS15-153 Definition of BuiltinTopicKey_t DDS 1.2 open
DDS15-183 Clarification of resource management DDS 1.2 open
DDS15-182 Clarification of create_multitopic behavior DDS 1.2 open
DDS15-181 Typo on description of class TopicDescription DDS 1.2 open
DDS15-179 Clarify behavior of register_type operation DDS 1.2 open
DDS15-176 Typo on descripton of "read" operation DDS 1.2 open
DDS15-175 Clarify behavior of "take" operation DDS 1.2 open
DDS15-173 Typo in description of "persistence" service reponsibility DDS 1.2 open
DDS15-172 Typo in Section: 2.1.3.14 DDS 1.2 open
DDS15-178 Clarification of instance_state -- Section: 2.1.2.5.1.3 DDS 1.2 open
DDS15-180 Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2 DDS 1.2 open
DDS15-30 [DDS] Data types permissible as topic key fields DDS 1.2 open
DDS15-188 DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS DDS 1.2 open
DDS15-171 Force KEEP_ALL to be RELIABLE Section: 2.1.3.18 DDS 1.2 open
DDS15-33 Deprecated usage of IDL in the DDS spec DDS 1.2 open
DDS15-45 Cancel coherent update DDS 1.2 open
DDS15-16 Introduce new typedef DDS 1.2 open
DDS15-14 : #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; DDS 1.2 open
DDS15-37 DDS typos and omissions DDS 1.2 open
DDS15-44 Get entity enabled state DDS 1.2 open
DDS15-49 Semantics instance liveliness and ownership unclear DDS 1.2 open
DDS15-184 create_contentfilteredtopic Method Prototype and Description Out DDS 1.2 open
DDS15-2 ContentFilteredTopics should be removed. Filtering belongs to DataReaders DDS 1.2 open
DDS15-22 Allow for more optimized list returned by get_datareaders() DDS 1.2 open
DDS15-3 Write with handle_nil underspecified DDS 1.2 open
DDS15-9 DDS specification should be more precise on NATIVE defines DDS 1.2 open
DDS15-10 Add DDS::STATUS_MASK_NONE DDS 1.2 open
DDS15-15 For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec DDS 1.2 open
DDS15-43 DDS DCPS Issue: PRESENTATION=GROUP and QoS DDS 1.2 open
DDS15-51 Invalid DURABILITY_SERVICE reference on the DataWriter DDS 1.2 open
DDS15-177 Section: 2.1.2.5.3 DDS 1.2 open
DDS15-1 TypeSupport::get_type_name should be precisely specified DDS 1.2 open
DDS15-5 InstanceHandle_t/Domain ID DDS 1.2 open
DDS15-34 'synchrobnous' and 'asynchronous' switched DDS 1.2 open
DDS15-36 DURABILITYSERVICE_POLICY_NAME DDS 1.2 open
DDS15-174 Section: 2.1.3 DDS 1.2 open
DDS15-4 Spec lacks definition regarding uniqueness of InstanceHandle_t DDS 1.2 open
DDS15-6 get_type_name, class or object method DDS 1.2 open
DDS15-27 behaviour of redefining multiple times the same topic with different QoS not clearly specified DDS 1.2 open
DDS15-52 DataReader semantics for historical data are insufficient DDS 1.2 open
DDS15-8 DDS should require to annotate IDL to indicate which IDL types are used for dds DDS 1.2 open
DDS15-12 Add new mask which will let DDS callback on the listener to gets its mask DDS 1.2 open
DDS15-46 Default built-in ReaderDataLifecycle values DDS 1.2 open
DDS15-47 Inconsistent lookup semantics DDS 1.2 open
DDS15-7 Add several with_profile methods DDS 1.2 open
DDS15-11 Extend Topic with method to retrieve key fields DDS 1.2 open
DDS15-23 When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block DDS 1.2 open
DDS15-24 The compatibility rules for the Presentation QoS are too strict DDS 1.2 open
DDS15-31 Mapping of OMG IDL to C++ for DDS DDS 1.2 open
DDS15-35 Specify the allowed IDL Types within DDS Topic structs DDS 1.2 open
DDS15-48 Missing TypeSupport operations DDS 1.2 open
DDS11-15 DDS should use typed modules DDS 1.2 open

Issues Descriptions

Add name attribute to Entity

  • Key: DDS15-50
  • Legacy Issue Number: 10807
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    For system management it is very useful that Entities can be identified by a logical application defined name. This attribute should ideal be set via the factory create call but if changing API's is not desired it can also be set via a QoS policy. This attribute should also be supported by the built-in Topics

    Solution:
    Introduction of a new Properties QoS that can be used for a name, but also for other things. The new QoS would contain a sequence of "properties" where each property is a pair of strings:
    (property_name, property_value)
    This Properties QoS can be used very much the same as the USER_DATA, but because each property is named, multiple things can be stored without conflicting with each other. This also provides an extensibility mechanism for the DDS spec. We can reserve the property-names with the prefix "DDS." To indicate "built-in" properties that should not be used by applications.
    We can use this mechanism with the built-in property name "DDS.EntityName" to implement the name attribute.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Wed, 17 Jan 2018 02:48 GMT

DDS Entities should have a name

  • Key: DDS15-28
  • Legacy Issue Number: 16029
  • Status: open  
  • Source: ADLINK ( Angelo Corsaro)
  • Summary:

    DDS Entities (DomainParticipant, Publisher, Subscriber, DataReader and DataWriter) have associated GUID but the current API does not provide any way of associating them a symbolic name, such as "com.acme.mycoolapp.DomainParticipantFoo"

    The DDS PIM should be extended to support the explicit setting of entity names. When not set explicitly, vendors should be free to pick meaningful names.

  • Reported: DDS 1.2 — Wed, 16 Feb 2011 05:00 GMT
  • Updated: Wed, 17 Jan 2018 02:48 GMT

DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038

  • Key: DDS15-13
  • Legacy Issue Number: 14166
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS defines Time_t with seconds as long, this is 32bit. This will give an issue after 2038, almost all operating systems are now defining time as 64bit, shouldn't DDS do the same?

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Fri, 15 Dec 2017 22:14 GMT

Definition of BuiltinTopicKey_t

  • Key: DDS15-153
  • Legacy Issue Number: 10581
  • Status: open  
  • Source: MilSOFT ( Ertan Deniz)
  • Summary:

    The PSM mapping of BuiltinTopicKey_t is defined to be as:

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3]; 
    }; 
    

    But the DDS Interoperability Wire Protocol (RTPS) specifies that GUID consists of 12 bytes GuidPrefix and 4 bytes EntityId.

    In order to map GUID and BuiltinTopicKey, we should define BuiltinTopicKey as either

    typedef octet BuiltinTopicKey[16];
    

    or else if we really wanted to preserve the definition as an array of longs

    struct BuiltinTopicKey_t { 
        BUILTIN_TOPIC_KEY_TYPE_NATIVE value[4]; 
    }; 
    

    But the latter could cause problems due to different endianess unless we also specified how to place the octets that arrive at the protocol level into the array of long.

  • Reported: DDS 1.2 — Tue, 9 Jan 2007 05:00 GMT
  • Updated: Tue, 24 May 2016 00:30 GMT

Clarification of resource management

  • Key: DDS15-183
  • Legacy Issue Number: 10357
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    I don't think that it is explicitly stated anywhere in this spec that each DataWriter and each DataReader maintains its own set of samples. Samples are not maintained by Publishers, Subscribers. It is implied in several places, e.g. the fact that RESOURCE_LIMITS applies to DataWriter and DataReader and not to Publisher and Subscriber. It took me a while to figure this out. It is possible for a Publisher to have more than one DataWriter with the same topic, and a Subscriber to have more than one DataReader with the same topic. The semantics of DataReader.take, for instance, are unclear unless it is understood that each DataReader has its own samples. Evidently a take operation on one DataReader does not disturb the samples of another DataReader with the same Publisher and Topic. Please clarify the specification in this regard. Figure 2-1 and accompanying text would be one place.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 21:50 GMT

Clarification of create_multitopic behavior

  • Key: DDS15-182
  • Legacy Issue Number: 10358
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The resulting type is specified by the type_name argument." What happens if the specified type is inconsistent with the subscription_expression?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 21:49 GMT

Typo on description of class TopicDescription

  • Key: DDS15-181
  • Legacy Issue Number: 10359
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    The class description for TopicDescription says "no attributes" but in fact two attributes are listed immediately below.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:43 GMT

Clarify behavior of register_type operation

  • Key: DDS15-179
  • Legacy Issue Number: 10361
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The application may pass nil as the value for the type_name. In this case the default typename as defined by the TypeSupport (i.e., the value returned by the get_type_name operation) will be used." What happens if register_type is given a type_name that differs from the result of get_type_name?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:42 GMT

Typo on descripton of "read" operation

  • Key: DDS15-176
  • Legacy Issue Number: 10364
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The use of this variant allows for zero-copy access to the data and the application will need to “return the loan” to the DataWriter using the return_loan operation (see Section 2.1.2.5.3.20 )." Should be DataReader?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:41 GMT

Clarify behavior of "take" operation

  • Key: DDS15-175
  • Legacy Issue Number: 10365
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The act of taking a sample removes it from the DataReader so it cannot be ‘read’ or ‘taken’ again." See my earlier comment. Apparently if there are other DataReaders for the same Topic and the same Subscriber, their samples are not disturbed. Assuming this is true, it should be stated.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:40 GMT

Typo in description of "persistence" service reponsibility

  • Key: DDS15-173
  • Legacy Issue Number: 10367
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "The “persistence service” is the one responsible for implementing the DURABILITY kinds TRANSIENT and PERSISTENCE." You mean PERSISTENT

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 17 May 2016 18:37 GMT

Typo in Section: 2.1.3.14

  • Key: DDS15-172
  • Legacy Issue Number: 10368
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "In other words, the DataReader may miss some datasamples but it will never see the value of a data-object change from a newer value to an order value." You mean "older".

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:38 GMT

Clarification of instance_state -- Section: 2.1.2.5.1.3

  • Key: DDS15-178
  • Legacy Issue Number: 10362
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "For each instance the middleware internally maintains an instance_state." Obviously this instance_state could be different for different DomainParticipants. Might it be different for two Subscribers of the same DomainParticipant? How about two DataReaders of the same Subscriber?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:37 GMT

Behavior of multiple calls to create_topic -- Section: 2.1.2.3.2

  • Key: DDS15-180
  • Legacy Issue Number: 10360
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "A Topic is identified by its name, which must be unique in the whole Domain." There is nothing in the description of create_topic that indicates that this constraint is enforced. Is it possible for multiple domain_participants to execute create_topic with the same name? What happens if they specify different types?

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Sat, 2 Apr 2016 20:36 GMT

[DDS] Data types permissible as topic key fields

  • Key: DDS15-30
  • Legacy Issue Number: 14089
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The DDS 1.2 standard does not mention which IDL data types are permissible as
    key fields for topic data types.

    As the data types for keys, at least enumeration types and integral types
    (octet/short/long etc.) should be permissible.
    However, it would be desirable to also allow simple (non-array) typedefs
    of these types.

  • Reported: DDS 1.2 — Wed, 22 Jul 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 16:05 GMT

DATAWRITER_QOS_USE_TOPIC_QOS and DATAREADER_QOS_USE_TOPIC_QOS

  • Key: DDS15-188
  • Legacy Issue Number: 19651
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 7.2.3 the defines DATAWRITER_QOS_USE_TOPIC_QOS
    and DATAREADER_QOS_USE_TOPIC_QOS do exist but they are not mentioned anywhere in the spec. Not sure if they should be removed, or documented

  • Reported: DDS 1.2 — Fri, 31 Oct 2014 04:00 GMT
  • Updated: Tue, 15 Mar 2016 15:02 GMT

Force KEEP_ALL to be RELIABLE Section: 2.1.3.18

  • Key: DDS15-171
  • Legacy Issue Number: 10369
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "If the kind is set to KEEP_ALL, then the Service will attempt to maintain and deliver all the values of the instance to existing subscribers. The resources that the Service can use to keep this history are limited by the settings of the RESOURCE_LIMITS QoS. If the limit is reached, then the behavior of the Service will depend on the RELIABILITY QoS. If the reliability kind is BEST_EFFORT, then the old values will be discarded." This violates the ordinary English meaning of KEEP_ALL. Can't the same effect be achieved by specifying KEEP_LAST with history_depth=max_samples_per_instance? If so, then KEEP_ALL should not be allowed for RELIABILITY=BEST_EFFORT.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Tue, 15 Mar 2016 14:41 GMT

Deprecated usage of IDL in the DDS spec

  • Key: DDS15-33
  • Legacy Issue Number: 12539
  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The CORBA specification (08-01-04) in section 7.11.6 deprecates the use of anonymous types, for example the type of the struct field "seq" below:
    struct Foo

    { sequence<octet> seq; }

    ;

    The DDS DCPS IDL uses these in multiple places (the first is DDS::UserDataQosPolicy). These should be replaced with non-deprecated usage such as:
    typedef sequence<octet> OctetSeq;
    struct Foo

    { OctetSeq seq; }

    ;

    This will also increase internal consistency of the DDS spec, since it already uses a DDS::StringSeq typedef in the PartitionQosPolicy struct.

    Furthermore, if the element type of the sequence is a Basic Type or a String Type, the CORBA module already provides these typedefs, so it would be preferable to use them. The example above becomes:
    struct Foo

    { CORBA::OctetSeq seq; }

    ;

  • Reported: DDS 1.2 — Fri, 20 Jun 2008 04:00 GMT
  • Updated: Tue, 15 Mar 2016 14:24 GMT

Cancel coherent update

  • Key: DDS15-45
  • Legacy Issue Number: 10812
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It is possible that a transaction needs to be canceled, for example because one of the participating writers gets blocked and finally stops while returning a timeout. This might lead to the situation in which you want to cancel all preceding writes as well.

    Solution:
    To be able to cancel such a transaction, we propose to add an additional operation like e.g. cancel_coherent_changes would then remove all samples that have already been written since the last begin_coherent_changes.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Tue, 15 Mar 2016 14:23 GMT

Introduce new typedef

  • Key: DDS15-16
  • Legacy Issue Number: 13950
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    UserDataQosPolicy, TopicDataQosPolicy, and GroupDataQosPolicy use an anonymous sequence, this is deprecated in IDL. A new typedef for this should be introduced

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 13:34 GMT

: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t;

  • Key: DDS15-14
  • Legacy Issue Number: 14165
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS spec defines: #define HANDLE_TYPE_NATIVE long typedef HANDLE_TYPE_NATIVE InstanceHandle_t; We see that some vendors use long, other a struct containing an octet array. This is causing problems when integrating DDS into CCM. A CORBA::Long is passed by value, a struct is passed as const &. At least the way the InstanceHandle_t is passed to methods and returned should be the same. We propose to change this type to: struct NativeInstanceHandle_t

    { // Vendor defined }

    ; typedef NativeInstanceHandle_t InstanceHandle_t; That way we always have a struct passed as const&.

  • Reported: DDS 1.2 — Thu, 30 Jul 2009 04:00 GMT
  • Updated: Tue, 15 Mar 2016 13:30 GMT

DDS typos and omissions

  • Key: DDS15-37
  • Legacy Issue Number: 12212
  • Status: open  
  • Source: Anonymous
  • Summary:

    1. Section 7.1.4.4 Conditions and Wait-sets - Two paragraphs above figure 7.19 is "The blocking behavior of the WaitSet is illustrated in Figure 7.18" I think this is meant to reference figure 7.19 instead.

    2. Section 7.1.6.2.2 Notifications via Conditions and Wait-Sets - starts out with "The first part of Figure 7.21" I think it should be figure 7.22

    3. In section 7.2.3 DCPS PSM : IDL on pages 152 - 153 are definitions of all the IDs and names of the QOS Policies with the exception that "TRANSPORTPRIORITY" has an ID definition but is missing a name definition. 4. Section 7.1.2.2.2.7 set_qos
    This operation sets the value of the DomainParticipantFactory QoS policies. These policies control the behavior of the
    object a factory for entities.

  • Reported: DDS 1.2 — Mon, 4 Feb 2008 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Get entity enabled state

  • Key: DDS15-44
  • Legacy Issue Number: 10813
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    It should be possible to obtain the "enabled" state of an Entity

    Solution:
    We propose to add a boolean operation to the Entity called something like is_enabled().

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Semantics instance liveliness and ownership unclear

  • Key: DDS15-49
  • Legacy Issue Number: 10808
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    From the OMG DDS specification the semantic of the liveliness of a reader instance is not clear, when it is exclusively owned by a writer. The LivelinessChangedStatus of the reader indicates how many active and inactive writers communicate with the reader. In case of exclusive ownership it is unclear whether only the reader sees the strongest writer as an active writer, or when it must see all available writers, since the reader will only receive samples from the strongest writer.

    Solution:
    Do we need to clarify this?

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

create_contentfilteredtopic Method Prototype and Description Out

  • Key: DDS15-184
  • Legacy Issue Number: 9964
  • Status: open  
  • Source: Anonymous
  • Summary:

    I was looking at the DDS specification and saw that the name of the first parameter for DomainParticipant's create_contentfilteredtopic method is "name" in the table of methods (section 2.1.2.2.1) and it is "topic_name" in the method description (section 2.1.2.2.1.7). I assume the name should be consistent.

  • Reported: DDS 1.2 — Tue, 25 Jul 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

ContentFilteredTopics should be removed. Filtering belongs to DataReaders

  • Key: DDS15-2
  • Legacy Issue Number: 18311
  • Status: open  
  • Source: ADLINK ( Angelo Corsaro)
  • Summary:

    The DDS v2.1 introduces the concept of a ContentFilteredTopic in order to express filtering on a DataReder. The ContentFilteredTopic is a local entity that is not distributed via discovery. In addition content filters are already distributed as part of DataReader discovery.

    As such it would be cleaner and more sensible to remove the ContentFilteredTopic and allow to express the filter directly through either DataReader QoS or as a Filter parameter (see DDS-PSM-Cxx for inspiration).

  • Reported: DDS 1.2 — Wed, 12 Dec 2012 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Allow for more optimized list returned by get_datareaders()

  • Key: DDS15-22
  • Legacy Issue Number: 17364
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Found by: Fernando Crespo
    Severity:

    Problem:
    OMG DDS spec (section 7.1.2.5.2.10) states that the sequence returned by
    get_datareaders() will contain list containing each DataReader one or more times.
    For example, if multiple consecutive samples in a group belong to the same DataReader
    the DataReader is repeated in the list returned by get_datareaders().
    Having to process each element, even when they belong to the same DataReader is
    less performant.

    Proposed Resolution:
    Modify the specification to return one DataReader element, instead of a list where
    a DataReader is repeated multiple times, when multiple subsequent samples belong to
    the same DataReader. This allows for more optimized processing where the user calls
    read/take until the return code is NO_DATA.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Write with handle_nil underspecified

  • Key: DDS15-3
  • Legacy Issue Number: 17413
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For write the DDS spec says:

    The special value HANDLE_NIL can be used for the parameter handle. This indicates that the identity of the instance
    should be automatically deduced from the instance_data (by means of the key).

    The case which is not specified is the case where the handle is HANDLE_NUL, but they key we use hasn't been registered with dds yet, will DDS than return an error, or automatically register a new instance?

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS specification should be more precise on NATIVE defines

  • Key: DDS15-9
  • Legacy Issue Number: 15834
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS leaves domainid, handle, and topic key to the dds vendor, each can define their own type for these. The specification has defines for them, but the default is long. If now a vendor uses for example a struct for the InstanceHandle_t, this leads to challenges when writing portable C++ code because the argument passing is different between a long (as value) or a fixed struct (const &). To my idea the dds specification should be more precise on the type, maybe fixed struct to achieve more portability of users code

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add DDS::STATUS_MASK_NONE

  • Key: DDS15-10
  • Legacy Issue Number: 15041
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We want to propose to extend the DDS status masks with DDS::STATUS_MASK_NONE which is defined as 0. This is cleaner for application code.

  • Reported: DDS 1.2 — Mon, 8 Feb 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec

  • Key: DDS15-15
  • Legacy Issue Number: 13951
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For ContentFilteredTopic::get_expression_parameters the argument name is not given in the spec, this way the IDL isn't complete and compilable Also MultiTopic::get_expression_parameters has the same issue Also DataWriter::get_liveliness_lost_status has this issue

  • Reported: DDS 1.2 — Mon, 8 Jun 2009 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS DCPS Issue: PRESENTATION=GROUP and QoS

  • Key: DDS15-43
  • Legacy Issue Number: 10993
  • Status: open  
  • Source: OCI ( Don Busch)
  • Summary:

    Section 7.l.3.6 of the DCPS spec should indicate what happens under the PRESENTATION=GROUP policy when different DataWriters in the group have different QoS settings. Whose settings are followed by the group? The most stringent? The least stringent? Group membership is dynamic, so the group members are not knows until each write() happens

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Invalid DURABILITY_SERVICE reference on the DataWriter

  • Key: DDS15-51
  • Legacy Issue Number: 10806
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In the QoS table (Section 2.1.3 Supported QoS) the 'concern' row illegally specifies the DataWriter for the DURABILITY_SERVICE QoS.

    Solution:
    Section 2.1.3 Supported QoS, QoS Table:
    Entry for DURABILITY_SERVICE QoS, remove the word 'DataWriter' from the 'Concerns' column.
    If we do this it would need to be removed from the BuiltinPublicationData.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Section: 2.1.2.5.3

  • Key: DDS15-177
  • Legacy Issue Number: 10363
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: DataReader.read operation Why are sample_states, view_states, and instance_states provided as separate parameters? Aren't they contained in sample_infos? More explanation required.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

TypeSupport::get_type_name should be precisely specified

  • Key: DDS15-1
  • Legacy Issue Number: 18468
  • Status: open  
  • Source: ADLINK ( Angelo Corsaro)
  • Summary:

    The description of the TypeSupport::get_type_name operation currently states:

    "This operation returns the default name for the data-type represented by the TypeSupport."

    The problem is that the default name for the data-type is not specified anywhere. One logical choice would be the fully qualified type as per the IDL syntax. As an example org::omg::dds::demo::ShapeType.

    If the specification does not clearly mandate the representation for the topic type interoperability may be hindered unless users explicitly override topic types.

    This is very unfortunate and a critical issue that should be addressed ASAP.

  • Reported: DDS 1.2 — Thu, 21 Feb 2013 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

InstanceHandle_t/Domain ID

  • Key: DDS15-5
  • Legacy Issue Number: 16266
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    InstanceHandle_t is underspecified, The IDL PSM that should use a struct, so that argument passing is the same for all values

    In the IDL PSM, I see that copying and comparing instance handles is underspecified.

    The same issue applies to domain IDs, actually, which also have unspecified contents in that PSM.)

  • Reported: DDS 1.2 — Thu, 26 May 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

'synchrobnous' and 'asynchronous' switched

  • Key: DDS15-34
  • Legacy Issue Number: 12465
  • Status: open  
  • Source: Anonymous
  • Summary:

    While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchrobnous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

    <para #4, page 11>
    On the subscriber’s side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access.

  • Reported: DDS 1.2 — Wed, 14 May 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DURABILITYSERVICE_POLICY_NAME

  • Key: DDS15-36
  • Legacy Issue Number: 12276
  • Status: open  
  • Source: lmco.com ( Abdullah Sowayan)
  • Summary:

    noticed an inconsistency while I was reading the DDS spec (version
    1.2) last night. My question relates to the following quality of
    service policy:
    DURABILITYSERVICE_POLICY_NAME

    The pattern in all QoS names is:

    *_QOS_POLICY_NAME, except for the DURABILITYSERVICE

    The pattern in all QoS IDs is:

    *_QOS_POLICY_ID

    The DURABILITYSERVICE does adhere to the pattern/convention for Qos IDs:

    DURABILITYSERVICE_QOS_POLICY_ID

    But the does NOT adhere to the pattern/convention for Qos names. So, is
    there a typo in DURABILITYSERVICE_POLICY_NAME, i.e., should it be
    DURABILITYSERVICE_QOS_POLICY_NAME, or is the lacking of QOS
    intentional?

  • Reported: DDS 1.2 — Thu, 13 Mar 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Section: 2.1.3

  • Key: DDS15-174
  • Legacy Issue Number: 10366
  • Status: open  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "And three integers: history_depth, max_samples, max_instances, max_samples_ per_instance" There are four integers here.

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Spec lacks definition regarding uniqueness of InstanceHandle_t

  • Key: DDS15-4
  • Legacy Issue Number: 17412
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec defines the following:
    7.1.2.1.1.8 get_instance_handle
    This operation returns the InstanceHandle_t that represents the Entity.

    But it doesn't specify in how far this InstanceHandle_t has to be unique. When the user receives an InstanceHandle_t, is it than unique within the same domain participant, within the process or within the complete dds domain? If it is for example just unique within one domain participant, we can't use it for example as key in a map which could contain entities from multiple domain participants

  • Reported: DDS 1.2 — Fri, 8 Jun 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

get_type_name, class or object method

  • Key: DDS15-6
  • Legacy Issue Number: 16262
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It seems that DDS vendors are implementing get_type_name of the TypeSupport interfaces differently. Some do it as static class method in C++, some as a regular method. The spec uses regular IDL, which gives the idea that it is a regular method needed a concrete TypeSupport instance, but I doubt whether that is intended

  • Reported: DDS 1.2 — Tue, 24 May 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

behaviour of redefining multiple times the same topic with different QoS not clearly specified

  • Key: DDS15-27
  • Legacy Issue Number: 16098
  • Status: open  
  • Source: ADLINK ( Angelo Corsaro)
  • Summary:

    The DDS v1.2 specification does not clearly specify the behaviour of redefining multiple times the same topic with different QoS. As a Topic represents a global assertion, having different applications associating different QoS with the same topic should be flagged as an error.

  • Reported: DDS 1.2 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DataReader semantics for historical data are insufficient

  • Key: DDS15-52
  • Legacy Issue Number: 10805
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    The current specification provides no solution for the following two use-cases:
    · A Volatile DataReader can receive data from a Transient or persistent DataWriter so it may also be interested in historical data. However a DataReader cannot receive historical data. Just making the DataReader Transient does not solve the problem because the DataReader may also be interested in volatile data.
    · A Transient or Persistent DataReader may not be interested in historical data, there is no way to avoid receiving historical data. A DataReader may be e.g. Transient to avoid receiving data from volatile DataWriters, in addition there may be no interest in historical data.

    Solution:
    Separate the control of receiving historical data from the DataReaders durability interest. The DataReaders Durability interest will specify from which DataWriter it will accept data. A separate call will control (ask for) the retrieval of historical data.
    Add the following method
    ReturnCode_t get_historical_data(Duration_t max_wait)
    And Transient and Persistent DataReaders should not automatically receive historical data. A consequence is that this invalidates the method
    ReturnCode_t wait_for_historical_data(Duration_t max_wait).

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS should require to annotate IDL to indicate which IDL types are used for dds

  • Key: DDS15-8
  • Legacy Issue Number: 15835
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In a CCM/DDS4CCM based system not all IDL defined types are intended to be used with dds. At this moment there is not a standardized way to indicate that a type should be usable with DDS. If I now have a large file with a lot of types, DDS just assumes that everything should be transmittable through DDS and generates a lot of code. Just like can indicate the keys of a struct, I think DDS should define a standardized way to annotate the idl so that just some types in a file are handled by the dds tooling

  • Reported: DDS 1.2 — Wed, 17 Nov 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add new mask which will let DDS callback on the listener to gets its mask

  • Key: DDS15-12
  • Legacy Issue Number: 14814
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS has several methods to create entities and pass a listener. With the listener than a mask has to be passed. It would be much cleaner for some C++ systems when we can pass a special mask which means that DDS will callback on the listener to gets its mask, this reduces the application code and could lead to a cleaner user code architecture

  • Reported: DDS 1.2 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Default built-in ReaderDataLifecycle values

  • Key: DDS15-46
  • Legacy Issue Number: 10811
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    QoS settings of buildin Readers: according to section 2.1.5 builtin Readers should have its ReaderDataLifecycles delays set to infinite, meaning that builtin topics that are disposed and/or unregistered will never be removed from the system unless explicitly 'taken'. If an application never bothers to look at the builtin readers, they will never clean up resources and these readers will use up more and more memory if entities keep on joining and leaving the network.

    Solution:
    We propose to give the builtin-readers a finite duration for both auto_purge variables (for example something like 5 minutes).

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Inconsistent lookup semantics

  • Key: DDS15-47
  • Legacy Issue Number: 10810
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    There is inconsistency in the spec: on page 2-24 there is a list of operations that is allowed when the DomainParticipant is in the disabled state. This list does not include any lookup operations. However, on page 2-14 there is also a list of operations which may be invoked when Entity has not yet been enabled, and here the 'lookup' operations are mentioned. So the questions are whether the DomainParticipant should be allowed to perform "find_topic" and "lookup_topicdescription" operations when it is in disabled state.

    Solution:
    Our proposal is that find_topic should not be allowed in this case, but lookup_topicdescription should be allowed. Also all delete operations including the delete_contained_entities should be allowed

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Add several with_profile methods

  • Key: DDS15-7
  • Legacy Issue Number: 15904
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile.

    local interface DomainParticipant : Entity

    { Publisher create_publisher_with_profile( in string library_name, in string profile_name, in PublisherListener a_listener, in StatusMask mask); Subscriber create_subscriber_with_profile( in string library_name, in string profile_name, in SubscriberListener a_listener, in StatusMask mask); Topic create_topic_with_profile( in string topic_name, in string type_name, in string library_name, in string profile_name, in TopicListener a_listener, in StatusMask mask); }

    ;

    local interface DomainParticipantFactory

    { DomainParticipant create_participant_with_profile( in DomainId_t domain_id, in string library_name, in string profile_name, in DomainParticipantListener a_listener, in StatusMask mask); ReturnCode_t set_default_participant_qos_with_profile( in string library_name, in string profile_name); }

    ;

    local interface Publisher : Entity

    { DataWriter create_datawriter_with_profile( in Topic a_topic, in string library_name, in string probile_name, in DataWriterListener a_listener, in StatusMask mask); }

    ;

    local interface Subscriber : Entity

    { DataReader create_datareader_with_profile( in TopicDescription a_topic, in string library_name, in string profile_name, in DataReaderListener a_listener, in StatusMask mask); }

    ;

  • Reported: DDS 1.2 — Tue, 21 Dec 2010 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Extend Topic with method to retrieve key fields

  • Key: DDS15-11
  • Legacy Issue Number: 14829
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template meta programming as we are doing for the dds4ccm spec, it is needed to know at runtime time of the user program whether a topic has a key or not, because behaviour is dependent on that. we propose to add methods to the Topic to get its key fields

  • Reported: DDS 1.2 — Wed, 2 Dec 2009 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

When using GROUP access scope presentation QoS, allow for read/take outside of begin_access and end_access block

  • Key: DDS15-23
  • Legacy Issue Number: 17363
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    Found by: Fernando Crespo
    Severity:

    Problem: The DDS specification (section 7.1.2.5.2.8)
    does not allow access to the DDS cache when the
    application wants to access data, but does not
    care about the order across Data Writers.

    Proposed Resolution:
    When using GROUP access scope, allow both
    access patterns and do not return PRECONDITION_NOT_MET
    error code when called read, take, etc. without first
    called begin_access.

    Note: This also allows portability for applications which
    do not care about the order across topics.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

The compatibility rules for the Presentation QoS are too strict

  • Key: DDS15-24
  • Legacy Issue Number: 17362
  • Status: open  
  • Source: Real-Time Innovations ( Fernando Sanchez)
  • Summary:

    The compatibility rules for the Presentation QosPolicy,
    specified in section 7.1.3.6 of the DDS Specification
    prevent a subscriber configured using GROUP
    access scope from simultaneously matching a
    publisher configured using GROUP access scope
    and a publisher configured using TOPIC or
    INSTANCE access scope.

    Proposed Resolution:
    The addition of a new boolean field
    called "use_highest_offered_access_scope" to
    Presentation QosPolicy.

    This boolean is not propagated as part of the
    discovery information and remains local to the
    subscriber.
    Users configure the subscriber to the minimum
    accepted access scope. When the boolean field
    is set to true, the subscriber will provide the
    access_scope offered by the publisher as opposed to
    its own access_scope value.

    For example: a subscriber wanted to provide GROUP
    access scope when matched with a GROUP
    order publisher and with a publisher providing
    INSTANCE access scope, will use INSTANCE access
    scope and set the user_highest_offered_access_scope
    boolean to true.

  • Reported: DDS 1.2 — Tue, 8 May 2012 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Mapping of OMG IDL to C++ for DDS

  • Key: DDS15-31
  • Legacy Issue Number: 13839
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The mapping of user written IDL to C++ is not described in the version 1.2 of
    the DDS standard.

    Is it expected that DDS use the existing CORBA C++ mapping for data types?
    If so then the standard should state this requirement.

    On the other hand, the CORBA IDL to C++ mapping is fairly old.
    The new DDS PSM for C++ would suggest a more modern mapping.

    For example, for bounded strings and bounded sequences, C++ classes inspired
    by the Standard Template Library (STL) could be used.
    These classes need not necessarily break the DCPS compatibility with the C
    language mentioned in 8.2.1.1. (Use fixed buffer, avoid virtual methods.)
    It is not clear whether unbounded data types need be supported, see issues
    8892 and 12360.

    In case a new mapping is defined which is independent of the CORBA C++
    mapping, there is a problem to address:
    Bridge applications which use both CORBA and DDS would need to translate a
    single IDL file twice, once for CORBA and again for DDS. Then there is an
    overlap in the generated names.
    This problem could be solved by encapsulating all C++ code generated for DDS
    from user IDL in an extra namespace.

  • Reported: DDS 1.2 — Fri, 27 Mar 2009 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Specify the allowed IDL Types within DDS Topic structs

  • Key: DDS15-35
  • Legacy Issue Number: 12360
  • Status: open  
  • Source: Naval Surface Warfare Center ( Paul Werme)
  • Summary:

    The DDS Spec (as of v1.2) does not specify the set of IDL types that are allowed in a DDS Topic struct. This should be defined and made normative instead of being left as an implementation detail.

    Discussion:

    Because the set of IDL types allowed in a DDS Topic struct is not defined, implementors are at liberty to decide what set of IDL types to support. Concerns about the impact of the lack of standardization in this area have been raised by the computing infrastructure teams on major Navy programs on several occasions particularly in regards to potential impact on code portability across DDS implementations and interoperability between DDS implementations.

    In reviewing the DDS C++ Native Language Mapping RFP, we commented that the RFP provided an opportunity to insert a requirement to define the allowed C++ types within a DDS Topic struct which would indirectly result in defining the set of allowed DDS IDL types due to the RFP requirement for the C++ mapping to be consistent with the IDL mapping. This suggestion was rejected because it was viewed that the correct forum and mechanism for resolving this issue was the DDS RTF. We were requested to submit this as an issue to the RTF since the RTF could probably resolve this issue within the next 6 months.

  • Reported: DDS 1.2 — Mon, 31 Mar 2008 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Missing TypeSupport operations

  • Key: DDS15-48
  • Legacy Issue Number: 10809
  • Status: open  
  • Source: Anonymous
  • Summary:

    Problem:
    In IDL, the operations on the TypeSupport interface are commented out: all operations are defined in its specialized sub-classes. That is strange, since all TypeSupport operations have a signature that is completely independent of this specific type.

    Solution:
    We propose to promote all these operations to the TypeSupport class itself, and thus to uncomment these operations in the TypeSupport interface.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DDS should use typed modules

  • Key: DDS11-15
  • Legacy Issue Number: 15430
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS specfication has typed interfaces (writer/reader/etc) which are currently not expressed in IDL. The DDS specification should use the typed modules as introduced in the dds4ccm specification to express all interfaces explicitly in IDL, including the typed ones.

  • Reported: DDS 1.2 — Mon, 23 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT