Data Distribution Service Avatar
  1. OMG Specification

Data Distribution Service — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS15-332 Rules for evaluating liveliness by DataReader need to be clarified DDS 1.4 open
DDS15-320 Missing escaping rules for filter expression, topic expression, query expression DDS 1.4 open
DDS15-331 Proper interpretation of Duration_t for negative values DDS 1.4 open
DDS15-329 set_listener behavior is underspecified DDS 1.4 open
DDS15-250 Align with XTYPES 1.3 and IDL 4.2 DDS 1.4 open
DDS15-315 InstanceHandle_t underspecified DDS 1.4 open
DDS15-328 Annex A: Ownership Profile is unclear DDS 1.4 open
DDS15-327 The "depth" QoS setting does not have any bounds set DDS 1.4 open
DDS15-326 Incorporate the lookup_topicdescription change added in XTYPES 1.3 DDS 1.4 open
DDS15-245 Clarify the PartitionQosPolicy DDS 1.4 open
DDS15-316 find_topic/delete_topic underspecified DDS 1.4 open
DDS15-325 Read / Take with max_samples = 0 DDS 1.4 open
DDS15-324 sample lost/rejected should be clarified and extended DDS 1.4 open
DDS15-323 Order in which implied IDL and language mappings interact DDS 1.4 open
DDS15-321 Example class table seems to violate written convention DDS 1.4 open
DDS15-319 create_querycondition with a query with string parameters DDS 1.4 open
DDS15-318 Extend SampleLostStatus with last_reason DDS 1.4 open
DDS15-317 behaviour of create_topic with duplicate topic_name DDS 1.4 open
DDS15-314 Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted DDS 1.4 open
DDS15-313 Editorial corrections DDS 1.4 open
DDS15-199 Typo DDS 1.4 open
DDS15-312 Default value for WRITER_DATA _LIFECYCLE v should be FALSE DDS 1.4 open
DDS15-311 Add a function that allows releasing any resources created by the DomainParticipantFactory DDS 1.4 open
DDS15-310 get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET DDS 1.4 open
DDS15-256 Define InstanceHandle_t and DomainId_t portably DDS 1.4 open
DDS15-240 The start time of type Time_t is not defined DDS 1.4 open
DDS15-251 Wrong name for DataRepresentationQosPolicy field DDS 1.4 open
DDS15-246 Collection of longs misrepresented in 2.2.1.1 MyClass DDS 1.4 open
DDS15-247 Names of listener operations are incorrect in UML diagrams DDS 1.4 open
DDS15-249 Consider replacing @Choice annotation with XTYPES 1.2 unions DDS 1.4 open
DDS15-195 Typo in section 2.2.2.5 Subscription Module DDS 1.4 open
DDS15-20 The DDS Specification should define legal DDS Topic Types DDS 1.4 open
DDS15-235 DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability DDS 1.4 open
DDS15-32 No specific package definition for the entities of the model in case of JAVA language binding DDS 1.4 open
DDS15-25 History and Reliability should be orthogonally independent concerns DDS 1.4 open
DDS15-21 Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL DDS 1.4 open
DDS15-309 Extend SampleInfo with sequenceNumber and reception_timestamp DDS 1.4 open
DDS15-197 Legal characters and length of Topic Name DDS 1.4 open
DDS15-26 Missing APIs for (read|take)_instance_w_condition DDS 1.4 open
DDS15-303 PARTITION PolicyQos should be in DataReader/DataWriter DDS 1.4 open
DDS15-194 Coherent updates with best efforts DDS 1.4 open
DDS15-248 Deprecate Basic Service Mapping DDS 1.4 open
DDS15-266 Organize definitions of Time_t, Duration_t and other common types in the PIM DDS 1.4 open
DDS15-258 Add a DomainTag to the PSM DDS 1.4 open
DDS15-255 What can be done with a disabled Topic? DDS 1.4 open
DDS15-254 Specify the behavior of instance state machine in case of a disconnect-reconnect scenario DDS 1.4 open
DDS15-253 Consider adding some of the concepts in the new PSMs to the PIM DDS 1.4 open
DDS15-252 Clarify definition of counts in Plain Communication Status DDS 1.4 open
DDS15-244 Communication Status changes for multiple events DDS 1.4 open
DDS15-243 Dispose for topics without key DDS 1.4 open
DDS15-242 set_expression_parameters on ContentFilteredTopic, MultiTopic DDS 1.4 open
DDS15-241 Clarify when a dispose or unregister may be omitted for a Reader DDS 1.4 open
DDS15-238 Add restrictions and guidelines that are required when writing GROUP coherent sets DDS 1.4 open
DDS15-239 Add resource limits related to coherent changes DDS 1.4 open
DDS15-237 How to handle some GROUP ordered Subcriber scenarios DDS 1.4 open
DDS15-236 Request/Offered behavior of DURABILITY Qos does not match use-cases DDS 1.4 open
DDS15-234 Incorporate common elements from DDS Security to the Builtin Topics DDS 1.4 open
DDS15-208 Add DataTagQosPolicy DDS 1.4 open
DDS15-209 Define ranges of QosPolicyId_t DDS 1.4 open
DDS15-207 Durability section typos DDS 1.4 open
DDS15-206 BuiltinTopicKey_t should be completely customizable. DDS 1.4 open
DDS15-205 Specify behavior of filters and queries relative of lifecycle events DDS 1.4 open
DDS15-204 Add API for "directed writes" DDS 1.4 open
DDS15-203 Topic Names are Restricted to Characters, Digits, and Hyphens DDS 1.4 open
DDS15-202 Relationship between begin/end coherent changes and presentation.coherent_access==true DDS 1.4 open
DDS15-201 No specification for unregister_type for TypeSupport interface DDS 1.4 open
DDS15-200 Syntax for Topic Names DDS 1.4 open
DDS15-198 Add a write_sequence() operation to DataWriter DDS 1.4 open
DDS15-196 Clarify RxO behavior for DURABILITY Qos DDS 1.4 open
DDS15-190 Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters DDS 1.4 open
DDS15-29 All IDL should use local interfaces DDS 1.4 open
DDS15-187 Durability Implementation Description does not consider the role of partitions DDS 1.4 open

Issues Descriptions

Rules for evaluating liveliness by DataReader need to be clarified

  • Key: DDS15-332
  • Status: open  
  • Source: Unity Foundation, NP ( Mr. Justin Wilson)
  • Summary:

    2.2.3 (p. 96) The DataReader requests that liveliness of
    the writers is maintained by the requested
    means and loss of liveliness is detected with
    delay not to exceed the lease_duration.
    The DataWriter commits to signalling its
    liveliness using the stated means at
    intervals not to exceed the lease_duration.

    Since both the DataReader and DataWriter have a lease duration, the reference to lease_duration is ambiguous.

    2.2.3.11 (p. 107) Changes in LIVELINESS must be detected by the Service with a time-granularity greater or equal to the lease_duration. This
    ensures that the value of the LivelinessChangedStatus is updated at least once during each lease_duration and the related
    Listeners and WaitSets are notified within a lease_duration from the time the LIVELINESS changed.

    Same problem, the reference to lease_duration could refer to the writer or the reader.

    Other sections not mentioning the lease_duration may have similar problems.

    The language around on_liveliness_changed implies that changes (listener, wait set) must be communicated at least once for every lease_duration of the DataReader.

    The spec should clarify three things:
    1. How often does the DataReader evaluate the liveliness of a DataWriter? Is this at a period of at most the DataReader's lease_duration or a period of at most the DataWriter's lease_duration?
    2. When the DataReader evaluates the liveliness of a DataWriter, which lease_duration should it use, the lease_duration of the DataReader or the lease_duration of the DataWriter?
    3. Are the rules for evaluating liveliness for the purpose of ownership the same as for listeners and waitsets? This question is particularly vexing because it can lead to inconsistency where ownership should be eventually consistent.

    To illustrate the problem, consider the following a system using exclusive ownership.

    • Writer 1 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 1.
    • Writer 2 has a lease_duration of 1 second but only writes/asserts every 4 seconds. Ownership strength of 2.
    • Reader 1 has a lease_duration of 2 seconds.
    • Reader 2 has a lease_duration of 4 seconds.

    Let events happen according to this sequence:

    Time Writer 1 Writer 2 Reader 1 Reader 2
    1. assert      
    2.     eval  
    3.   assert    
    4.     eval eval
    5. assert      
    6.     eval  
    7.   assert    
    8.     eval eval
    9. assert      
    10.     eval  

    If we assume that the readers evaluate liveliness at a period of their own lease_duration using their own lease_duration, then Reader 2 will always see Writer 2 as the owner while Reader 1 will toggle ownership between the writers. Thus, there is no eventual consistency of exclusive ownership.

    If we assume that the readers evaluate liveliness at a period of their own lease_duration using the lease_duration of the writer, then both readers will consistently toggle and never see a live writer.

    If we assume that the readers evaluate liveliness independently for each writer at the lease_duration of the writer, then the readers will see ownership toggling but periods where writers are alive.

    Ideally, liveliness would be objective and not subjective. That is, liveliness should be based on the behavior of the writer interpretted by its lease_duration. Different readers may observe different things leading to temporary inconsistency, but eventual consistency would be guaranteed.

    If the spec choose a subjective approach, then language should be added that warns the reader of the problem and the consequences like ownership not working as expected.

  • Reported: DDS 1.4 — Tue, 12 Nov 2024 16:49 GMT
  • Updated: Thu, 14 Nov 2024 18:26 GMT

Missing escaping rules for filter expression, topic expression, query expression

  • Key: DDS15-320
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should specify how string parameters should be escaped when used withing a query string, for example a query_expression of "name = 'bar'", but what if bar is a string with a single quote, newline, tab, etc? The specification should specify the escaping rules for that.

  • Reported: DDS 1.4 — Thu, 4 Mar 2021 07:04 GMT
  • Updated: Fri, 6 Sep 2024 19:21 GMT

Proper interpretation of Duration_t for negative values

  • Key: DDS15-331
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification does not fully define the meaning of a Duration_t when the second part is negative.

    struct Duration_t {
        long sec;
        unsigned long nanosec;
    };
    

    What is he interpretation of a value when sec <0?
    Does the nanosec part get interpreted to have the same sign?
    If so, then the number between 0 < x < -1 cannot be represented

    So the most logical way to interpret a negative value for the sec field appears to be:

    value = sec + nanosec 
    

    where sec can be positive or negative but nanosec is always positive.
    So the value of negative 1ms would be represented as:

    sec = -1
    nanosec = 999,000,000
    

    The specification should define the proper interpretation.

  • Reported: DDS 1.4 — Mon, 20 Nov 2023 21:13 GMT
  • Updated: Mon, 20 Nov 2023 21:13 GMT

set_listener behavior is underspecified

  • Key: DDS15-329
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Suppose the DATA_AVAILABLE StatusChangedFlag (see Figure 2.16) is set on a DataReader and then a listener (with DATA_AVAILABLE_STATUS in its mask) is attached to the DataReader by the user calling set_listener(). The specification does not specify if the listener should be invoked. If the decision is that the listener is not invoked, then guidance should be given to users that they may need to invoke the listener manually.

  • Reported: DDS 1.4 — Fri, 30 Sep 2022 18:21 GMT
  • Updated: Fri, 30 Sep 2022 18:21 GMT

Align with XTYPES 1.3 and IDL 4.2

  • Key: DDS15-250
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue should be treated as blocker so that it is resolved ahead of other issues.

    • Align naming of annotations with the latest versions of said specifications.
    • Use the new size-aware typenames: int32_t, uint32_t etc. Instead of the classic ones.
    • Use bitmask where it makes sense. For example the StatusKind, InstanceStateKind, ViewStateKind and the corresponding
    • StatusMask, InstanceStateMask, ViewStateMask? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use enum for ReturnCode_t, QosPolicyId_t? Will this negatively impact /break the Java, C#, C++ APIs?
    • Use template modules to model the Implied IDL related to type 'Foo'?
    • Apply the @extensibility annotation to the BuiltinTopicData types and the types they reference (e.g. QosPolicy types) since they are serialized to be sent to other peers. Note that this was already done in XTYPES so we can copy those definitions to the DDS spec and remove them from a future revision of XTYPES.
  • Reported: DDS 1.4 — Mon, 20 May 2019 22:47 GMT
  • Updated: Thu, 2 Jun 2022 00:59 GMT

InstanceHandle_t underspecified

  • Key: DDS15-315
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 2.2.2.1.1.8 the Instance handle is mentioned by the spec lacks some definition of InstanceHandle_t. In how far as instance handles unique and should they be comparable? Are they unique system wide or process wide? Is it legal to have two DDS entities (for example two domain participants) to have the same instance handle? This is important for users who for example store DDS entities in a std::map.

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 07:30 GMT
  • Updated: Wed, 25 May 2022 23:42 GMT

Annex A: Ownership Profile is unclear

  • Key: DDS15-328
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The bullet point for " This profile adds two things " goes on to list three things. The third is about History QoS, which makes it appear to the reader like this was added on later and not initially part of the profile. That itself is not a problem, but for clarity this section should provide a rationale as to why the History QoS Policy is involved in the definition of Ownership Profile.

  • Reported: DDS 1.4 — Thu, 7 Apr 2022 15:54 GMT
  • Updated: Thu, 7 Apr 2022 15:54 GMT

The "depth" QoS setting does not have any bounds set

  • Key: DDS15-327
  • Status: open  
  • Source: Open Robotics ( William Woodall)
  • Summary:

    The description of the history depth QoS setting indicates it is optional and only used when KEEP_LAST is the history kind, and that it is a long (or sometimes referred to as an integer/int), and that the default value is 1, and that it needs to be consistent with related RESOURCE_LIMITS QoS settings, but it does not specify a bounds nor does it explicitly state that the bounds are actually any valid (signed) long value. So a few boundary cases are not well defined, for example:

    • is KEEP_LAST with depth 0 valid? If so, is it a special behavior?
    • what about negative values for depth?

    RTI's Connext Pro documentation limits it to values greater than zero and less than 100,000,000:

    > "[range] [1,100 million], <= DDS_ResourceLimitsQosPolicy::max_samples_per_instance"
    https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/api/connext_dds/api_c/structDDS__HistoryQosPolicy.html#aef0fb3fd3579866be17d1a936f5e3729

    Other implementations like Cyclone DDS and Fast-DDS will accept values of zero, though it's not clear what they're behavior is in that case.

    Those are useful to imply what the behavior is, but I think the standard should probably take stance on the valid values for depth, and I think values >= 1 makes sense, though the "100 million" upper bound set by RTI's API seems kind of arbitrary, though I don't have a better alternative in mind.

  • Reported: DDS 1.4 — Thu, 24 Feb 2022 02:30 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

Incorporate the lookup_topicdescription change added in XTYPES 1.3

  • Key: DDS15-326
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.6.4.2 Operation: DomainParticipant::lookup_topicdescription
    in XTYPES 1.3 makes a changes to the DDS spec in the description of the Operation: DomainParticipant::lookup_topicdescription

    This change should be consolidated into the DDS specification.

  • Reported: DDS 1.4 — Tue, 4 Jan 2022 21:09 GMT
  • Updated: Tue, 4 Jan 2022 21:09 GMT

Clarify the PartitionQosPolicy

  • Key: DDS15-245
  • Status: open  
  • Source: Brunvoll AS ( Havard Skjevling)
  • Summary:

    It is ambiguous whether or not the PartitionQosPolicy set for a Publisher or Subscriber should affect DataWriter and DataReader matching, and how an implementation should handle it.

    Since it is stated that failure to match partitions does not imply "incompatible" QoS, it would seem it does not affect matching.
    If so, the specification should be clearer with regards to

    • whether this is filtered on the publishing, or subscribing side (or both)
    • how partitions are tied to samples or instances e.g. when written from a DataWriter whose Publisher changes partitions intermittently
    • how it deals with late joiners and historical data
    • how this affects the "transient/persistent" services and their entities' QoS settings

    2.2.3 QosPolicy Table

    A DataWriter within a Publisher only communicates with a DataReader in a Subscriber if (in addition to matching the Topic and having compatible QoS) the Publisher and Subscriber have a common partition name string.

    2.2.3.13 Partitions

    For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must
    share a common partition. Each string in the list that defines this QoS policy defines a partition name. A partition name may
    contain wildcards. Sharing a common partition means that one of the partition names matches.
    Failure to match partitions is not considered an “incompatible” QoS and does not trigger any listeners nor conditions.

  • Reported: DDS 1.4 — Wed, 7 Nov 2018 11:03 GMT
  • Updated: Tue, 16 Nov 2021 20:21 GMT

find_topic/delete_topic underspecified

  • Key: DDS15-316
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It is not clear what kind of restrictions there are to find_topic/delete_topic.

    Assume two software modules in the same process, order of instantiation is not fixed, also more modules could be loaded by a configuration file. All modules use find_topic to find topic Foo, the first module now calls create_topic to create the topic, second module gets topic Foo through find_topic.

    Each module now creates its own datareader/datawriters using the topic it retrieved. At the moment the module now ends it cleans the datareader/datawriter it has created and now calls delete_topic. It is not clear what at that moment delete_topic will return for the module that has successfully used find_topic to get the topic. Some DDS vendors return RETCODE_OK, some RETCODE_PRECONDITION_NOT_MET because there are still readers/writers related to that topic (but the other module did use create_topic). The shutdown order can also be swapped, so first the module that used create_topic will be removed, the one with find_topic keeps running.

    The description of find_topic should be extended to clarify how it behaves related to delete_topic? Personally I think RETCODE_OK should be returned when there is no DataReader, DataWriter, ContentFilteredTopic, or MultiTopic attached anymore to the topic returned by find_topic, independent of the entities attached to the topic as it was created by create_topic (or a different find_topic call)

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 12:36 GMT
  • Updated: Thu, 22 Jul 2021 06:17 GMT

Read / Take with max_samples = 0

  • Key: DDS15-325
  • Status: open  
  • Source: eProsima ( Miguel Company)
  • Summary:

    It is not clear what should be done if the user calls read, take, or any of their variants when the following conditions are met:

    1. The method is called with max_samples = 0
    2. There is data available that would be returned with max_samples > 0

    I think we have two options here:

    1. Return NO_DATA
    2. Return OK with a resulting collection with len = 0

    The last sentence of the section seems to indicate the latter...

    If the DataReader has no samples that meet the constraints, the return value will be NO_DATA

    ... but the definition of NO_DATA on page 5 seems to indicate the former (as no data is returned)

    Indicates a transient situation where the operation did not
    return any data but there is no inherent error.

  • Reported: DDS 1.4 — Thu, 15 Jul 2021 09:02 GMT
  • Updated: Tue, 20 Jul 2021 13:20 GMT

sample lost/rejected should be clarified and extended

  • Key: DDS15-324
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    when testing for sample lost/rejected between multiple DDS vendors we see different vendors to different things. The specification should be extended with more information when a sample is considered lost and when rejected with also more details how QoS settings would influence this. We see that vendors have extended the SampleLostStatus and SampleRejectedStatus and even have deprecated some of its members, this should be handled in the specification so that the user gets the same behavior when using multiple vendors

  • Reported: DDS 1.4 — Thu, 27 May 2021 16:27 GMT
  • Updated: Thu, 3 Jun 2021 18:53 GMT

Order in which implied IDL and language mappings interact

  • Key: DDS15-323
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There looks to be different interpretations between DDS vendors how implied IDL and language mappings interface. The specification lists in 2.3.3 the example of type Foo which results in the implied IDL DataWriter named FooDataWriter. On this implied IDL the concrete language mapping is applied, so with IDL to C++ we get FooDataWriter/FooDataWriter_ptr/FooDataWriter_var. But, what happens when the type is a IDL or C++ keyword, for example the type _public results in the implied IDL publicDataWriter, on which the IDL to C++ language mapping is implied, so to our idea you get _cxx_public/publicDataWriter/publicDataReader. The IDL to C++ language mapping only sees the identifiers as resulted by the implied IDL rules. Some vendors do generate _cxx_public/_cxx_publicDataWriter/_cxx_publicDataReader which means the implied IDL and IDL to C++ language mapping are strangely mixed. A generaic modeling tool for example only knows of implied IDL, a custom code generator generates the code for the specific language mapping.

    The specification should give an example for _public, what does the programmer now get in a specific programming language, for example C++

  • Reported: DDS 1.4 — Wed, 19 May 2021 11:54 GMT
  • Updated: Thu, 20 May 2021 20:27 GMT

Example class table seems to violate written convention

  • Key: DDS15-321
  • Status: open  
  • Source: Air Force Institute of Technology, Student ( Nathaniel Peck)
  • Summary:

    Above the Myclass example table, the written text says that collections of types will be denoted by <type>[]. The example describes in: param4 as being a collection of longs, but the table defines the type as long rather than long[] as the written convention seems to imply.

  • Reported: DDS 1.4 — Tue, 30 Mar 2021 17:56 GMT
  • Updated: Thu, 1 Apr 2021 15:53 GMT

create_querycondition with a query with string parameters

  • Key: DDS15-319
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We identified differences between DDS vendors how to handle a query condition that uses a string parameter. At the moment we have a query with "symbol = %0", what is the query parameter string we need to use when we want to match it with OMG. When using for example C++, RTI Connext DDS seems to require "'OMG'", so single quotes around the string itself, but OpenDDS/Opensplice seem to use "OMG" so without single quotes around the string.

    The specification should be clear about how strings are used when they are passed through a query parameter like %0.

  • Reported: DDS 1.4 — Fri, 26 Feb 2021 14:24 GMT
  • Updated: Thu, 4 Mar 2021 01:01 GMT

Extend SampleLostStatus with last_reason

  • Key: DDS15-318
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Several DDS vendors have already extended SampleLostStatus with a last_reason, indicating why the last sample was lost. We would like to see this in the DDS specification so that all vendors provide this consistently

  • Reported: DDS 1.4 — Mon, 23 Nov 2020 12:11 GMT
  • Updated: Mon, 28 Dec 2020 17:03 GMT

behaviour of create_topic with duplicate topic_name

  • Key: DDS15-317
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the DDS spec should define the behaviour when the create_topic is called multiple times with the same topic_name, I think the operation should fail at that moment, but that is not mentioned in the spec

  • Reported: DDS 1.4 — Mon, 16 Nov 2020 17:36 GMT
  • Updated: Tue, 17 Nov 2020 14:30 GMT

Change the default value for DataWriterLifecycle::autodispose_unregistered_instances and behavior when a DataWriter is deleted

  • Key: DDS15-314
  • Status: open  
  • Source: Real-Time Innovations ( Ms Erin McManus)
  • Summary:

    Unregistering and disposing instances have different semantics and the default association of these two operations through the usage of the autodispose_unregistered_instances may lead to behaviors that are unexpected and not desirable to DDS users.

    The unregister operation is meant to indicate that the DataWriter will no longer update the instance but does not indicate anything about the state of the instance itself. The dispose operation, on the other hand, is meant to indicate a change in the state of the instance, it indicates that the instance has been deleted. Because of this, we are proposing changing the default value of this QoS to FALSE. This is something that many of our customers end up doing explicitly.

    In addition to changing the default value for autodispose_unregistered_instances, we are also proposing that this QoS does not have any effect during the deletion of the DataWriter. Disposing of an instance should be an explicit operation (individual or bulk operation). In many cases, the user's intention is not to delete (dispose) an instance when a DataWriter is deleted and doing so explicitly ties the lifecycle of the instance to the lifecycle of the DataWriter.

  • Reported: DDS 1.4 — Wed, 2 Sep 2020 23:52 GMT
  • Updated: Thu, 3 Sep 2020 20:00 GMT

Editorial corrections

  • Key: DDS15-313
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    p2 5th para middle sentence

    The purpose of the DDS specification is to
    define the standardized interfaces and behaviors that enable applicaton portability.

    -> application



    p11 Figure 2.5 bottom right class box,
    p58 Figure 2.10 bottom middle class box,
    p125 Figure 2.19 middle right class box

    QueryConditon

    -> QueryCondition



    p61 2.2.2.5.1.4 1st para 3rd sentence

    change of state for an intance that was caused by some internal mechanism

    -> instance



    p61 2.2.2.5.1.4 1st para 4th sentence

    An example of this situation is when the Service [...] and changes the coresponding

    -> corresponding



    p61 2.2.2.5.1.4 2nd para 2nd sentence

    The application can distinguish wether a particular DataSample has data

    -> whether



    (DDS15-195)
    p61 2.2.2.5.1.4 3rd para 1st sentence

    To ensure corerctness and portability, the valid_data flag must be examined

    -> correctness

    p107 2.2.3.13 4th para 3rd sentence

    It may establish new "matchs" that did not exist before, or break existing matchs.

    -> "matches" , matches.



    p110 2nd para 2nd sentence

    [...] For example setting
    max_samples_per_instance to LENGH_UNLIMITED will cause the middleware to [...]

    -> LENGTH_UNLIMITED



    p120 2.2.4.2.2 enumerated list 2nd bullet 2nd sub-bullet

    • the DataWriter that owns it if OWNERSHIP QoS kind=EXLUSIVE, or by

    -> kind=EXCLUSIVE



    p121 Figure 2.16 statebox at right

    StatiusChangedFlag = TRUE

    -> StatusChangedFlag



    p166 top

    Selection        ::=    TOPICNAME
                     |      TOPICTNAME NaturalJoin JoinItem
    

    -> TOPICNAME NaturalJoin JoinItem

  • Reported: DDS 1.4 — Mon, 11 May 2020 03:39 GMT
  • Updated: Thu, 28 May 2020 20:35 GMT

Typo

  • Key: DDS15-199
  • Status: open  
  • Source: Netherlands Aerospace Centre ( Arnoud van Leeuwen)
  • Summary:

    Suspected typo in paragraph 4, last scentece:
    "In other words, the DataReader may miss some data-samples but it will never see the
    value of a data-object change from a newer value to an order value."

    Should the second to last word "order", not be: "older"? The context seems to suggest so.

  • Reported: DDS 1.4 — Fri, 19 Aug 2016 07:53 GMT
  • Updated: Mon, 11 May 2020 03:42 GMT

Default value for WRITER_DATA _LIFECYCLE v should be FALSE

  • Key: DDS15-312
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    According to the Qos table in 2.2.3 'Supported QoS' the default value for autodispose_unregistered_instance is TRUE. We have found a two issues with this

    (1) It is not semantically what people expect. Just because a DataWriter is deleted it does not mean all the instances should be deleted... It could be so for some use-cases, but we found that in the majority of the use-cases it is not an intuitive behavior.

    (2) It is not scalable. If writer with a lot of instances is deleted. it needs to send many messages and potentially wait until they are acknowledged before releasing the DataWriter resources. This makes the data-writer delete operation something that can block for an unbounded time which is not what applications expect.

    It sees it would be better to:
    (a) Change the default value of autodispose_unregistered_instance to FALSE.
    (b) Provide a better/more efficient/scalable way to communicate to the DataReaders that all the instances of a DataWriter have been deleted.

  • Reported: DDS 1.4 — Thu, 30 Apr 2020 21:02 GMT
  • Updated: Fri, 8 May 2020 12:32 GMT

Add a function that allows releasing any resources created by the DomainParticipantFactory

  • Key: DDS15-311
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Domain Participant Factory may create resources (e.g. tables that allow looking up or manage created domain participants, etc.)

    These resources need to be released when the application shuts down so that they are not reported as "leaks" by the OS.

    A function should be added that forcefully releases all resources created by the DomainParticipantFactory. This function would have as a pre-requisite that all DomainParticipants have been deleted...

  • Reported: DDS 1.4 — Fri, 27 Mar 2020 21:46 GMT
  • Updated: Fri, 27 Mar 2020 21:46 GMT

get_discovered_participant_data() should return BAD_PARAMETER instead of PRECONDITION_NOT_MET

  • Key: DDS15-310
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue has to do with the proper code when the function
    get_discovered_participant_data gets passed an invalid handle.

    This function is analogous to get_matched_subscription_data() and get_matched_publication_data() except that that it retrieves information on the matching participant instead of the matching endpoint. All these functions take a handle as an input that refers to the "matching" entity for which information is
    being retrieved.

    Prior to version 1.2 get_matched_subscription_data() was returning PRECONDITION_NOT_MET and get_matched_publication_data BAD_PARAMETER.
    Returning BAD_PARAMETER seemed more appropriate so in version 1.2 (OMG issue 9500) we updated get_matched_subscription_data to also return BAD_PARAMETER.

    However get_discovered_participant_data() was not updated as part of is still returning PRECONDITION_NOT_MET.

    Therefore get_discovered_participant_data() should be updated to also return BAD_PARAMETER when an invalid handle is passed.

  • Reported: DDS 1.4 — Fri, 28 Feb 2020 20:31 GMT
  • Updated: Fri, 28 Feb 2020 20:31 GMT

Define InstanceHandle_t and DomainId_t portably

  • Key: DDS15-256
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Define InstanceHandle_t as a structure that contains native data
    Define DomainId_t as an integer

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 11:57 GMT
  • Updated: Thu, 10 Oct 2019 00:04 GMT

The start time of type Time_t is not defined

  • Key: DDS15-240
  • Status: open   Implementation work Blocked
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Section 2.3.2 on page 138 contains:

    The two types used to represent time: Duration_t and Time_t are mapped into structures that contain fields for the second and the nanosecond parts.

    However, the standard does not define the calendar time of Time_t at

    { sec = 0, nanosec = 0 }

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

  • Reported: DDS 1.4 — Sat, 21 Jul 2018 07:19 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Wrong name for DataRepresentationQosPolicy field

  • Key: DDS15-251
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Section 7.6.3.1.3 'DataRepresentationQosPolicy: Platform-Specific API' states:

    The topic, publication, and subscription built-in topic data types shall each indicate the data representation of the associated entity with a new member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;

    This does not follow the naming conventions for field names. Instead it should have said that the new member should be:
    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;

    Likewise in Annex D the declarations of structures TopicBuiltinTopicData, TopicQos, PublicationBuiltinTopicData, DataWriterQos, SubscriptionBuiltinTopicData, and DataReaderQos all have the member:

    @id(0x0073) DDS::DataRepresentationQosPolicy representation;
    

    This should be changed so the member is:

    @id(0x0073) DDS::DataRepresentationQosPolicy data_representation;
    
  • Reported: DDS 1.4 — Wed, 5 Jun 2019 23:44 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Collection of longs misrepresented in 2.2.1.1 MyClass

  • Key: DDS15-246
  • Status: open  
  • Source: Turkish Navy Research Center ( Akif Tokuz)
  • Summary:

    In MyClass table on page4 (pdf page 16/180), param4 is given type long. But the description says above:"‘param4,’ is also an input parameter of type collection of longs"
    So it must be "long []" instead of "long".

    I checked the DDS 1.2 spec (formal/07-01-01), it was correct in that version (pdf page 18/260).

    Akif,

  • Reported: DDS 1.4 — Thu, 3 Jan 2019 13:23 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Names of listener operations are incorrect in UML diagrams

  • Key: DDS15-247
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In Figures 2.9, 2.10, and 2.17, the Data*Listener classes in the UML incorrectly have functions called

    on_*_match()

    when in fact they should be

    on_*_matched()
  • Reported: DDS 1.4 — Thu, 14 Feb 2019 23:35 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Consider replacing @Choice annotation with XTYPES 1.2 unions

  • Key: DDS15-249
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

    Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

    However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

    An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

  • Reported: DDS 1.4 — Mon, 20 May 2019 22:45 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Typo in section 2.2.2.5 Subscription Module

  • Key: DDS15-195
  • Status: open  
  • Source: Technical University of Madrid ( Jesús Rodríguez-Molina)
  • Summary:

    While this is a very minor issue, it is a good idea to mention it. In the line starting with "To ensure corerctness and portability" I guess it is meant "To ensure correctness and portability", thus having a typo in "corerctness". Am I right?

    Kind regards,

    Jesús Rodríguez-Molina

  • Reported: DDS 1.4 — Wed, 16 Mar 2016 11:36 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

The DDS Specification should define legal DDS Topic Types

  • Key: DDS15-20
  • Legacy Issue Number: 19141
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The DDS v1.2 specification does not explicitly define the subset of IDL that can be used to express Topic Types. From the specification, it can be inferred – and all vendor have done so – that a topic type is defined by means of a struct and that the IDL types that cannot be used for the attributes of this struct are Value-Types, Any Types and Object References.

    The DDS v1.2 should explicitly state this. Notice the the problem is not solved by the X-Types specification as that introduces a set of types, such as Maps, Optional types, etc. that are not supported by DDS v1.2 implementations.

    This is really a critical matter which is trivial to solve. Just state what is implicitly assumed and should be fixed ASAP.

  • Reported: DDS 1.4 — Thu, 12 Dec 2013 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

DURABILITY history depth should be de-coupled from the KEEP_LAST history depth used for reliability

  • Key: DDS15-235
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The specification provides no way to way to specify a different history depth used for DURABILITY than the used for reliability...

    The HISTORY depth is sometimes needed for reliability in order to accommodate bursts. But this means that the amount of data kept for DURABILITY is affected.

    What is desirable is to have a setting that allows the DURABILITY depth to be decoupled from the RELIABILITY.

  • Reported: DDS 1.4 — Tue, 27 Mar 2018 16:37 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

No specific package definition for the entities of the model in case of JAVA language binding

  • Key: DDS15-32
  • Legacy Issue Number: 13448
  • Status: open  
  • Source: Selex ES ( Dario Di Crescenzo)
  • Summary:

    The DDS specification document does not prescribes a specific package definition for the entities of the model in case of JAVA language binding; in the IDL only a "DDS" module is defined which does not result in a strictly specified package structure (it might only imply that the entities belong to the DDS package/namespace). It would be useful to have a precise statement indicating at least for the JAVA binding the packages to which the DDS Entities must belong in order to have all implementations using the same packages for the same Entities (e.g org.omg.dds.infrastructure, org.omg.dds.domain, etc..)

  • Reported: DDS 1.4 — Fri, 6 Feb 2009 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

History and Reliability should be orthogonally independent concerns

  • Key: DDS15-25
  • Legacy Issue Number: 17284
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader.

    In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" – this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why.

    Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being).

    Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message.

    Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast(n). In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers – without holes – might finds him-/her-self surprised by the fact that some samples might be missing.

  • Reported: DDS 1.4 — Thu, 29 Mar 2012 04:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Wrong definition of GROUPDATA_QOS_POLICY_NAME constant in IDL

  • Key: DDS15-21
  • Legacy Issue Number: 18320
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    GROUPDATA_QOS_POLICY_NAME is given as "TransportPriority", and the corresponding *_POLICY_NAME from TRANSPORTPRIOIRTY is missing.

    Index: dds/DdsDcpsInfrastructure.idl
    ===================================================================
    --- dds/DdsDcpsInfrastructure.idl
    +++ dds/DdsDcpsInfrastructure.idl
    @@ -327,7 +327,8 @@
         const string WRITERDATALIFECYCLE_QOS_POLICY_NAME = "WriterDataLifecycle";
         const string READERDATALIFECYCLE_QOS_POLICY_NAME = "ReaderDataLifecycle";
         const string TOPICDATA_QOS_POLICY_NAME           = "TopicData";
    -    const string GROUPDATA_QOS_POLICY_NAME           = "TransportPriority";
    +    const string GROUPDATA_QOS_POLICY_NAME           = "GroupData";
    +    const string TRANSPORTPRIORITY_QOS_POLICY_NAME   = "TransportPriority";
         const string LIFESPAN_QOS_POLICY_NAME            = "Lifespan";
         const string DURABILITYSERVICE_POLICY_NAME       = "DurabilityService";
    
  • Reported: DDS 1.4 — Mon, 17 Dec 2012 05:00 GMT
  • Updated: Thu, 10 Oct 2019 00:03 GMT

Extend SampleInfo with sequenceNumber and reception_timestamp

  • Key: DDS15-309
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Many vendors already extend the SampleInfo with some additional fields:

    • The reception_timestamp
    • The writerSequence number.

    I would propose we make these part of the new standard.

  • Reported: DDS 1.4 — Wed, 25 Sep 2019 20:15 GMT
  • Updated: Wed, 25 Sep 2019 20:15 GMT

Legal characters and length of Topic Name

  • Key: DDS15-197
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS specification states a Topic name is a string but it does not state what the legal characters are. It would therefore be possible to use "unprintable" characters which could create difficulties with printing and logginf messages.
    Because of this it is also possible for multiple vendors to put in place restrictions that could cause incompatibilities.

    For this reason it is desirable that the specification states with characters are legal within a Topic name.

    In addition RTPS version 2.2 defines TopicName as string<256> this should also be reflected in DDS.

  • Reported: DDS 1.4 — Tue, 17 May 2016 21:54 GMT
  • Updated: Mon, 23 Sep 2019 15:42 GMT

Missing APIs for (read|take)_instance_w_condition

  • Key: DDS15-26
  • Legacy Issue Number: 16607
  • Status: open  
  • Source: Real-Time Innovations ( Kevin Jaeger)
  • Summary:

    For keyed topics, the core set of read or take APIs support read|take, read|take_instance, and read|take_next_instance.

    The corresponding set of API's for read or take with conditions only specified read|take_w_condition and read|take_next_instance_w_condition. The specification lacks the APIs for read|take_instance_w_condition.

    Lack of these APIs deprives the user from the ability to read or take from a specific instance while limiting the sample set to specific conditions.

  • Reported: DDS 1.4 — Fri, 14 Oct 2011 04:00 GMT
  • Updated: Tue, 27 Aug 2019 23:25 GMT

PARTITION PolicyQos should be in DataReader/DataWriter

  • Key: DDS15-303
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The logic of the PARTITION Qos applies separately to each DataReader/DataWriter and the propagation on the DCPS bultin Topics also happens along with each DataReader and DataWriter.

    Despite this the PARTITION Qos can only be set on the Publisher/Subscriber which impact all the DataWriters/DataReaders they contain. To overcome this we have seen many users create a separate Publisher/Subscriber per DataWriter/DataReader which unnecessarily consumes resources and couples them.

    The recommendation is to allow the PARTITION Qos to be set directly on the DataWriter and DataReader. This would not impact the behavior of partition matching. Just makes it more flexible to use.

    A question is whether we should still allow the Publisher/Subscriber to have a PARTITION Qos. This may be desirable to avoid braking existing code. In this case we could interpret as a 'default" unless ta DataWriter/DataReader specifies it explicitly. This would make current applications work without changes.

  • Reported: DDS 1.4 — Fri, 16 Aug 2019 00:54 GMT
  • Updated: Mon, 19 Aug 2019 14:27 GMT

Coherent updates with best efforts

  • Key: DDS15-194
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Clarify what happens if coherent updates involve best-effors writers. Would missing one sample cause the whole set to be discarded?

    Affects both TOPIC coherence and GROUP coherence if there are some best-efforts writers in the Publisher

  • Reported: DDS 1.4 — Tue, 15 Mar 2016 15:36 GMT
  • Updated: Fri, 16 Aug 2019 00:09 GMT

Deprecate Basic Service Mapping

  • Key: DDS15-248
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The Basic Service Mapping was included in the specification primarily to support implementations that did not support XTYPES. Now that most DDS support XTYPES this motivation is no longer there.

    Having both a Basic Service Mapping and an Enhance Service Mapping creates significant complexity and ambiguity. It becomes another choice the user must make and another way implementations may not interoperate.

    Furthermore when other specifications map to DDS Services, they must too make a choice of Service Mappings. Hence perpetuating complexity and interoperability issues.

    The Enhanced Service Mapping has significant advantages in terms of performance, scalability, and type-system simplicity. Fundamentally it allows the use of the same types for request reply and RPC, any extra information is added in meta-data so that the types themselves are unpolluted. This is in-line with what other middleware technologies (e.g. JMS) does.

    Therefore the most sensible thing is to deprecate the Basic Service Mapping.

  • Reported: DDS 1.4 — Mon, 20 May 2019 22:31 GMT
  • Updated: Thu, 15 Aug 2019 00:50 GMT

Organize definitions of Time_t, Duration_t and other common types in the PIM

  • Key: DDS15-266
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The PIM contains definitions for most of the "reference semantic" classes. But it does not directly define the "value semantic" classes such as: Time_t, Duration_t, SequenceNumber_t, InstanceHandle_t, StatusKind, StatusMask, etc.

    Some types like ReturnCode_t are defined. But this is done in an odd place: (section 2.2.1.1 'Format and Conventions').

    The PIM would be more clear if these types were all defined clearly in a centralized place. For example the Infrastructure module.

    This issue should be treated as a "Blocker" so it is resolved ahead of other issues. That way the other issues can refer to the new definitions and organization.

  • Reported: DDS 1.4 — Wed, 7 Aug 2019 11:03 GMT
  • Updated: Wed, 7 Aug 2019 11:03 GMT

Add a DomainTag to the PSM

  • Key: DDS15-258
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added a domainTag (see Table 8.73 - RTPS SPDPdiscoveredParticipantData attributes) this was done to support having the DDS RTF adding it to the next version of the Spec. This task should be completed.

    The domainTag is used to isolate domains even if they are on the same DDS domainId

  • Reported: DDS 1.4 — Mon, 5 Aug 2019 12:22 GMT
  • Updated: Mon, 5 Aug 2019 12:22 GMT

What can be done with a disabled Topic?

  • Key: DDS15-255
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Since Topics are Entities, they can exist in a disabled state. Section 2.2.2.1.1.7 is insufficient to define what can (more importantly, can't) be done with a disabled Topic.
    That section defines which operations "may be invoked on it", but more interesting for Topics are the passive uses of these objects as arguments to other operations.
    In particular, it should be explicitly stated that a DataReader or Writer that references a disabled Topic (including, for readers, indirectly via ContentFilteredTopic or MultiTopic) cannot be enabled. In these cases, the enable() operation returns RETCODE_PRECONDITION_NOT_MET.

  • Reported: DDS 1.4 — Tue, 9 Jul 2019 15:56 GMT
  • Updated: Tue, 9 Jul 2019 15:56 GMT

Specify the behavior of instance state machine in case of a disconnect-reconnect scenario

  • Key: DDS15-254
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The DDS specification is very clear what happens in case of a disconnect: the receiver will behave as if the sender unregistered all its instances. But what should the behavior be in case of a reconnect?

    For VOLATILE cases the behavior might still be intuitive: an instance stays NOT_ALIVE_NO_WRITERS until an update has been received, in which case it goes back to ALIVE. And because VOLATILE data is typically periodic data, eventually all my instances will come back alive.

    But what about non-volatile data, that is typically not periodic, or is periodic but with a very low update frequency? Consider the following scenario:

    • Writer A writers 10 samples belonging to 10 different instances.
    • Reader B takes all samples.
    • Writer A disconnects from Reader B.
    • Reader B receives invalid samples indicating all instances are now NOT_ALIVE_NO_WRITERS.
    • Reader B takes these samples.
    • A reconnection is established, and none of the instances have been updated by Writer A.

    You would expect that all instances in Reader B would go back to the ALIVE state, but how do I get them back into the ALIVE state? Since there are no more samples to piggy-bag this instance state change on.

    A couple of approaches are conceivable:

    • Use an invalid sample to bring the instance back alive.
    • Republish the last available sample
    • Do nothing.

    Every approach has its pro's and cons, but the DDS spec should clearly describe which behavior is intended here.

  • Reported: DDS 1.4 — Wed, 19 Jun 2019 12:15 GMT
  • Updated: Wed, 19 Jun 2019 12:15 GMT

Consider adding some of the concepts in the new PSMs to the PIM

  • Key: DDS15-253
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Examples:

    • Selector from C++ PSM
    • Cascading operations to set Qos policies qos.with().with().
    • Dispatch on waitset and conditions (attach a function)
    • "close" operation that is recursive and avoids having a handle to the factory.
      *
  • Reported: DDS 1.4 — Wed, 19 Jun 2019 10:00 GMT
  • Updated: Wed, 19 Jun 2019 10:00 GMT

Clarify definition of counts in Plain Communication Status

  • Key: DDS15-252
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The second table in 2.2.4.1 (the one that starts with "SampleLostStatus") has confusing definitions of the "counts" in various plain communication status.

    Certain "statuses" simply report events that occur within the Entities. Sample Lost is a good example of this. When a sample is lost, it's lost for good and not coming back. Therefore we expect total_count_change to be nonnegative. In this case the total_count definition is clear.

    Other "status" are ways to report some aspect of the state of the Domain to the application. Inconsistent Topic is an example of this. Since remote Entities can change at any time, the count of inconsistent topics may decrease (for example, when a Topic owned by a remote Participant is deleted). For the "statuses" in this category, the wording of the definition of total_count (and perhaps other attributes) is confusing since it starts with "Total cumulative count..." just like the one for Sample Lost.

  • Reported: DDS 1.4 — Fri, 7 Jun 2019 15:36 GMT
  • Updated: Fri, 7 Jun 2019 15:36 GMT

Communication Status changes for multiple events

  • Key: DDS15-244
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    Plain Communication Status structures may undergo multiple changes between the time the first event occurs and when the application reads/resets the Plain Communication Status. This results in loss of important data that DDS should make available to the application. It is more likely to occur when using the WaitSet/StatusCondition mechanism instead of Listeners, but may occur with Listeners depending on how the implementation determines when to invoke the Listener.

    For example, an application creates a DataReader that uses Deadline QoS. In order to monitor for Deadline violations, the application gets the reader's StatusCondition and adds it to a WaitSet. If that Condition becomes active, the application invokes get_requested_deadline_missed_status to determine which instance experienced the deadline violation (using last_instance_handle). However, in the case that multiple instances have deadline violations since the last time status was checked (total_count_change > 1), the identity of all but the last of those instances is not available to the application.

    This same concept applies to any of the uses of "last_*" in the Plain Communication Status structures.

  • Reported: DDS 1.4 — Tue, 2 Oct 2018 17:44 GMT
  • Updated: Tue, 2 Oct 2018 17:44 GMT

Dispose for topics without key

  • Key: DDS15-243
  • Status: open  
  • Source: Central Research Laboratory, Bharat Electronics Ltd ( Saurabh Bansal)
  • Summary:

    Behavior of dispose is not specified for topics without key.
    As per section "2.2.1.2.2 Overall Conceptual Model",. If no key is provided, the data set associated with the Topic is restricted to a single instance.

    If data set is considered as a single instance than dispose of that instance shall be possible.

  • Reported: DDS 1.4 — Wed, 19 Sep 2018 17:08 GMT
  • Updated: Thu, 20 Sep 2018 17:58 GMT

set_expression_parameters on ContentFilteredTopic, MultiTopic

  • Key: DDS15-242
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    When expression parameters change, should any data stored in associated DataReaders be re-evaluated using the new parameters? Or do the DataReaders reflect the state of the parameters at the time the data was received?

  • Reported: DDS 1.4 — Wed, 22 Aug 2018 20:27 GMT
  • Updated: Wed, 22 Aug 2018 20:27 GMT

Clarify when a dispose or unregister may be omitted for a Reader

  • Key: DDS15-241
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    If a writer disposes an instance that it never sent to a reader, should it still send the dispose to the reader?

    In general sending it would cause an scalability problem. So it would be better not to.

    However there are cases where it may be needed. For example if a Writer sets an alarm and a different writer that never created it wants to dispose it.

    Perhaps this behavior something is something that should be configurable on the Reader or Writer.

  • Reported: DDS 1.4 — Wed, 8 Aug 2018 15:25 GMT
  • Updated: Wed, 8 Aug 2018 17:47 GMT

Add restrictions and guidelines that are required when writing GROUP coherent sets

  • Key: DDS15-238
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added support for GROUP ordered access and coherent access. As part of this effort, a number of restrictions and guidelines were identified that should be added to DDS in order to properly support these features.

    The restrictions include:

    • Writers shall not be created and/or deleted from the time a GROUP Publisher called begin_coherent_changes() to end_coherent_changes()
    • Readers belonging to a subscriber with PRESENTATION access_scope=GROUP must all have the same value for DESTINATION_ORDER, RELIABILITY?, DURABILITY, OWNERSHIP
    • Writers belonging to a Publisher with PRESENTATION access_scope=GROUP should have the same value for OWNERSHIP, DURABILITY, RELIABILITY?, DESTINATION_ORDER?
      • With OWNERSHIP: kind (i.e. all SHARED or all EXCLUSIVE) and in the case they are exclusive all Writers must have value of the the same OWNERSHIP_STRENGTH.
    • All samples in the coherent set should have the same reception_timestamp and source_timestamp:
      • If access_scope = GROUP the reception and source timestamp are equal to that of the EndCoherentChanges sample.
      • If access_scope < GROUP the reception and source timestamp correspond to the ones from the last sample in the coherent set which may or may not be the EndCoherentChanges sample.

    Guidelines:

    • Adding a note for users that it may often be required to change the HISTORY kind/depth from KEEP_LAST,1. This is because a publisher that is quickly publishing coherent sets which update the same instances could very easily invalidate a coherent set that has not been fully delivered to the subscribers. Replacing a sample in history that is part of a coherent set invalidates that coherent set. It may be worth adding a callback that is called when a writer removes a coherent set from its queue
      • In general, writers that are part of a GROUP Publisher should be configured homogeneously.
  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:55 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

Add resource limits related to coherent changes

  • Key: DDS15-239
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    RTPS 2.4 added support for GROUP ordered access and coherent access. It may be useful to consider adding some resource limits specifically associated with coherent sets.
    For example, limiting the maximum number of samples that can be outstanding per DataReader and per Subscriber.

    These resource limits would help to prevent a (potentially ill-intentioned) Writer from filling up the entire reader queue with a never-ending coherent set since the reader must store the coherent set until it is complete.

  • Reported: DDS 1.4 — Fri, 20 Jul 2018 16:58 GMT
  • Updated: Fri, 20 Jul 2018 17:49 GMT

How to handle some GROUP ordered Subcriber scenarios

  • Key: DDS15-237
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    When using a GROUP ordered Subscriber, how do you access the samples in the order in which they are produced? The DDS1.4 specification says the following thing about this:.

    "If the PRESENTATION QosPolicy of the Subscriber to which the DataReader belongs has the access_scope set to ‘GROUP.’ This operation should only be invoked inside a begin_access/end_access block. Otherwise it will return the error PRECONDITION_NOT_MET. Depending on the setting of the PRESENTATION QoS policy (see 2.2.3.6), the returned collection of DataReader objects may be a ‘set’ containing each DataReader at most once in no specified order, or a ‘list’ containing each DataReader one or more times in a specific order.

    1. If PRESENTATION access_scope is INSTANCE or TOPIC the returned collection is a ‘set.’
    2. If PRESENTATION access_scope is GROUP and ordered_access is set to TRUE, then the returned collection is a ‘list.’
      This difference is due to the fact that, in the second situation it is required to access samples belonging to different DataReader objects in a particular order. In this case, the application should process each DataReader in the same order it appears in the ‘list’ and read or take exactly one sample from each DataReader. The patterns that an application should use to access data is fully described in 2.2.2.5.1, Access to the data."

    The big question here is: what happens when the user does not follow this scenario exactly? Here is a couple of potential deviations from the described scenario:

    1. Reading more than one sample from every listed reader (i.e. use read/take with max_samples > 1)
      • We could state that no matter what the size of max_samples is, you get one sample at max.
    2. Reading/Taking samples with different sample/view/instance state masks than passed to the get_datareaders() call.
    3. Reading/Taking samples from a different reader than next one in the reader list.
    4. you invoke get_datareaders() before having fully iterated through the previous reader list.

    We should specify what happens if an application (intentionally or non-intentionally) does not follow the scenario laid out in the spec, or we should come up with an alternative reading mechanism that does not allow you stray off the correct path in these ways for example by introducing new function calls.

  • Reported: DDS 1.4 — Fri, 6 Jul 2018 19:34 GMT
  • Updated: Fri, 6 Jul 2018 19:34 GMT

Request/Offered behavior of DURABILITY Qos does not match use-cases

  • Key: DDS15-236
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DURABILITY Qos is defined as Request/Offered. If a DataWriter offers a kind, the DataReader 'request' kind must be 'less or equal'. Otherwise they will not match, for this comparison it is considered that
    VOLATILE < TRANSIENT_LOCAL < TRANSIENT < PERSISTENT.

    This is not intuitive to users and does not match many of the use-cases observed in practice.

    What users expect is for a DataWriter to configure its durability without impact on the matching (very much like HISTORY). The setting would just control whether the DataWriter keeps a local copy of the data for late joiners and whether it sends the data to the persistence services.

    The reader in the other hand should simple state whether it wants "historical data" meaning data that was published before the reader joined the domain. This could just be a "boolean" or maybe a boolean plus some extra information that controls how much "historical data" to get.

    If the DataWriter enabled durability then it would get the data that the DataWriters have on their "historical cache" that includes data from the Persistence services.

    If a DataWriter set DURABILITY to TRANSIENT or PERSISTENT, then it would send its data to the PERSISTENCE services. It it was 'TRANSIENT LOCAL" then the Persistence service would not match the writer.

    Ideally this could be done as an extension so it has minimal impact in current behavior or interoperabiity

  • Reported: DDS 1.4 — Tue, 27 Mar 2018 20:09 GMT
  • Updated: Tue, 27 Mar 2018 20:09 GMT

Incorporate common elements from DDS Security to the Builtin Topics

  • Key: DDS15-234
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS Security added information to the builtin-topic data.
    Some if this information is generic and not specific to DDS Security. An example of this is DataTags. Even if those are things DDS Security can associate permissions with, the tags themselves are generic and would make sense for any DDS implementation.

    The purpose of this issue is to identify those "generic" additions made by DDS Security and incorporate them to the DDS specification.

  • Reported: DDS 1.4 — Wed, 7 Mar 2018 19:02 GMT
  • Updated: Wed, 7 Mar 2018 19:02 GMT

Add DataTagQosPolicy

  • Key: DDS15-208
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS Security specification (see 7.2.5) added a DataTagQosPolicy defined as:

    @extensibility(APPENDABLE)
    struct Tag {
        string name;
        string value;
    };
    
    typedef sequence<Tag> TagSeq;
    
    @extensibility(APPENDABLE)
    struct DataTags {
        TagSeq tags;
    };
    
    typedef DataTags DataTagQosPolicy
    

    This is actually a generic policy that does not require DDS Security. It makes sense even without security as a way to associate tags with DataWriters and DataReaders.

    Therefore it would be better to move that definition to the DDS specification. This is a user-visible API that is expected to be explicitly set. If it is not part of the DDS API than applications would not be directly portable between DDS and DDS security.

    The spec should also define values for DATATAG_QOS_POLICY_NAME and DATATAG_QOS_POLICY_ID. For example:

     const string DATATAG_QOS_POLICY_NAME = "DataTag";
     const QosPolicyId_t  DATATAG_QOS_POLICY_ID = 25;
    

    Note that currently DDS-XTYPES defines IDs 23 and 24. Probably XTYPES should have used numbers in a different range so the IDs in DDS could remain contiguous.

    See also DDS15-209.

  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:05 GMT
  • Updated: Thu, 18 Jan 2018 23:14 GMT

Define ranges of QosPolicyId_t

  • Key: DDS15-209
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    DDS defines values of QosPolicyId_t from 0 to 22. Other specs (e.g. XTYPES) define additional values (23 and 24) and vendors potentially also define values.

    To avoid confusion and collision DDS should allocate ranges for each of these. For example:
    0-499 for DDS
    500-999 for Other OMG specs
    1000- for vendor extensions.

    If we go with this proposal we need to file an issue with XTYPES to change the policy ID values to to the reserved range for "other specifications"

  • Reported: DDS 1.4 — Thu, 18 Jan 2018 23:13 GMT
  • Updated: Thu, 18 Jan 2018 23:13 GMT

Durability section typos

  • Key: DDS15-207
  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    2.2.3.4 DURABILITY

    paragraph 5: "serviced" should be "service"

    paragraph 8: "data-instances" should be "data-instance"

    item #3: "longer that" should be "longer than"

    last paragraph: "disposition" should be "disposal" or "dispose operation"

  • Reported: DDS 1.4 — Thu, 14 Dec 2017 22:54 GMT
  • Updated: Thu, 14 Dec 2017 22:54 GMT

BuiltinTopicKey_t should be completely customizable.

  • Key: DDS15-206
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The IDL file describing the builtin topics consists of two parts:

    • A section with #define statements where certain datatypes may be customized by the different vendors.
    • A section where these customized datatypes are actually embedded in the builtin topic declarations.

    All builtin topics contain a key field of type BuiltinTopicKey_t that is defined in the following way:

    #define BUILTIN_TOPIC_KEY_TYPE_NATIVE long
    
    module DDS {
        struct BuiltinTopicKey_t {
            BUILTIN_TOPIC_KEY_TYPE_NATIVE value[3];
        };
    };
    

    This implies that vendors may specify part of the key (the array element type), but they may not specify it to be anything else than an array of three of those vendor specific datatypes.

    Right now, different vendors have specified the BuiltinTopicKey_t in various different ways: some uses an array of 16 octets to directly reflect the RTPS GUID, but the official DDS spec does not allow for this.

    In order to allow for these kinds of vendor specific customizations, the entire BuiltinTopicKey_t should be declared as a vendor specific #define statement.

    As some context: this issue was filed in the RTPS RTF working group during the Dec 2017 San Fransisco OMG meeting. Basically the consensus was that indeed the builtin topic key type should be fully customizable. How this is exactly gonna be achieved was left to the DDS RTF working group.

  • Reported: DDS 1.4 — Tue, 5 Dec 2017 19:50 GMT
  • Updated: Wed, 6 Dec 2017 07:00 GMT

Specify behavior of filters and queries relative of lifecycle events

  • Key: DDS15-205
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    How are dispose and unregister samples treated for DataReaders that use a ContentFilteredTopic or a QueryCondition?

    Should these "lifecycle" notification samples pass all filters? Should the "key part" of the filter be considered when propagating these notifications?

  • Reported: DDS 1.4 — Tue, 5 Dec 2017 18:50 GMT
  • Updated: Tue, 5 Dec 2017 18:50 GMT

Add API for "directed writes"

  • Key: DDS15-204
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS-RTPS protocol supports directing samples to a specific DataReader. However there is no way to exercise this feature using standard DDS API.

    The idea is to add an additional operation to the DataWriter allowing the specification of the destination DataReader. This could be a specific write_directed() operation or a more generic write_with_parameters() that allows additional parameters to be specified.

  • Reported: DDS 1.4 — Sat, 2 Dec 2017 00:33 GMT
  • Updated: Sat, 2 Dec 2017 00:34 GMT

Topic Names are Restricted to Characters, Digits, and Hyphens

  • Key: DDS15-203
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    SQL grammar in BNF in clause B.2 limits topic names to the following characters: [A-Za-z0-9\-]+.

    The DDS specification should add support for more characters. Some candidates are "/", ":", ".", "_". The latter is actually used in the DDS-XTYPES as a separator in the mapping of interfaces to request and reply topics.

  • Reported: DDS 1.4 — Tue, 28 Nov 2017 16:13 GMT
  • Updated: Thu, 30 Nov 2017 14:35 GMT

Relationship between begin/end coherent changes and presentation.coherent_access==true

  • Key: DDS15-202
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We observe differences between DDS vendors related to begin/end_coherent_changes and presentation.coherent_access==true. The question is how begin_coherent_changes() should behave when presentation.coherent_access==false. Some vendors are silent and the operation just works, some return a RETCODE_ERROR saying begin_coherent_changes may only be called when presentation.coherent_access==true. To our idea the DDS spec should be precise so that users who separate code and qos (like DDS4CCM) do know what behavior they get

  • Reported: DDS 1.4 — Tue, 28 Mar 2017 15:05 GMT
  • Updated: Fri, 31 Mar 2017 16:55 GMT

No specification for unregister_type for TypeSupport interface

  • Key: DDS15-201
  • Status: open  
  • Source: DSTO ( Michael Mathers)
  • Summary:

    Currently there is no specification on the TypeSupport interface for an unregister_type operation as a companion to the register_type operation. This leads to variation between vendor implementations with respect to the lifecycle of type registrations. In the case of component-based architectural approaches it is desirable to be able to unload components to free resources. With no clear ability to unregister a type, it is not safe to unload component libraries while a container or manager of DDS infrastructure may still hold a reference to a no longer used type.

  • Reported: DDS 1.4 — Sun, 15 Jan 2017 23:13 GMT
  • Updated: Thu, 26 Jan 2017 21:03 GMT

Syntax for Topic Names

  • Key: DDS15-200
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    For portability & interoperability it is necessary to know what the valid syntax of topic names can be, including valid characters. Some vendors support characters like '.' '/', ':' while others don't.

    The spec should make clear which characters are supported by all vendors

    Note that Appendix B does include a TOPICNAME syntax, but this section appears only related to content filters it is not clear if this would limit a Topic name in general. In Appendix B it says:

    TOPICNAME - A topic name is an identifier for a topic, and is defined as any series of characters ‘a’, ..., ‘z’, ‘A’, ..., ‘Z’, ‘0’, ..., ‘9’, ‘-’ but may not start with a digit.

    This seems limiting and also the "-" seems like an odd choice or perhaps a typo. "_" would be a more natural choice...

    Also it seems very restrictive to not allow things like "." or "/" or ":" given that large systems would want to organize their topic names and take advantage of this.

  • Reported: DDS 1.4 — Fri, 21 Oct 2016 14:29 GMT
  • Updated: Fri, 21 Oct 2016 14:37 GMT

Add a write_sequence() operation to DataWriter

  • Key: DDS15-198
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The DDS PIM DataReader read/take operations return a sequence. However there is no similar operation on the DataWriter.

    This makes the API non-symmetric.

    In fact the new DDS C++ PSM added a write() operation that takes a forward iterator. Which now is only available in this PSM and not the others.

    This operation should be added to the PIM as it is a generic capability that should be available on all PSMs.

  • Reported: DDS 1.4 — Fri, 1 Jul 2016 01:12 GMT
  • Updated: Fri, 1 Jul 2016 01:12 GMT

Clarify RxO behavior for DURABILITY Qos

  • Key: DDS15-196
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    This issue was reported by email by Virginie Watine from THALES.

    Assume a DW is TRANSIENT and a DR is VOLATILE.
    According to the RxO policy attached to that QoS, they should match (all the other factors being OK). Is it correct?
    (at least that is what the spec says)

    But what are the first samples that are provided to the DR? I assume it receives only the ones that are produced after its creation (as opposed to a DR with TRANSIENT which receives also the ones that have been produced before its creation). Is it correct?
    (that point is not explained in the spec – or at least is not easy to find)

  • Reported: DDS 1.4 — Thu, 31 Mar 2016 18:04 GMT
  • Updated: Thu, 31 Mar 2016 18:07 GMT

Specify Publishers with PRESENTATION access_scope GROUP should use same order for DataWriters

  • Key: DDS15-190
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    When PRESENTATION access_scope is GROUP samples need to e ordered across DataWriters. This is very hard/impossible if some writers use source_timestamp and others reception timestamp order

    Propose that this is not allowed. If PRESENTATION access_scope is GROUP then all writers must have same ORDER. E.g. as writers are created if one is not consistent it should give an error

  • Reported: DDS 1.4 — Tue, 15 Mar 2016 14:11 GMT
  • Updated: Tue, 15 Mar 2016 14:11 GMT

All IDL should use local interfaces

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

    DDS uses IDL and defines its interface as regular interfaces, but these should all be local interfaces

  • Reported: DDS 1.4 — Thu, 13 Jan 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Durability Implementation Description does not consider the role of partitions

  • Key: DDS15-187
  • Legacy Issue Number: 19649
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The third paragraph of the DURABILITY section (2.1.3.4) describes the semantics that has to be provided by a durability service for TRANSIENT and PERSISTENT topics. Specifically, it states that given a Topic T with DURABILITY QoS set to TRANSIENT or PERSISTENT then the "built-in fictitious" DataReader and DataWriter used by the Durability Service to receive/distribute data have to be created with the same QoS T. Yet, nothing is said with respect to the role of the PARTITION QoS. Section 2.1.3.13 clearly states that:

    "For a DataReader to see the changes made to an instance by a DataWriter, not only the Topic must match, but also they must share a common partition."

    Thus based on the current specification the Durability Service DataReader and DataWriter would only match the applications DataReader and DataWriter that are in the default partition.

  • Reported: DDS 1.4 — Wed, 29 Oct 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT