Issue 11035: Must send GAP when filtering on writer-side
Issue 11070: Clarify interoperability requirement 8.4.2.3.3
Issue 11071: Reader-side Heartbeat response suppression
Issue 11072: Interpreting Liveliness Heartbeats
Issue 11073: Add Entity Name Parameter Id
Issue 15885: RTF needs to agree any chnage of name and/or URL for specification
Issue 15912: DDSI/RTPS Key MD5 Hash
Issue 16099: How should interoperable implementations deal with Transient / Persistent data."
Issue 16100: How should interoperable implementations deal with Group Coherent updates
Issue 16558: Key attributes and Regular attributes of a topic should be individually de-serializable
Issue 16953: Typographical errors
Issue 16954: Remove the concept of Topic Kinds (With Key vs. No Key)
Issue 16955: Use the term "Encapsulation" consistently and precisely
Issue 16956: Use compliant OMG IDL syntax
Issue 16957: Editing issues
Issue 16958: Section: 8.2.1.2, Table 8.2, Locator_t row
Issue 16959: Section: 8.3.5.8
Issue 16960: Section: 8.3.7.3.5
Issue 16961: Section: 8.4.1.1, Figure 8.14
Issue 16962: Section: 8.4.1.1, Item 16
Issue 16963: Section: 8.4.7.3, Table 8.52
Issue 16964: Section: 8.4.8.1.4
Issue 16965: Section: 8.4.9.1.4
Issue 16966: Section: 8.4.14.1.1, Bullet 3
Issue 16967: Section: 8.4.15.7
Issue 16968: Section: 8.5.3.2, Figure 8.27 and Table 8.73
Issue 16969: Section: 8.5.3.2, Table 8.73
Issue 16970: Section: 8.7.6
Issue 16971: Section: 8.7.7
Issue 16972: Section: 8.7.8
Issue 16973: Section: 9.3.1.2
Issue 16974: Section: 9.3.1.3, Table 9.2
Issue 16975: Section: 9.3.2, Table 9.4
Issue 16976: Section: 9.4.2.6 and 9.4.2.8 (last lines of each section)
Issue 16977: Section: 9.4.5.1.3, Paragraph 3
Issue 16978: Section: 9.6.2.2
Issue 16979: Section: 9.6.2.2
Issue 16980: Section: 9.6.2.2
Issue 16981: Section: 9.6.2.2.2, Table 9.12
Issue 16982: Section: 9.6.2.2.2, Table 9.12
Issue 16983: Section: 9.6.2.2.2, Table 9.13
Issue 16984: Section: 9.6.2.2.2, Table 9.13
Issue 16985: Section: 9.6.3.3
Issue 16986: Section: 10.1
Issue 16987: Section: 10.1.1.1
Issue 16988: Section: 10.1.1.1 and 10.1.1.2
Issue 16989: Section: 10.1.1.2, 10.1.1.3
Issue 17285: The Writer Liveliness Protocol should be removed
Issue 17286: Message Size should be included as part of DDSI/RTPS Messages
Issue 11035: Must send GAP when filtering on writer-side (data-distribution-interop-rtf)
Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:
Title: Must send GAP when filtering on writer-side regardless of reliability QoS setting
Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
This issue is not currently in a state to be resolved. What follows are various thoughts on the issue and possible solutions to be discussed. This issue will not be resolved in time for the finalization task force and is included here to be documented for the revision task force.
Discussion topic: what are DDS semantics for combining filtering with the deadline QoS?
Should the deadline be triggered when all samples during the deadline period were filtered out?
That is, does deadline require at least one sample to arrive every deadline period seconds that passed the filter?
Or is the deadline satisfied when any sample arrives within the period, whether filtered out or not?
If deadline only applies to samples that pass the filter, RTPS needs no changes, simply use the GAP subMessage to avoid incorrect onDataLost callbacks.
If not, we run into a problem when using keyed DataWriters and finite deadlines. As the deadline applies on a per instance basis, the Reader expects at least one update for every instance, even when none of the updates for a particular instance pass the filter. A GAP message does not indicate for which instance an update was filtered out, so it cannot be used by the Reader to verify the deadline constraint. Instead, we should consider using an empty DATA message instead, possibly with a flag that states the update did not pass any filter. This would also be useful to add a new instance state NOT_ALIVE_FILTERED or so later on to the DDS spec.
Another possibility would be to add a list of KeyHashes to the GAP message. SO that a GAP that is caused by a CFT actually encodes the instances that are being gapped. This would not cause incorrect firings of the DEADLINE and as a result would maintain ownership of instances even if they are filtered out…
There are two ways to do this.
Either we separate GAPs that correspond to filtered samples from those that correspond to irrelevant samples. So in effect we have two kinds of GAP messages
Or we list explicitly the sequence number of each filtered message along with its KeyHash.
Not clear what would be easier implementationwise. The samples that have been filtered are still on the writer so it appears that either implementation would work.
Option (1) would save putting the sequence number with each KeyHash. This can be 4 or 8 bytes per instance, depending on whether we put the sequence number as is, or we encode it as an increment
Option (2) would cause additional GAP submessages to be sent which is an overhead of 28 bytes. Not clear what is less costly…
Also, if we use Option(1), then the messages that represent real GAPs can be sent via multicast; but this is only likely to occur when late joiners appear as normally there would be no "irrelevant" gaps if data is published immediately. Moreover we can in practice still do this and separate the GAP messages that represent real GAPs from the ones that don't. Option 1 does not force us to combine, just provides the means to do so…
Option (2) has the problem that in certain edge cases the overhead is significant. For example if each we have a irrelevant-sample GAP followed by a filtered sample, followed by an irrelevant sample gap, etc. then we end up sending one GAP message per filtered sample with is 28 bytes of overhead per filtered sample versus a single GAP with 4 bytes of overhead per filtered sample. Also the processing is much more efficient as each GAP message is dispatched separately up the receiver's stack.
For this reason it appears that Option 1 is more flexible, and the overhead is more stable. Opt
Proposal(s):
Always send GAPs for filtered-out messages (both in the BestEffort and in the RELIABLE) cases
If the type is Keyed, then the GAP also includes at the end a sequence of :
struct FilteredSampleDesc {
long gapStartOffset;
KeyHashPrefix keyHashPrefix;
KeyHashSuffic keyHashSuffix;
};
The GAP message gets two additional flags:
KeyHashFlag
indicates the presence of the KeyHashPrefix
FilteredSamplesFlag
Indicates the presence of the sequence< FilteredSampleDesc>
An issue needs to be filed against the DDS spec to clarify:
(a) Whether the deadline as specified by a DataReader should apply to the samples that pass the DataReader filter or to the samples sent by any writer?
(b) Whether a new instance_state ALIVE_FILTERED should be added such that the DataReader can determine that a sample was filtered and potentially take action on that.
(c) Whether an API or a QoS should be added to the DataReader to allow the DataReader to remove the instance information for instances with state ALIVE_FILTERED after all samples are taken. This allows resources to be conserved in the case where once filtered we expect the instance to remain filtered and also allows a reader to be notified if the instance becomes unfiltered.
(d) Weather to add a filtered_generation_count that the instance has becomed ALIVE after being in the ALIVE_FILTERED
Resolution:
T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
Revised Text:
Proposal(s):
Always send GAPs for filtered-out messages (both in the BestEffort and in the RELIABLE) cases
If the type is Keyed, then the GAP also includes at the end a sequence of :
struct FilteredSampleDesc {
long gapStartOffset;
KeyHashPrefix keyHashPrefix;
KeyHashSuffic keyHashSuffix;
};
The GAP message gets two additional flags:
KeyHashFlag
indicates the presence of the KeyHashPrefix
FilteredSamplesFlag
Indicates the presence of the sequence< FilteredSampleDesc>
An issue needs to be filed against the DDS spec to clarify:
(a) Whether the deadline as specified by a DataReader should apply to the samples that pass the DataReader filter or to the samples sent by any writer?
(b) Whether a new instance_state ALIVE_FILTERED should be added such that the DataReader can determine that a sample was filtered and potentially take action on that.
(c) Whether an API or a QoS should be added to the DataReader to allow the DataReader to remove the instance information for instances with state ALIVE_FILTERED after all samples are taken. This allows resources to be conserved in the case where once filtered we expect the instance to remain filtered and also allows a reader to be notified if the instance becomes unfiltered.
(d) Weather to add a filtered_generation_count that the instance has becomed ALIVE after being in the ALIVE_FILTERED
Resolution:
T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
Resolution:
This issue cannot be resolved until the DDS specification defines what the correct behavior is for readers that use both content-filtered topics and a deadline.
The proposal is to leave this issue unresolved for now until the DDS specification clarifies the semantics of the deadline.
The opinion of this RTF task force is that a content filter prevents non-matching data from arriving in the datareader and a deadline applies to a datareader. Therefore deadline only applies to samples that pass the filter. When read- and/or query conditions are used instead of content filters, data always arrives at the datareader and deadline applies to all samples.
Revised Text:
Proposed Disposition: Deferred
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.
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:
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:
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
The DDS interoperability protocol is also referred to as RTPS. OMG staff have received conflicting suggestions for the short name of the protocol (RTPS vs. DDSI). This short name determines (amongst other things) the URL by which the mist recent version of the specification is always accessible. The RTF must decide what short name to use for this specification.
In section 8.7.9 of the DDSI/RTPS v2.1 protocol is described the KeyHash sub-message-element representing the MD5 hash of the key for the Data sub-message to which it belongs. The specification does not mandate the use of the KeyHash all keyed topics -- implementations are free to include it or not. However, if implementations are not including the KeyHash the only way to get a clue on the Topic Instance to which the received samples belongs is to de-serialize the payload. This leads two at least two problems, (1) DDSI/RTPS routers are forced to de-serialize the data payload even if no content transformation have to be performed and (2) DDS Implementations are forced to deserialize eagerly in order to manage instances, thus preventing DDS implementations to do lazy deserialization (which is now possible with the API provided by the new C++/Java PSM). The suggested resolution is to require that Data SubMessage for keyed topic shall always include the KeyHash submessage element.
The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Transient / Persistent data."
The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Group Coherent updates
Key attributes and Regular attributes of a topic should be individually de-serializable (or at least make the keyhash compulsory) [Nature] Architectural [Severity] Major [Description] The "DDS Interoperability Wire Protocol v2.1" defines a a serialization format for topic types in which it is not easy, nor efficient, to simply get access to the key of a given topic. This has to do with how CDR serializes structs but could be worked around with the new X-Types specification. In essence the problem is that some applications such as DDS routers (such as the PrismTech BlendBox) require to perform some operations that while requiring a knowledge of the instance do not require the deserialization of the data payload. [Resolution] For DDS implementation compatible with the X-Types ensure that the regular data attributes and the key attributes are serialized in different chunks and thus individually accessible in an efficient manner -- meaning to access the key I would prefer not to scan all the regular attributes. For non X-Types compatible DDS implementations make the KeyHash compulsory, meaning require DDS compliant implementation to always send a key-hash along with a Data submessage.
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
This distinction is important for DDS, but not relevant for RTPS. There are places where RTPS deals with the Key as an independent unit of data (KeyFlag, etc.), but those are not relevant to the TopicKind_t which seems to be an artifact of an older version of the specification. The current protocol as written in this specification works the same way for both With Key and No Key topics. This issue seeks to remove the Topic Kind concept entirely from the specification. Section: 8.2.1.2, Table 8.2 Page: 14 Change: remove the table row for TopicKind_t Section: 8.2.1.3, Figure 8.2 Page: 16 Change: remove the topicKind attribute in Endpoint Section: 8.2.5, Figure 8.5 Page: 21 Change: remove the topicKind attribute in Endpoint Section: 8.2.6, Table 8.9 Page: 23 Change: remove the table row for TopicKind_t Section: 8.2.9.1, Figure 8.6 Page: 25 Change: remove the if() statements for W::topicKind Section: 8.2.9.1.3-4 Page: 26-27 Change: remove the if() statements for the_rtps_writer.topicKind and the paragraphs “This operation has no effect if the topicKind==NO_KEY).” Section: 8.3.3, Figure 8.8 Page: 31 Change: remove NoKeyData and NoKeyDataFrag Section: 8.3.7, Bullets 1-2,4 Page: 43 Change: remove the text “(NO_KEY Reader/Writer or WITH_KEY Reader/Writer)” Section: 8.3.7.2 Page: 47 Change: remove the text “(NO_KEY or WITH_KEY)” Section: 8.3.7.3 Page: 49 Change: remove the text “(NO_KEY or WITH_KEY)” Section: 8.3.7.2, 3rd Bullet Page: 63 Change: remove the text referring to “keyed topics” Section: 8.4.4 Page: 69-70 Change: remove all references to topicKind, WITH_KEY, NO_KEY, etc. Section: 8.4.7.1, Figure 8.15 Page: 72 Change: remove the topicKind attribute in Endpoint Section: 8.4.8.1 Page: 83 Change: remove “WITH_KEY” Section: 8.4.8.1, Figure 8.16 Page: 84 Change: remove “WITH_KEY” Section: 8.4.8.2 Page: 85 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.8.2, Figure 8.17 Page: 86 Change: remove “WITH_KEY” Section: 8.4.9.1 Page: 90 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.9.1, Figure 8.18 Page: 90 Change: remove “WITH_KEY” Section: 8.4.9.2 Page: 93 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.9.2, Figure 8.19 Page: 94 Change: remove “WITH_KEY” Section: 8.4.10.1, Figure 8.21 Page: 102 Change: remove the topicKind attribute in Endpoint Section: 8.4.11.1 Page: 109 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.11.1, Figure 8.22 Page: 110 Change: remove “WITH_KEY” Section: 8.4.12.1 Page: 111 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.12.1, Figure 8.23 Page: 111 Change: remove “WITH_KEY” Section: 8.4.12.2 Page: 113 Change: remove “WITH_KEY” and “NO_KEY” Section: 8.4.12.3, Figure 8.25 Page: 117 Change: remove “NOKEYDATA” alternative Section: 8.5.3.3, Tables 8.74 and 8.75 Page: 129 Change: remove topicKind rows from both tables Section: 9.3.2, Table 9.4 Page: 155 Change: remove the “TopicKind_t” row
Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of “encapsulation” in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of “encoding” in place of “encapsulation.” Section: 8.3.2, Table 8.13, Count_t row Page: 30 Change: replace “encapsulate” with “encode” Section: 8.3.3.2, Table 8.15, flags row Page: 34 Change: replace “encapsulate” with “encode” Section: 8.3.5.1 Page: 37 Change: replace “encapsulate” with “encode” Section: 8.3.5.9, Paragraph 1 Page: 41 Change: replace “encapsulate” with “encode”; replace “encapsulation” with “encoding” Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows Page: 59 Change: replace “encapsulate” with “encode”; replace “encapsulated” with “encoded” Section: 8.4.10.3 Page: 105 Change: replace “encapsulated” with “represented” (this use has nothing to do with encoding) Section: 8.5.3.2, Table 8.73, expectesInlineQos row Page: 126 Change: replace “encapsulated” with “encoded” Section: 9.4.2.11, Paragraphs 5, 7, 9 Page: 165 Change: replace “encapsulation” with “encoding”. Note that ParameterList itself is not an encapsulation. When it is used as the data payload for Discovery, it is the encapsulated data. When it is used as inlineQos it is not encapsulated. Each data value in the ParameterList is certainly not a CDR encapsulation. Section: 9.6.2.2, Paragraphs 4-5 Page: 181 Change: replace “encapsulates” with “encodes”; replace “encapsulated” with “encoded” (twice) Section: 9.6.2.2.2 Page: 182 Change: replace “encapsulate” with “encode” Section: 9.6.3 Page: 187 Change: replace “encapsulated” with “encoded” Section: 8.6.3.3 Page: 190-191 Change: replace “encapsulated” with “encoded” (twice); replace “encapsulation” with “encoding” (six times) Section: 10 Page: 193 Change: The introduction to section 10 (before the 10.1 header) should be removed. It adds no useful information and only confuses things with ambiguous use of the "encapsulate" term and the concept of a "type-plugin" which is nowhere to be found in the DDS specification. Since there is no 10.2, the contents of 10.1 can become 10. Regarding just the first sentence, data encapsulation must be part of RTPS or it would not be here, and different DDS implementations would not be able to interoperate.
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.
The following collection of proposed changes represents fixes to problems in the editing of the specification. Section: 3 Page: 1 Change: DDS 1.1 is obsolete; CORBA should be referenced for IDL/CDR; IETF RFCs 1321 and 1305 should be referenced Section: 8.2.4.2, Paragraph 2 Page: 21 Change: First two octets of prefix are fixed due to issue 12509 Section: 8.3.6.3, Bullet 2 and Footnote 2 Page: 43 Change: PROTOCOL_RTPS is not defined by PSM Section: 8.3.7.3.2, Table 8.35 Page: 50 Change: KeyFlag is missing from the table Section: 8.3.7.3.2, Table 8.35 Page: 51 Change: Remove the line "Present only if DataFlag is set in the header", as DataFrag has no such flag. Remove the line "Present only if either the DataFlag or the KeyFlag are set in the header", as DataFrag has no DataFlag. In the first bullet point replace "If the DataFlag is set" with "If the KeyFlag is not set". Section: 8.4.1 Page: 63 Change: Section 8.4.13 (Writer Liveliness) is missing from this list. Section: 8.4.7.1, Figure 8.15 Page: 72 Change: resendDataPeriod is unused, it should be removed Section: 8.4.7.2, Table 8.49 Page: 75 Change: resendDataPeriod is unused, it should be removed Section: 8.4.7.2, Table 8.50 Page: 76 Change: Locator_t in this table should be ReaderLocator Section: 8.4.7.2.1 Page: 76 Change: resendDataPeriod is unused, it should be removed Section: 8.4.7.2.2, 8.4.7.2.3 Page: 76 Change: Locator_t in these sections should be ReaderLocator Section: 8.4.7.3 Page: 77 Change: In figure 8.15, type of locator is Locator_t[*] but the [*] is missing from this table and the text should reflect the true cardinality. Section: 8.4.9.2 Page: 93 Change: The sentence fragment "Submessages are used…" is nonsensical, it should be removed. Section: 8.5.3.2, Table 8.73 Page: 127 Change: The six constants for BuiltInEndpoints (each constant describes an endpoint, not an endpoint set) are all missing from the PSM Section: 8.5.3.3, Figure 8.29 Page: 128 Change: Remove figure 8.29, it is a duplicate of figure 8.28 Section: 9.3.1.5 Page: 153 Change: OMG Issue 12509 was resolved but the changed text is missing here Section: 9.3.2, Table 9.4 Page: 153 Change: OMG Issue 12507 was resolved but the assigned Vendor IDs are not listed. If they should not be listed in the spec, a URL to the appropriate omg.org web site should be listed here. Section: 9.3.2, Table 9.4 Page: 156 Change: ReliabilityKind_t is not used on the wire, it should be a PIM-only concept and removed from the PSM Section: 9.3.2, Table 9.4 Page: 157 Change: Property_t and EntityName_t are not used by the protocol, they should be removed Section: 9.3.2, Table 9.4 Page: 158 Change: Three problems with the constants for BuiltinEndpoints: 1. the constants don't match the table in the PSM, so the reader of the spec must guess to determine how they are used. 2. constants corresponding to propagation of Topic discovery data are missing. 3. constants for 'participant proxy' and 'participant state' need further explanation (or removal from the spec) Section: 9.4.5.3, block diagram Page: 170 Change: Flag "K" is missing from the flags byte Section: 9.6.2.1 Page: 180 Change: The wire-representation diagram is missing the participantGuidPrefix and kind fields (also see OMG Issue 12501) Section: 9.6.2.2, Table 9.10 Page: 181 Change: remoteWriterGuid belongs to WriterProxy, not ReaderProxy Section: 9.6.2.2, Table 9.10 Page: 181 Change: Table 9.10 caption is incorrect Section: 9.6.2.2.2, Table 9.12 Page: 184 Change: The following ParameterIds are not used for built-in entities and therefore do not belong in this table: PID_BUILTIN_ENDPOINT_SET, PID_PROPERTY_LIST, PID_TYPE_MAX_SIZE_SERIALIZED, PID_ENTITY_NAME, PID_KEY_HASH, PID_STATUS_INFO (the last six rows). Some of them are already in Table 9.14. Section: 9.6.2.2.2, Table 9.13 Page: 187 Change: The presence of the final three rows of the table with "Reserved for future use" is confusing, why is it in the specification if all (non-vendor-specific) PIDs are effectively reserved. Section: 9.6.3, Table 9.14 Page: 188 Change: PID_DIRECTED_WRITE and PID_ORIGINAL_WRITER_INFO are not described in the subsequent subsections. Section: 9.6.3.2, Table 9.16 Page: 190 Change: KeyHashSuffix does not exist; remove this row from the table. The row for SerializedData should be sufficient to describe the use of PID_COHERENT_SET.
Page: 14 Change: discriminator and port number using 4 octets *each* (insert the word “each”)
Page: 40 Change: Time_t is underspecified. What real-world time does 0 represent?
Page: 52 Change: Add parentheses around the subexpression: "(dataSize % fragmentSize) ? 1 : 0"
Page: 64 Change: DDS has no "finish" operation on DataReader
Page: 65 Change: DDS has no "finish" operation on DataReader
Page: 77 Change: Unlike other tables of operations in this section, none of these operations are described in the text of the section
Page: 85 Change: Figure 8.16 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.
Page: 92 Change: Figure 8.18 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.
Page: 120 Change: Fragment size should be allowed to be equal to (instead of strictly greater than) 1KB, also define KB as 1024 bytes to avoid the KB/KiB issue (1000 vs. 1024).
Page: 123 Change: Scope of counts is underspecified: is a Heartbeat count scoped to one Writer; is an AckNack/NackFrag count scoped to a Reader itself or to a Reader's conversation with a given Writer?
Page: 126-127 Change: In the figure and the table, BuiltinEndpointSet_t is already a "set" so it should not also be an array with "[*]"
Page: 127 Change: In the row for defaultUnicastLocatorList, "at least one Locator must be present" constrains implementations unnecessarily. As long as each Endpoint has a locator, there is no need for the participant to have a default locator
Page: 146 Change: There is no such "directed" or "peer-to-peer" function described by the DDS spec, therefore none is available to the user. If such a function should be used by RTPS to implement DDS communication, its use by RTPS must be described here. Otherwise remove this section.
Page: 146 Change: There is no such "property list" feature in the DDS spec, this section should be removed.
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.
Page: 150
Change: ENTITYID_UNKNOWN is missing a level of braces to represent the embedded array inside the struct: { {0, 0, 0}, 0 }
Page: 151-152 Change: All EntityId_t values should be shown with braces for the embedded array (see previous note)
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”?
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.)
Page: 169 Change: This section refers to submessages larger than 64KB, which is impossible with UDP/IP.
Page: 181 Change: Duration_t (used for leaseDuration) is not defined in the PSM. Use Time_t instead?
Page: 181 Change: This section under-specifies the key fields for all four data types. The "inherited" DDS structures do not provide a key field that is useful for RTPS because it is vendor-specific. This section should describe what a "key only" (KeyFlag==1) Data Submessage should contain as its payload for both SPDP and for all 3 types of SEDP. Table 9.13 indicates that Built-In Topic Keys can be encoded as a GUID, which has no correspondence to the actual definition of Built-In Topic Keys.
Page: 182 Change: This section refers to a non-existent "key parameter" in the Data submessage.
Page: 183-184 Change: IPv4Address_t and Port_t are not defined anywhere in the specification
Page: 184 Change: Duration_t (used for PID_PARTICIPANT_LEASE_DURATION) is not defined in the PSM. Use Time_t instead?
Page: 185 Change: The following DDS fields lack a mapping: TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation, and the "key" field in Publication, Subscription, and Topic. Also, the mapped DDS field SubscriptionBuiltinTopicData::lifespan does not exist in DDS
Page: 184-187 Change: The following RTPS fields lack a mapping: ParticipantProxy::guidPrefix, ReaderProxy::remoteReaderGuid, WriterProxy::remoteWriterGuid. Table 9.10 indicates that they are optional, but they are not possible to encode without a mapping. Also, DiscoveredReaderData::contentFilterProperty (AKA DiscoveredReaderData::contentFilter in the PIM: these should be consistent) is lacking a mapping
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.
Page: 193 Change: Delete the last sentence of paragraph 2, the concept of a DDS "type-plugin" is not defined.
Page: 193 Change: This section should define the "options" field which is subsequently referenced.
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.
Page: 194-195 Change: Remove the paragraphs starting "In addition to, …" since its only purpose is to describe a non-existent length field.
The DDSI v2.1 specification describes in section 8.4.13 the Writer Liveliness Protocol as the mechanism used by participants to assess the liveliness of their contained data writers (with automatic liveliness). The Writer Liveliness Protocol is specified as mandatory for compliant implementations. The first remark is that the Writer Liveliness Protocol is not required at all for interoperability, thus it should not be a mandatory requirement for compliant implementation. This is not only easy to reason about, but wireshark captures made during the DDS interoperability demo of the past March 2012 showed how different DDS implementations could work w/o using this protocol. Beyond that, the protocol is simply superfluous as DataWriter liveliness can be anyway asserted via the Participant Liveliness, this in turns is asserted by the participant discovery protocol. Beyond the potential waste of resource required by yet another periodic information flow, what seems very odd is the choices of QoS for the built-in entities that write this periodic message. As described in section 8.4.13.3 these built-int entities communicate reliably and have a history set to KeepLast(1), along with TransientLocal durability. This QoS settings only "works" best for those implementations that tie the reliability send queue to the writer history but is less than ideal for those that rightfully decouple history and reliability. Anyway, however one looks at it this part of the specs seems bogus. In addition as mentioned above is not required for interoperability and generates yet another stream of periodic messages. The recommendation is to remove this section from the next version of the standard.
The DDSI/RTPS wire protocol currently expects the transport to provide the size for the message -- said in other terms, the current version of the protocol can only work with message oriented transports, such as UDP/IP. This assumptions should be dropped in order to enable the use of DDSI/RTPS over stream oriented transports such as TCP/IP. One possible approach to overcome this limitation w/o breaking backward compatibility with other implementation is to add a new sub-message element, say MESSAGE_LEN structured as follows: +--------+--------+--------+--------+ | ID | Flags | octect2NextSME | +--------+--------+--------+--------+ | Message Length | +-----------------------------------+ In addition, for efficient parsing, if the sub-message above, when used, should be always placed right after the RTPS header.