DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Closed Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 23
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP22-24 Section: 10.1.1.2, 10.1.1.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-23 Section: 10.1.1.1 and 10.1.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-22 Section: 10.1.1.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-21 Section: 10.1 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-20 Section: 9.6.3.3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-19 Section: 9.4.5.1.3, Paragraph 3 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-18 Section: 9.4.2.6 and 9.4.2.8 (last lines of each section) DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-17 Section: 9.3.2, Table 9.4 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-16 Section: 9.3.1.3, Table 9.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-15 Section: 9.3.1.2 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-14 Section: 8.7.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-13 Section: 8.7.7 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-12 Section: 8.4.1.1, Item 16 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-11 Section: 8.4.1.1, Figure 8.14 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-10 Section: 8.3.7.3.5 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-9 Section: 8.3.5.8 DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-8 Section: 8.2.1.2, Table 8.2, Locator_t row DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-7 Use compliant OMG IDL syntax DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-6 Typographical errors DDSI-RTPS 2.0 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-5 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-4 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-3 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed
DDSIRTP22-2 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.2 Resolved closed

Issues Descriptions

Section: 10.1.1.2, 10.1.1.3

  • Legacy Issue Number: 16989
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 194-195
    Change: Remove the paragraphs starting "In addition to, …" since its only purpose is to describe a non-existent length field.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Do as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1 and 10.1.1.2

  • Legacy Issue Number: 16988
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 194-196
    Change: In Table 10.1 and all examples, all Identifiers should be shown as

    {0x00, 0x0?}

    to indicate that they are two-element arrays. Showing it as a single two-byte value could lead to confusion about endianness.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    replace as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1.1.1

  • Legacy Issue Number: 16987
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 193
    Change: This section should define the "options" field which is subsequently referenced.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This is resolved as part of resolving 16989
    Revised Text:
    Disposition: NoChange (Merged)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.1

  • Legacy Issue Number: 16986
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 193
    Change: Delete the last sentence of paragraph 2, the concept of a DDS "type-plugin" is not defined.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This was already addressed as part of Issue 16955
    Revised Text:
    Disposition: NoChange (Merged)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.6.3.3

  • Legacy Issue Number: 16985
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 192
    Change: The "register" Lifecycle operation is not discussed, should it be indicated with a zero value for StatusInfo_t? This should be explicit in the spec.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The ‘register” operation is currently described as a local operation on the writer side
    and there is nothing in the specification requiring or preventing it from being
    propagated. From the reader perspective the registration will occur automatically the
    first time data is received for a particular instance.
    Most implementations do not propagate registrations, but in case some
    implementation chooses to do that we should clarify what the StatusInfo_t flags that
    would be associated with the submessage.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.5.1.3, Paragraph 3

  • Legacy Issue Number: 16977
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 169
    Change: This section refers to submessages larger than 64KB, which is impossible with UDP/IP.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No change: It is true that this is not needed for the UDP/IP PSM, but it is something
    that would be useful in other PSMs. By leaving it here it becomes possible to have
    the other PSMs refer to this section verbatim without having to add or modify the text.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.4.2.6 and 9.4.2.8 (last lines of each section)

  • Legacy Issue Number: 16976
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 163
    Change: The phase "does not follow strict CDR encoding" depends on an unspecified notion of "strict" vs. "nonstrict" CDR encoding where in actuality there is no such distinction. Remove the word "strict" to note that the wire representation is not following CDR rules. (This applies to both 9.4.2.6 and 9.4.2.8.)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    see revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.2, Table 9.4

  • Legacy Issue Number: 16975
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 153
    Change: In NTP, TIME_ZERO represents a point in time in 1900. If this was followed by RTPS with its 31-bit field for positive seconds, the maximum point in time would be in 1968, long before RTPS was invented. Therefore the meaning of TIME_ZERO must be specified here. Additionally, leaving only 31 bits for positive seconds and assuming 1970 is used as TIME_ZERO, RTPS times are only valid through 2038. Is there a need for a sign bit in “seconds”?

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The format used is similar to NTP in that is uses seconds and fractions of a second
    (to make arithmetic simple) rather than seconds and nanoseconds. However it uses
    a signed seconds such that signed arithmetic can be applied.
    For these reasons and to facilitate conversion to operating system times (timeval and
    timespec) the time origin TIME_ZERO is defined to be the Unix prime epoch 0h, 1
    January 1970

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.3, Table 9.2

  • Legacy Issue Number: 16974
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 151-152
    Change: All EntityId_t values should be shown with braces for the embedded array (see previous note)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.3.1.2

  • Legacy Issue Number: 16973
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 150
    Change: ENTITYID_UNKNOWN is missing a level of braces to represent the embedded array inside the struct: {

    {0, 0, 0}

    , 0 }

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.8

  • Legacy Issue Number: 16972
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 146
    Change: Change "Persistent" level of DDS Durability to "Transient or Persistent levels" since due to DDS (v1.2 section 7.1.3.4) they both behave the same for the purpose of Original Writer Info.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.7.7

  • Legacy Issue Number: 16971
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 146
    Change: There is no such "property list" feature in the DDS spec, this section should be removed.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    There is an issue filed against the DDS spec to add these lists so once it is resolved
    this will no longer be an issue
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Item 16

  • Legacy Issue Number: 16962
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 65
    Change: DDS has no "finish" operation on DataReader

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.4.1.1, Figure 8.14

  • Legacy Issue Number: 16961
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 64
    Change: DDS has no "finish" operation on DataReader

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    The operation should be called “return_loan”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.7.3.5

  • Legacy Issue Number: 16960
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 52
    Change: Add parentheses around the subexpression: "(dataSize % fragmentSize) ? 1 : 0"

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept suggested change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.5.8

  • Legacy Issue Number: 16959
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 40
    Change: Time_t is underspecified. What real-world time does 0 represent?

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    No Change for this issue. Resolve as part of resolving 16975
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2.1.2, Table 8.2, Locator_t row

  • Legacy Issue Number: 16958
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Page: 14
    Change: discriminator and port number using 4 octets each (insert the word “each”)

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Accept as submitted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use compliant OMG IDL syntax

  • Legacy Issue Number: 16956
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    IDL is defined by OMG’s own document formal/2011-11-01 in section 7. As another OMG specification (and most importantly, for clarity and precision), the current pseudo-IDL throughout the RTPS document must be changed to be actual compliant IDL. Compliant IDL does not use anonymous types: newly-constructed types appear in their own typedefs.
    Section: 9.2.2
    Page: 149
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t

    { OctetArray3 entityKey; octet entityKind; };

    Section: 9.3.1.1
    Page: 150
    Change: replace IDL with
    typedef octet GuidPrefix_t[12];

    Section: 9.3.1.2
    Page: 150
    Change: replace IDL with
    typedef octet OctetArray3[3];
    struct EntityId_t { OctetArray3 entityKey; octet entityKind; }

    ;

    Section: 9.3.1.5
    Page: 153
    Change: replace IDL with
    struct GUID_t

    { GuidPrefix_t guidPrefix; EntityId_t entityId; }

    ;

    Section: 9.3.2, Table 9.4 row “Time_t”
    Page: 153
    Change: replace IDL with
    struct Time_t

    { long seconds; unsigned long fraction; }

    ;

    Section: 9.3.2, Table 9.4 row “VendorId_t”
    Page: 153
    Change: replace IDL with
    typedef octet OctetArray2[2];
    struct VendorId_t

    { OctetArray2 vendorId; }

    ;

    Section: 9.3.2, Tables 9.4 and 9.5
    Page: 154-159
    Change: For ALL table entries with a struct move struct's identifier to directly follow the keyword "struct" (SequenceNumber_t, FragmentNumber_t, Locator_t, Count_t, ProtocolVersion_t, KeyHash_t, StatusInfo_t, ParameterId_t, ContentFilterProperty_t, ContentFilterInfo_t, OriginalWriterInfo_t, LocatorUDPv4_t) and in cases where "typedef" is used to introduce a struct, remove it (ProtocolVersion_t, ContentFilterProperty_t, ContentFilterInfo_t)
    Section: 9.3.2, Table 9.4
    Page: 155-157
    Change: Use of anonymous types is deprecated (applies to Locator_t::address, KeyHash_t::value, StatusInfo_t::value, all fields in ContentFilterProperty_t except for filterExpression). Replace the anonymous type with a typedef.
    Section: 9.3.2, Table 9.4
    Page: 157
    Change: Array bounds for FilterSignature_t must be at the end of the typedef
    Section: 9.4.2.6
    Page: 161
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.8
    Page: 163
    Change: IDL syntax error due to use of anonymous types and the struct’s identifier must directly follow the keyword “struct”; also use unsigned long for bitmap
    Section: 9.4.2.11
    Page: 165
    Change: Use an unsigned short for “length” and mark this as "pseudo" IDL as there is no way to represent a sequence with a 2-byte length field or an array with runtime-determined bounds
    Section: 9.4.5.1
    Page: 168
    Change: struct’s identifier must directly follow the keyword “struct”
    Section: 9.6.2.1
    Page: 180
    Change: IDL syntax error due to use of anonymous types
    Section: 9.6.2.2
    Page: 181
    Change: IDL syntax error, the keyword "struct" is not used to identify types of fields. Also, IDL does not allow differences only in case so "WriterProxy writerProxy;" is ill-formed.
    Section: 10.1.1.1
    Page: 193
    Change: IDL syntax error, array bounds for Identifier must be at the end of the typedef, and the typedef keyword is missing.

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    In addition to making the IDL compliant, the reference to formal/2011-11-01 should
    added to the normative section.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical errors

  • Legacy Issue Number: 16953
  • Status: closed  
  • Source: OCI ( Adam Mitz)
  • Summary:

    Section: 8.3.7.6.5
    Page: 56
    Change: In the expressions for reader and writer GUID, replace Heartbeat with HeartbeatFrag

    Section: 8.3.7.9.6
    Page: 59
    Change: InfoTimestamp should be section 8.3.7.10, not 8.3.7.9.6 which makes it a part of the InfoSource submessage
    Section: 8.4.7.5.1
    Page: 81
    Change: pseudocode line "IF ( DDS_FILTER"… is missing a ")" before "THEN"

    Section: 8.4.13.2, Pgh 1, line 2
    Page: 118
    Change: "Endpoinst" should be "Endpoints"

    Section: 8.4.13.5
    Page: 119
    Change: "ome" should be "one"

    Section: 8.4.14.1.4, last bullet
    Page: 121
    Change: "of" should be "or"

    Section: 8.4.15.7
    Page: 123
    Change: "sample logical" should be "same logical"

    Section: 8.7.1
    Page: 140
    Change: "WoS" should be "QoS"

    Section: 8.7.4
    Page: 145
    Change: "Submessges" should be "Submessages", "PIM" should be "PSM", "teh" should be "the", "Data_Object" should be "Data-Object"
    Section: 9.4.2.6
    Page: 162
    Change: A stray digit "1" appears to the left of expression that starts "(bitmap[deltaN/32]...". Also, parentheses are unbalanced in this expression: there must be one additional ")" before the "=="
    Section: 9.4.5.3.3, Paragraph 3
    Page: 171
    Change: Replace "skip any submessage headers" with "skip any submessage elements". Replace "fule" with "rule". Replace "the received will" with "the receiver will".
    Section: 9.6.2.1
    Page: 180
    Change: replace "tpe" with "type"

    Section: 9.6.2.2, Paragraph 6
    Page: 181
    Change: replace "teh" with "the"

    Section: 9.6.2.2.2, Table 9.12
    Page: 183
    Change: for consistency replace "0x001A" with "0x001a"

    Section: 9.6.3.3
    Page: 191
    Change: the paragraph that starts with "\Note" has a stray backslash

  • Reported: DDSI-RTPS 2.0 — Tue, 27 Dec 2011 05:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    Correction of the typographical errors

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add Entity Name Parameter Id

  • Legacy Issue Number: 11073
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
    Resolution:
    Add parameter Id for Entity Name.
    Revised Text:

    Type PSM Mapping
    EntityName_t struct

    { string name;}

    EntityName_t

    Append to Table 9.11:
    Name ID Type
    PID_ENTITY_NAME 0x0062 EntityName_t

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved the suggested changes are already in the spec.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpreting Liveliness Heartbeats

  • Legacy Issue Number: 11072
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

    Resolution:
    A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

    Revised Text:
    Append to 8.4.2.3.2:

    The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

    Revise statechart 8.24:

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11043. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reader-side Heartbeat response suppression

  • Legacy Issue Number: 11071
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

    Resolution:
    Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

    Revised Text:
    Revised figure 8.21:

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11041. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.
    Revised Text:
    Disposition: NoChange

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify interoperability requirement 8.4.2.3.3

  • Legacy Issue Number: 11070
  • Status: closed  
  • Source: Real-Time Innovations ( Ken Brophy)
  • Summary:

    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
    Resolution:
    Allow Writer to reclaim resources and send repairs if possible.
    Revised Text:
    Add the paragraph to the end of Section 8.4.2.3.3:

    Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.

  • Reported: DDSI-RTPS 2.0b1 — Fri, 25 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.2
  • Disposition Summary:

    This issue was already resolved as part of the FTF, in that report it is labeled as
    issue 11037. It appears that a typographical mistake was made in the report (or else
    something changed in the database) so that the issue was not closed in the OMG
    database.

  • Updated: Fri, 6 Mar 2015 20:58 GMT