${taskforce.name} Avatar
  1. OMG Task Force

DDS Interoperability FTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP2-28 Add Parameter ID for Original Writer Info DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-27 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-5 Clarify Writer liveliness mechanism DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-4 Change structure of (Nokey)DataFrag DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-7 Add SerializedDataFragment as Submessage Element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-6 Version number should be 2.0 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-3 Remove length field in encapsulation chapter DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-2 Provide default timing parameters DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-25 DDS DURABILITY Persistent QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-24 ChangeKind Has DDS Relationship DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-23 Clarify GAP usage DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-26 TOPICNAME parameter appears in PSM but not in PIM DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-22 Elaborate on Necessity and Usage of In-line QoS DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-21 Clarify Data Encapsulation Schemes DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-12 Clarify implementing Count submessage element DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-11 Reclaiming finite resources from inactive readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-17 Supporting Inline QoS by Stateful Readers DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-16 Add Directed Write Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-9 Clarify interoperability requirement 8.4.2.3.3 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-8 Clarify interoperability requirement 8.4.2.3.4 DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-15 Interpreting Liveliness Heartbeats DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-14 Clarify Writer Response to ACKNACK DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-20 Add Max Sample Size Serialized Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-19 Add Property List Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-10 Define default multicast Reader behavior DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-13 Reader-side Heartbeat response suppression DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed
DDSIRTP2-18 Add Entity Name Parameter Id DDSI-RTPS 2.0b1 DDSI-RTPS 2.0 Resolved closed

Issues Descriptions

Add Parameter ID for Original Writer Info

  • Legacy Issue Number: 11075
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Add Max Sample Size Serialized Parameter Id

  • Legacy Issue Number: 11074
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Clarify Writer liveliness mechanism

  • Key: DDSIRTP2-5
  • Legacy Issue Number: 11031
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The current Writer liveliness mechanism piggybacks on SPDP messaging. As RTPS should also be able to support other discovery protocols beyond SPDP, including a static configuration, this is not the best approach.
    It is true that all implementations must support at least SPDP, but if a customer wants to disable it (e.g. no need to interoperate with a different vendor so it possible to use a different protocol exclusively), this should not affect the DW liveliness mechanism. To some extent, it does not, but sending SPDPDiscoveredParticipantData to maintain a DWs liveliness is wasteful, especially if SPDP is not even used.
    Resolution:
    Update the Writer liveliness protocol to be independent of Discovery.
    Revised Text:
    Since this change is lengthy, the editorial instructions appear in a blue font to help the reader distinguish them from document content.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the SPDPDiscoveredParticipantData) at a rate faster than the smallest lease duration among the Writers.

    with:

    DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the ParticipantMessageData, see Section 8.4.13.5 for details) at a rate faster than the smallest lease duration among the Writers.

    · Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the SPDPDiscoveredParticipantData) and add the PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT in-line QoS, where the value of the in-line QoS is incremented each time.

    with:

    DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the ParticipantMessageData, see Section 8.4.13.5 for details).

    · Section 8.5.2, change the title from "RTPS built-in Endpoints" to "RTPS built-in Discovery Endpoints"
    · Add the following row to the end of Table 8.50:

    ParticipantMessageData Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.

    · Insert new Section following 8.4.12 (so a new 8.4.13) with the following content:

    8.4.13 Writer Liveliness Protocol
    The DDS specification requires the presence of a liveliness mechanism. RTPS realizes this requirement with the Writer Liveliness Protocol. The Writer Liveliness Protocol defines the required information exchange between two Participants in order to assert the liveliness of Writers contained by the Participant.

    All implementations must support the Writer Liveliness Protocol in order to be interoperable.

    8.4.13.1 General Approach
    The Writer Liveliness Protocol uses pre-defined built-in Endpoints. The use of built-in Endpoints means that once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote participant and establish the association with the locally-matching built-in Endpoints.

    The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.

    8.4.13.2 Built-in Endpoints required by the Writer Liveliness Protocol
    The built-in Endpoints required by the Writer Liveliness Protocol are the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. The names of these Endpoints reflect the fact that they are general-purpose. These Endpoints are used for liveliness but can also be used for other data in the future.

    The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints:
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
    ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER

    The actual value for each of these EntityId_t instances is defined by each PSM.

    8.4.13.3 BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader QoS
    For interoperability, both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader use the following QoS values:
    · reliability.kind = RELIABLE_RELIABILITY_QOS
    · durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS
    · history.kind = KEEP_LAST_HISTORY_QOS
    · history.depth = 1

    8.4.13.4 Data Types associated with the built-in Endpoints used by the Writer Liveliness Protocol

    Each RTPS Endpoint has a HistoryCache that stores changes to the data-objects associated with the Endpoint. This is also true for the RTPS built-in Endpoints. Therefore, each RTPS built-in Endpoint depends on some DataType that represents the logical contents of the data written into its HistoryCache.

    Figure X defines the ParticipantMessageData DataType associated with the RTPS built-in Endpoints for the "DCPSParticipantMessage" Topic.

    Figure X The ParticipantMessageData structure.

    8.4.13.5 Implementing the Writer Liveliness Protocol using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader

    The liveliness of a subset of Writers belonging to a Participant is asserted by writing a sample to the BuiltinParticipantMessageWriter. If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS. Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers. The two instances are orthogonal in purpose so that if a Participant contains Writers of each of the two liveliness kinds described, two separate instances must be periodically written. The instances are distinguished using their DDS key which is comprised of the participantGuidPrefix and the kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.

    In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).

    The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in Section 8.7.2.2.3.

    · Add the following entries to Table 9.2

    BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER =

    {00,02,00,C2}

    BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER =

    {00,02,00,C7}

    · Insert a new Section 9.6.2.1 with the following content:

    9.6.2.1 Data representation for the ParticipantMessageData built-in Endpoints
    The Behavior Module within the PIM (Section 8.4) defines the DataType ParticipantMessageData. This type is the logical content of the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader built-in Endpoints.

    The PSM maps the ParticipantMessageData type into the following IDL:

    struct ParticipantMessageData

    { KeyHashPrefix_t participantGuidPrefix; KeyHashSuffix_t kind; sequence<octet> data; }

    ;

    The DDS key consists of the both the participantGuidPrefix and the kind fields. On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticipantMessageData because they are already explicitly serialized as part of the Data Submessage (see Section 8.3.7.2).

    The following values for the kind field are reserved by RTPS:

    #define PARTICIPANT_MESSAGE_DATA_KIND_UNKNOWN

    {0x00,0x00,0x00,0x00}

    #define PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x01}

    #define PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_LIVELINESS_UPDATE

    {0x00,0x00,0x00,0x02}

    RTPS also reserves for future use all values of the kind field where the most significant bit is not set. Therefore:

    kind.value[0] & 0x80 == 0 // reserved by RTPS
    kind.value[0] & 0x80 == 1 // vendor specific kind

    Implementations can decide the upper length of the data field but must be able to support at least 128 bytes.

    Following the CDR encoding, the wire representation of the ParticipantMessageData structure is:

    0...2...........8...............16.............24...............31
    ------------------------------------------------------+

    unsigned long data.length

    ------------------------------------------------------+

     

    ~ octet[] data.value ~

     

    ------------------------------------------------------+

    · Insert a new Section called 9.6.2.2
    Use the contents of Section 9.6.2 from the start until the beginning of Section 9.6.2.1

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Change structure of (Nokey)DataFrag

  • Key: DDSIRTP2-4
  • Legacy Issue Number: 11030
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    (NOKEY_)DATA_FRAG PSM submessage definition should be modified to place inlineQos AFTER fragmentation related parameters to simplify an implementation based on gather send.
    Resolution:
    Reposition the inlineQos field to be consistent with other messages, implementation simplicity, and higher performance.
    Revised Text:
    · Section 9.4.5.4, change
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+
    to
    0...2...........8...............16..............24..............32
    +

    NOKEY_DATA_FRAG X X X X X X Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+

    · Section 9.4.5.6, change
    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

    ------------------------------------------------------+

    KeyHashSuffix keyHashSuffix

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+

    to

    0...2...........8...............16..............24..............32
    +

    DATA_FRAG X X X X X H Q E octetsToNextHeader

    ------------------------------------------------------+

    EntityId readerId

    ------------------------------------------------------+

    EntityId writerId

    ------------------------------------------------------+

     

    + SequenceNumber writerSN +

     

    ------------------------------------------------------+

     

    + +

    KeyHashPrefix keyHashPrefix [only if H==1]

    + +

     

    ------------------------------------------------------+

    KeyHashSuffix keyHashSuffix

    ------------------------------------------------------+

    FragmentNumber fragmentStartingNum

    ------------------------------------------------------+

    ushort fragmentsInSubmessage ushort fragmentSize

    ------------------------------------------------------+

    unsigned long sampleSize

    ------------------------------------------------------+

     

    ~ ParameterList inlineQos [only if Q==1] ~

     

    ------------------------------------------------------+

     

    ~ SerializedData serializedData ~

     

    ------------------------------------------------------+

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see below

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

Add SerializedDataFragment as Submessage Element

  • Key: DDSIRTP2-7
  • Legacy Issue Number: 11033
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Encapsulation of serialized data should be the responsibility of the plug-in. Even though the protocol does not need to interpret the data stream, in the case of fragmented data, the data encapsulation header need only be pre-pended to the first fragment. Further fragments don't need the encapsulation header.
    Resolution:
    Add a new SubmessageElement subclass called SerializedDataFragment.

    Revised Text:

    Renumber 8.3.5.15 (StatusInfo) to 8.3.5.16, and add new section 8.3.5.15

    8.3.5.15 SerializedDataFragment

    SerializedDataFragment contains the serialized representation of a the value of a data-object that has been fragmented. Like for unfragmented SerializedData, the RTPS protocol does not interpret the fragmented serialized data-stream. Therefore, it is represented as opaque data. For additional information on data encapsulation, see Chapter 10.

    Add table 8.32 - Structure of the SerializedDataFragment SubmessageElement
    field type meaning
    value octet[*] Serialized data-stream fragment

    Replace Figure 8.12 with :

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    for updated figure see page 27 of ptc/2007-06-02

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

Version number should be 2.0

  • Key: DDSIRTP2-6
  • Legacy Issue Number: 11032
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The extensions made to the protocol break backwards compatibility and therefore the major version should be changed not the minor version.
    Resolution:
    Change the version number from 1.2 to 2.0.
    Revised Text:
    Change "1.2" to "2.0" in the following locations:
    · Table 8.13, 5th row (first cell reads "SubmessageKind"), the cell in the second column
    · Section 8.3.3.1.2, first paragraph, first sentence.
    · Section 8.3.4.1, numbered item 3, second sentence

    {note: two occurrences in this sentence}

    · Section 8.3.4.1, numbered item 4, third sentence.
    · Section 8.3.5, first paragraph, second sentence
    · Section 8.3.5.3, second paragraph (right after Table 8.20), first sentence
    · Section 8.3.5.9, within the bulleted items following the second paragraph
    o the second sentence in the second bulleted item
    o the second sentence in the third bulleted item
    · Section 8.3.7, first paragraph, first sentence
    · Section 8.6, first paragraph, first sentence
    · Section 9.3.1.2, last paragraph (right before Table 9.1), second sentence
    · Section 9.3.1.4, the title
    · Section 9.3.1.4, first paragraph, first and second sentences
    · Table 9.3, the caption
    · Section 9.4.2.11, last paragraph, first (and only) sentence
    · Section 9.4.5.1.1, first paragraph, last sentence
    · Section 9.4.5.1.2, last paragraph, first and second sentences
    · Section 9.6.4, the title
    · Section 9.6.4, first paragraph, first and second sentences

    Other changes:
    · Table 8.2, 6th row (cell in first column reads "ProtocolVersion_t"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    o NOTE: there are two instances of this change in this cell.
    · Table 8.16, 2nd row (cell in first column reads "sourceVersion"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.3.3.1.2, change "(major = 1, minor = 2)" to "(major = 2, minor = 0)"
    · Section 8.3.5.3, second paragraph, within the list of special values, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
    · Section 8.6, first paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.2, last paragraph (right before Table 9.1), third sentence, change "(1)" to "(2)"
    · Table 9.4, 5th row (first cell contains "ProtocolVersion_t")
    change:

    #define PROTOCOLVERSION_1_2

    {1,2}
    #define PROTOCOLVERSION {1,2}

    to:

    #define PROTOCOLVERSION_2_0

    {2,0}
    #define PROTOCOLVERSION {2,0}

    also, in the last sentence, change "version 1.2 (major = 1, minor = 2)" to "version 2.0 (major = 2, minor = 0)"
    · Section 8.3.3.1, last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2, last paragraph (following Table 8.15), first (and only) sentence, change "(1)" to "(2)"
    · Section 8.3.3.2.1, second paragraph, first sentence, change "(1)" to "(2)"
    · Section 9.3.1.3, second paragraph, third sentence, change "(1)" to "(2)"
    · Section 9.4.4, second paragraph, change "(1)" to "(2)"
    · Section 9.4.5.1, second to last paragraph, first (and only) sentence, change "(1)" to "(2)"
    · Section 9.4.5.1.1, second paragraph, first sentence, change "(1)" to "(2)"

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Remove length field in encapsulation chapter

  • Key: DDSIRTP2-3
  • Legacy Issue Number: 11029
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The protocol should clarify the sequence number of a writer's first sample. Currently, this is not specified in 8.3.5.4. Rather, it is implied by 8.3.5.5 which states that a sequence number set contains sequence numbers >= 1. The same issue applies for a fragment number.
    Resolution:
    Explicitly state that the sequence number of a writer's first sample or fragment is 1.
    Revised Text:
    · Section 8.3.5.4, first paragraph, append text

    Sequence numbers begin at 1.

    · Section 8.3.5.6, first paragraph, append text

    Fragment numbers begin at 1.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

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

Provide default timing parameters

  • Key: DDSIRTP2-2
  • Legacy Issue Number: 11028
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    For out-of-the-box interoperability, we should provide default timing parameters for the reliability protocol.
    Resolution:
    Provide default timing parameters for the reliability protocol.
    Revised Text:
    · Add a new Section 8.4.7.1.1 titled "Default Timing-RelatedValues" with the following content:

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    nackResponseDelay.sec = 0;
    nackResponseDelay.nanosec = 200 * 1000 * 1000; // 200 milliseconds
    nackSuppressionDuration.sec = 0;
    nackSuppressionDuration.nanosec = 0;

    · Add a new Section 8.4.10.1.1 title "Default Timing-Related Values" with the following content (NOTE: heartbeatSuppressionDuration does not currently exist in RTPS but is added through issue R#7) :

    The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
    heartbeatResponseDelay.sec = 0;
    heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds
    heartbeatSuppressionDuration.sec = 0;
    heartbeatSuppressionDuration.nanosec = 0;

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    No Data Available

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

DDS DURABILITY Persistent QoS

  • Legacy Issue Number: 11053
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

    The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    Resolution:
    Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

    Revised Text:

    Add to table 9.4:

    Type PSM Mapping
    OriginalWriterInfo_t struct

    { GUID_t originalWriterGUID; SequenceNumber_t originalWriterSN; ParameterList originalWriterQos;}

    OriginalWriterInfo;

    Append to table 9.13:
    Name ID Type
    PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

    Add new section:

    8.7.6 Original Writer Info

    A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

    This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

    The RTPS protocol supports this forwarding of messages by including information of the original writer.

    OriginalWriterInfo_t
    attribute type value
    originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
    originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
    originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

    When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

ChangeKind Has DDS Relationship

  • Legacy Issue Number: 11052
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Table 8.5 incorrectly shows a ChangeKind_t as having no applicable relation to DDS. Rather, the instance state kind of being disposed and unregistered are related to ChangeKind_t.

    Resolution:
    Revise table 8.5 to show the relationship between CacheChange kind and DDS instance state kind.

    Revised Text:
    Revise table 8.5:
    Attribute Type Meaning Relation to DDS
    kind ChangeKind_t Identifies the kind of change. See Table 8.2 DDS instance state kind

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify GAP usage

  • Legacy Issue Number: 11051
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Clarify that GAPs should be used only when a sample is not meaningful and not sent in the first place (e.g. filtered out).
    Resolution:
    Clarify GAP usage.

    Revised Text:
    Revise 8.3.7.4.5:

    The RTPS Writer sends the Gap message to the RTPS Reader to communicate that certain sequence numbers are no longer relevant. This is typically caused by the KEEP_LAST setting of the History QoS on the corresponding DDS DataWriter. This is typically caused by Writer-side filtering of the sample (content-filtered topics, time-based filtering). In this scenario, new data-values may replace the old values of the data-objects that were represented by the sequence numbers that appear as irrelevant in the GAP.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

TOPICNAME parameter appears in PSM but not in PIM

  • Legacy Issue Number: 11065
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Reinier Torenbeek)
  • Summary:

    Summary:
    Table 9.13 in section 9.6.3 contains a parameter called PID_TOPIC_NAME as one of the in-line QoS settings. This parameter is not mentioned in the PIM.
    Resolution:
    First extend section 8.7.1 explaining the rationale behind in-line QoS data. This is addressed in OMG issue #11050 already. Then add the TOPICNAME parameter in section 8.7.2.1.
    Revised Text:
    · Section 8.7.2.1, add the following sentence :
    In-line parameters are added to data sub-messages to make them self-describing. In order to achieve self-describing sub-messages, not only the parameters defined in table 8.7.2.1 have to be sent with the sub-message, but also a parameter TOPICNAME. This parameter contains the name of the topic that the sub-message belongs to.

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

    see below

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

Elaborate on Necessity and Usage of In-line QoS

  • Legacy Issue Number: 11050
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage. The specification should elaborate on how in-line QoS are required for stateless implementations.

    Resolution:
    Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

    Revised Text:
    Revise 8.7.1, insert starting as third paragraph:

    A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

    For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS. Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader. Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify Data Encapsulation Schemes

  • Legacy Issue Number: 11049
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Data encapsulation for Serialized Data Fragments needs differentiation from data encapsulation of serialized data. Fragmentation should be done after encapsulation of large serialized data. Rather than having an encapsulation header for each fragment, only a single encapsulation header is needed, as this is used after the sample has been reconstituted from its fragments. The specification of data encapsulation schemes should describe this.

    Also, in Sections 10.1.1-2, the length field of the data encapsulation schemes shown in the submessage diagrams are unnecessary, because the serialized data and fragments already contain sufficient information to determine the length of data. Instead, the field should be designated for data encapsulation scheme-specific options.
    Resolution:
    Replace the length field of the standard data encapsulation schemes with a scheme-specific option field.

    Define fragmentation as happening after encapsulation of a large data sample.

    Revised Text:
    · Section 10.1.1.2
    WAS
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Little Endian) ~

     

    ------------------------------------------------------+

    NOW:
    0...2...........8...............16..............24..............32
    +

    CDR_BE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Big Endian) ~

     

    ------------------------------------------------------+
    Fragmentation is done after encapsulation of large serialized data.

    0...2...........8...............16..............24..............32
    +

    CDR_LE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (CDR Little Endian) ~

     

    ------------------------------------------------------+

    · Section 10.1.1.3
    WAS:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort length

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

    ------------------------------------------------------+

    NOW:
    0...2...........8...............16..............24..............32
    +

    PL_CDR_BE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Big Endian) ~

     

    ------------------------------------------------------+

    0...2...........8...............16..............24..............32
    +

    PL_CDR_LE ushort options

    ------------------------------------------------------+

     

    ~ Serialized Data (ParameterList CDR Little Endian) ~

     

    ------------------------------------------------------+

    Fragmentation is done after encapsulation of large serialized data, so a SerializedDataFragment may contain the encapsulation header of its larger opaque SerializedData sample.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify implementing Count submessage element

  • Legacy Issue Number: 11040
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The use of the count submessage element is not fully explained.

    For heartbeats, the Count element differentiates logical heartbeats, so heartbeats with the same count as a previously received heartbeat can be ignored to prevent triggering duplicate repair sessions. Also, old heartbeats with count less than previously received counts should also be ignored. So, same logical heartbeats must not have the same count, and new heartbeats must have greater counts than older heartbeats.

    The same logic applies to counts of ACKNACKs.

    Resolution:
    Explain proper usage of the count element of Heartbeats and ACKNACKs.

    Revised Text:
    Add new section:

    8.4.14.6 Setting Count of Heartbeats and ACKNACKs
    The count element of Heartbeats differentiates logical heartbeats. A received heartbeat with the same count as a previously received heartbeat can be ignored to prevent triggering a duplicate repair seesion. So, an implementation should ensure same logical heartbeats are tagged with the same count.

    Also, new heartbeats should have counts greater than all older heartbeats. Then, received heartbeats with counts less than or equal to any previously received can be ignored.

    The same logic applies for counts of ACKNACKs: each logical ACKNACK

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Reclaiming finite resources from inactive readers

  • Legacy Issue Number: 11039
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    The specification should describe how finite resources impact reliable communications.

    Writer queue resources should be reclaimed when no remote reader needs the corresponding sample. This means at least samples that have been fully acknowledged may be reclaimed. However they may exist unresponsive readers that are alive but for some reason never acknowledge the writer. To enable a writer to reclaim resources in this case, we define the notion of inactive Readers. If a reader is detected to be unresponsive through some mechanism (for example, when not responding to successive Heartbeats), the reader is deemed inactive. Then, samples that have been fully acknowledged by all active readers may be reclaimed. The writer should continue sending new samples and Heartbeats to inactive readers, but the writer need not hold onto old samples that were not acknowledged by inactive readers. The specification must note that strict reliability is no longer guaranteed when a reader becomes inactive.

    Resolution:
    Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute.

    Revised Text:
    Add new section
    8.4.14.6 Reclaiming Finite Resources from Unresponsive Readers

    An implementation likely has finite resources to work with. For a writer, reclaiming queue resources should happen when all readers have acknowledged a sample in the queue and resource limits dictate that the old sample entry is to be used for a new sample.

    There may be scenarios where an alive reader becomes unresponsive and will never acknowledge the writer. Instead of blocking on the unresponsive reader, the writer should be allowed to deem the reader as 'Inactive' and proceed in updating its queue. The state of a reader is either Active or Inactive. Active readers have sent ACKNACKs that have been recently received. The writer should determine the inactivity of a reader by using a mechanism based on the rate and number of ACKNACKs received. Then samples that have been acknowledged by all active readers can be freed, and the writer can reclaim those resources if necessary. Note that strict reliability is not guaranteed when a reader becomes inactive.

    Add to table 8.59 - RTPS ReaderProxy Attributes
    Attribute Type Meaning Relation to DDS
    isActive bool Specifies whether the remote reader is responsive to the writer. N/A

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Supporting Inline QoS by Stateful Readers

  • Legacy Issue Number: 11045
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Stateful readers should be allowed to rely on cached information propagated by discovery of remote writers. Thus, support for receiving and parsing inline QoS should be optional for stateful readers.

    In the case of mutable QoS, a tradeoff happens, where not parsing these inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery. A stateful implementation may expose this tradeoff to the user: minimize bandwidth usage by not sending mutated inline QoS or avoid this delayed effect of certain mutable QoS for guaranteed semantics.

    Resolution:
    Allow stateful implementations the choice of whether or not to parse inline QoS.

    Revised Text:
    Add as last paragraph of 8.7.1:

    Stateful implementations can ignore inline QoS and rely solely on cached values obtained through discovery in order to improve performance. Note that not parsing inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Add Directed Write Parameter Id

  • Legacy Issue Number: 11044
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A directed write feature for tagging a sample with the GUID of the sample's single intended recipient must be supported with a new parameter Id to allow the GUID to be serialized as an inline parameter.

    Resolution:
    Add a new standard parameter Id, PID_DIRECTED_WRITE, with ID of 0x0057 and type of a sequence of GUIDs.

    Revised Text:
    Add following section:

    8.7.6 Directed Write
    Direct peer-to-peer communications may be enabled within the publish-subscribe framework of DDS by tagging samples with the handles of the intended recipient(s).

    RTPS supports directed writes by using the inline QoS parameter extension mechanism. The serialized information denotes the GUIDs of the targeted readers.

    When a writer sends such a directed sample, only the recipients with the matching parsed GUIDs accept the sample; all others acknowledge but absorb the sample, as if it was a GAP indicating a filtered sample.

    Append to Table 9.13:
    Name ID Type
    PID_DIRECTED_WRITE 0x0057 sequence<GUID_t>

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify interoperability requirement 8.4.2.3.3

  • Key: DDSIRTP2-9
  • Legacy Issue Number: 11037
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    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 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify interoperability requirement 8.4.2.3.4

  • Key: DDSIRTP2-8
  • Legacy Issue Number: 11036
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.3.4 currently states "Readers can only send an ACKNACK Message in response to a HEARTBEAT message." This implies a reader may not poll for samples by unilaterally NACKing. This is true in general: the frequency and bandwidth of NACKs and associated repair messages is well maintained if controlled only by the writer. However, in the case when a Reader first finds out about a remote writer, before it receives any heartbeats, it may optionally send an ACKNACK to notify the writer. This can expedite communications between the new writer/reader pair, as the arrival time of the first heartbeat may be indeterminate.

    The rationale of writer-only control of NACK and associated repair messages should be incThis optimization should be noted within an implementation note.

    Resolution:
    Clarify requirement 8.4.2.3.4 to include the special case of a Reader first discovering a Writer.
    Revised Text:
    · Change the text of Section 8.4.2.3.4 to:

    In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization. Writers are not required to respond to these pre-emptive ACKNACK Messages.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Interpreting Liveliness Heartbeats

  • Legacy Issue Number: 11043
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth 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:

    Revise Table 8.76 with revised transition:

    Transition state event next state
    T2 waiting HEARTBEAT message is received if (HB.FinalFlag==NOT_SET)then must_send_ackelse if (HB.LivelinessFlag == NOT_SET)then may_send_ackelse waiting

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Clarify Writer Response to ACKNACK

  • Legacy Issue Number: 11042
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Requirement 8.4.2.2.4 should be clarified: a writer does not only respond with data or a GAP as stated. Rather, since a writer may have KEEP_LAST semantics and so may not offer the requested sample anymore, it may also respond with a new HB indicating the requested sample is no longer available. This is the mechanism to trigger a reader's onDataLost callback.

    Resolution:
    Clarify 8.4.2.2.4 to include a Writer's response of a HB to an ACKNACK requesting a sample that the writer does not have available.

    Revised Text:
    Revise first paragraph of 8.4.2.2.4:
    When receiving an ACKNACK Message indicating a Reader is missing some data samples, the Writer must respond by either sending the missing data samples, sending a GAP when the sample is not relevant, or sending a Heartbeat when the sample is no longer available.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Add Max Sample Size Serialized Parameter Id

  • Legacy Issue Number: 11048
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

    Resolution:
    Add parameter Id for Type Max Sample Size Serialized

    Revised Text:

    Append to Table 9.11:
    Name ID Type
    PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Add Property List Parameter Id

  • Legacy Issue Number: 11047
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    User definable name-value pairs can serve as a generic and extensible framework for DDS properties. These properties may be serialized in parameter lists and thus need a corresponding unique parameter Id.
    Resolution:
    Add parameter Id for Property List.
    Revised Text:
    Add section:

    8.7.5 Property Lists

    Property lists are lists of user-definable properties applied to a DDS Entity. An entry in the list is a generic name-value pair. A user defines a pair to be a property for a DDS Participant, DataWriter, or DataReader. This extensible list enables non-DDS specified properties to be applied.

    The RTPS protocol supports Property lists as inline parameters. Properties can then be propagated during discovery or as inline QoS.

    Append to Table 9.4:

    Type PSM Mapping
    Property_t struct

    { string name; string value;}

    Property_t

    Append to Table 9.11
    Name ID Type
    PID_PROPERTY_LIST 0x0059 sequence<Property_t>

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Define default multicast Reader behavior

  • Legacy Issue Number: 11038
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth Brophy)
  • Summary:

    Source:
    Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
    Summary:
    Currently, the specification does not state whether a multicast DataReader must also have a unicast locator or not.
    Resolution:
    A unicast locator should be supplied for multicast DataReaders so that repair sessions can be sent over unicast. If one is not provided directly, then the Participant's locator can be assumed.

    Revised Text:
    Revise following entry in Table 8.77 - RTPS SPDPdiscoveredParticipantData attributes:

    attribute type meaning
    defaultUnicastLocatorList Locator_t[1..*] Default list of unicast locators (transport, address, port combinations) that can be used to send messages to the user-defined Endpoints contained in the Participant.These are the unicast locators that will be used in case the Endpoint does not specify its own set of Locators, so at least one Locator must be present.

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Reader-side Heartbeat response suppression

  • Legacy Issue Number: 11041
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth 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:

    Revised table 8.66

    Attribute Type Meaning Relation to DDS
    heartbeatSuppressionDuration Duration_t Protocol tuning parameter that allows the RTPS Reader to ignore heartbeats that arrive 'too soon' after a previous heartbeat was received. N/A

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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

Add Entity Name Parameter Id

  • Legacy Issue Number: 11046
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Kenneth 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 0x0058 EntityName_t

  • Reported: DDSI-RTPS 2.0b1 — Wed, 23 May 2007 04:00 GMT
  • Disposition: Resolved — DDSI-RTPS 2.0
  • Disposition Summary:

    see above

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