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?

In addition, the the standard does not define the calendar time of Time_t at

This is required in order to convert a Time_t to/from a system's native time (such the the type time_t on Unix systems which has the calendar start time 1970-01-01 00:00:00).

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.

The IDL file dds_dcps.idl has a wrong value

const string GROUPDATA_QOS_POLICY_NAME = "TransportPriority";

Shouldn't it say "GroupData"

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.

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).

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.)

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

Problem:
In the QoS table (Section 2.2.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.

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

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

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.2.2.2.1) and it is "topic_name" in the method description (section 2.2.2.2.1.7). I assume the name should be consistent.

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?

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?

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

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?

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".

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

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 'synchronous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.

<section 2.2.1.2.2 'Overall Conceptual Model', page 9, penultimate paragraph>
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.

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.

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

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

3. In section 2.3.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 2.2.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.

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.

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

;

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

;

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

;

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.

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

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

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

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

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

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

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.

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

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

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.

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.

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

The compatibility rules for the Presentation QosPolicy, specified in section 2.2.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.

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.

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.

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?

Problem: The DDS specification (section 2.2.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.

Found by: Fernando Crespo
Severity:

Problem:
OMG DDS spec (section 2.2.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.

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);
}; 

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

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_NIL, but they key we use hasn't been registered with dds yet, will DDS than return an error, or automatically register a new instance?

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).

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).

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.

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.

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?

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.

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.

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.

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?

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().

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

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.

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