Issue 11028: Provide default timing parameters
Issue 11029: Remove length field in encapsulation chapter
Issue 11030: Change structure of (Nokey)DataFrag
Issue 11031: Clarify Writer liveliness mechanism
Issue 11032: Version number should be 2.0
Issue 11033: Add SerializedDataFragment as Submessage Element
Issue 11034: Rename BuiltinEndpointKind and add description
Issue 11036: Clarify interoperability requirement 8.4.2.3.4
Issue 11037: Clarify interoperability requirement 8.4.2.3.3
Issue 11038: Define default multicast Reader behavior
Issue 11039: Reclaiming finite resources from inactive readers
Issue 11040: Clarify implementing Count submessage element
Issue 11041: Reader-side Heartbeat response suppression
Issue 11042: Clarify Writer Response to ACKNACK
Issue 11043: Interpreting Liveliness Heartbeats
Issue 11044: Add Directed Write Parameter Id
Issue 11045: Supporting Inline QoS by Stateful Readers
Issue 11046: Add Entity Name Parameter Id
Issue 11047: Add Property List Parameter Id
Issue 11048: Add Max Sample Size Serialized Parameter Id
Issue 11049: Clarify Data Encapsulation Schemes
Issue 11050: Elaborate on Necessity and Usage of In-line QoS
Issue 11051: Clarify GAP usage
Issue 11052: ChangeKind Has DDS Relationship
Issue 11053: DDS DURABILITY Persistent QoS
Issue 11065: TOPICNAME parameter appears in PSM but not in PIM
Issue 11074: Add Max Sample Size Serialized Parameter Id
Issue 11075: Add Parameter ID for Original Writer Info
Issue 11028: Provide default timing parameters (dds-interop-ftf)
Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Kenneth Brophy, ken(at)rti.com)
Nature: Uncategorized Issue
Severity:
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;
Resolution: Provide default timing parameters for the reliability protocol.
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.
Resolution: Explicitly state that the sequence number of a writer's first sample or fragment is 1.
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 ~ | | +---------------+---------------+---------------+---------------+
Resolution: Reposition the inlineQos field to be consistent with other messages, implementation simplicity, and higher performance.
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
Resolution: Update the Writer liveliness protocol to be independent of Discovery.
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)"
Resolution: Change the version number from 1.2 to 2.0.
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 :
Resolution: Add a new SubmessageElement subclass called SerializedDataFragment.
Source: Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com) Summary: This type is actually a set of boolean flags and so should be renamed to reflect its actual intention. Additionally, the description for this type is missing from Table 9.4. Resolution: Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type. Revised Text: In Table 8.77, the third row from the end (the cell in the first column reads "availableBuiltinEndpoints"), replace "BuiltinEndpointKind" with "BuiltinEndpointSet_t." Replace Figure 8.26 with: In Table 9.4, add the following row to the end of the table: BuiltinEndpointSet_t Mapping of the typetypedef unsigned long BuiltinEndpointSet_t;where#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER 0x00000001 << 0;#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR 0x00000001 << 1;#define DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER 0x00000001 << 2;#define DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR 0x00000001 << 3;#define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER 0x00000001 << 4;#define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR 0x00000001 << 5;#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER 0x00000001 << 6;#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR 0x00000001 << 7;#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER 0x00000001 << 8;#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR 0x00000001 << 9;#define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER 0x00000001 << 10;#define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER 0x00000001 << 11;
Resolution: Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type.
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.
Resolution: Clarify requirement 8.4.2.3.4 to include the special case of a Reader first discovering a Writer.
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.
Resolution: Allow Writer to reclaim resources and send repairs if possible.
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.
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.
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
Resolution: Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute
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
Resolution: Explain proper usage of the count element of Heartbeats and ACKNACKs.
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
Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.
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.
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.
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
Resolution: A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.
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>
Resolution: Add a new standard parameter Id, PID_DIRECTED_WRITE, with ID of 0x0057 and type of a sequence of GUIDs.
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
Resolution: Allow stateful implementations the choice of whether or not to parse inline QoS.
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
Resolution: Add parameter Id for Entity Name.
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>
Resolution: Add parameter Id for Property List.
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
Resolution: Add parameter Id for Type Max Sample Size Serialized
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.
Resolution: Replace the length field of the standard data encapsulation schemes with a scheme-specific option field.
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.
Resolution: Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.
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.
Resolution: Clarify GAP usage.
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
Resolution: Revise table 8.5 to show the relationship between CacheChange kind and DDS instance state kind.
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.
Resolution: Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.
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.
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
withdrawn, duplicate of issue 11048
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.
withdrawn, duplicate of issue 11053