1. OMG Mailing List
  2. DDSI-RTPS 2.5 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: ddsi-rtps-rtf5
  • Issues Count: 14

Issues Descriptions

Revise list of Submessages EntityIDs and PIDs reserved for other specifications

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    It seems that some ranges reserved by other specifications (e.g. XTypes type service) are missing from RTPS. They should be added:

    9.4.5.1.1.1 for SubmessageIDs
    to 9.3.1.3.1 for the EntityIDs
    Table 9.12 for ParameterIDs

    Maybe always list the same set of specs: DDS Security, XTypes, DDS-RPC? and indicate explicitly if a specification does not reserve anything.

    Also figure out whether new builtin endooints show up under the "availableBuiltinEndpoints" see Table 8.73 also the IDL in 9.3.2
    Right now there is a comment in the IDL that says:

    /* Bits 12-15 have been reserved by the DDS-Xtypes 1.2 Specification
    and future revisions thereof.
    Bits 16-27 have been reserved by the DDS-Security 1.1 Specification
    and future revisions thereof.
    */

    Maybe this needs ti be more explicit and get its own section.

  • Reported: DDSI-RTPS 2.3b1 — Wed, 24 Jun 2020 19:00 GMT
  • Updated: Wed, 24 Jun 2020 19:04 GMT

Add an INFO_AGE submessage

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Ornulf Staff)
  • Summary:

    The INFO_AGE submessage is semantically similar to INFO_TS, but it contains a Duration_t instead of a Time_t. It assigns a time to subsequent submessages that the service may use for functionality like lifespan and sample ordering.

    Transmitting a sample age gives the receiver an inexact timestamp. There will be an unknown time span between the time the sender calculates the age and the time the receiver transforms it back to a local time. If the receiver does no adjustment based on estimated latency, the calculated time will always be too high. However, the error will in practice be bounded and in many scenarios the receiver will have a time that is within one second of the actual sample time.

    Kongsberg uses a submessage like this today for deployments where no correct time source is available. This might be because the system has to be fully operational before a good time source is ready, or because some systems have requirements that mandate that the system clock must be adjustable. We have found that this is a better solution than attempting to have some form of synchronized "DDS time" on the network, because coming up with a network time that works very quickly at startup and is robust to network fragmentation is challenging.

    The use of the INFO_AGE message is enabled by a vendor specific configuration option to the participant containing the publisher. It may either be sent as an alternative to INFO_TS or in combination with INFO_TS to allow the subscriber to determine which time to use an also for compatibility with systems without support for INFO_AGE.

    INFO_AGE allows two features on systems with no time synchronization:

    • Full support for sample lifespan QoS, as long as lifespan is an order of magnitude larger than network latency
    • Partial support for by source timestamp QoS. It may be used to determine that some samples are clearly older than others, in practical use when the time difference is on the order of seconds. When estimated times are within the uncertainty margin, the subscriber needs to treat them as by destination order QoS to avoid surprising behavior when e.g. a writer publishes several samples in quick succession.

    It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 22 Jun 2020 12:27 GMT
  • Updated: Wed, 24 Jun 2020 18:39 GMT


Editorial corrections

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    7.6 enumerated list 5th bullet

    • The transport will drop m essages if incomplete or corrupted during transfer

    -> messages



    8.2.4

    Table 8.6 - RTPS Entity Attribues

    -> Attributes



    8.2.6

    Table 8.9 - RTPS Endpoint configuration attribues

    -> attributes



    8.3.7.2.5 enumerated list 1st bullet

    • If the DataFlag [...], the serializedPayload element is interpreted as
      the value of the dtat- object.

    -> data-object



    8.3.7.9.2 Table 8.42 2nd row 3rd column (meaning)

    Indicates the protocol used for subsequent Sudmessages.

    -> Submessages



    8.4.2.3.2 1st para 2nd sentence

    This requirement only applies if the Reader
    can accomodate these missing samples in its cache [...]

    -> accommodate



    8.4.3 3rd para 3rd sentence

    This involves a
    trade-off, as improved scalability and reduced memory usage may require additional bandwith usage.

    -> bandwidth



    8.4.10.4.7 fixed font section

    FIND change FROM this.cha;nges_from_writer
    

    -> changes_from_writer



    8.6.2 enumerated list 3rd bullet

    * The meaning of submessageIds cannot be modfied.

    -> modified



    8.7.2.2.4 1st sentence

    Implementations may optimize bandwith usage by applying a time-based filter on the Writer side.

    -> bandwidth



    8.7.4 4th para 1st sentence

    When RTPS sends a Data Submessge to communicate instance state changes it may include only the Key of

    -> Submessage



    8.7.4 6th para numbered list

    1. If the previous update to the instance passed the filter, [...]
    that either includes the data value, or else indicates the IntanceState is ALIVE_FILTERED.

    -> InstanceState



    8.7.9 3rd para

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

    -> supports



    9.1 enumerated list 4th bullet

    • [...]; this allows multiple RTPS endpoints to
      share a single operat- ing-system UDP resource (socket/port) while

    -> operating-system



    9.3.1.2 Mapping of the EntityId_t

    typedef octet OctetArray3[3]; struct {
    

    -->

    typedef octet OctetArray3[3]; 
    struct EntityId_t {
    



    9.4.5.7.1 Flags in the Submessage Header

    Reference to (8.3.6.2).

    -> 8.3.7.4.2



    9.4.5.14.1

    The MulticastFlag is [...]. M=1 means the InfoReplyIp4 also includes a
    multicastRLocator.

    -> multicastLocator



    9.6.1.3 1st sentence

    The port number expresssions use the following parameters:

    -> expressions



    9.6.2.2.1 1st para 2nd sentence

    In order to accomodate vendor specific options [...]

    -> accommodate



    9.6.3.9 p179 ca. 5th para

    The DisposeedFlag is represented with the literal 'D.'

    -> DisposedFlag

  • Reported: DDSI-RTPS 2.3 — Tue, 21 Apr 2020 08:05 GMT
  • Updated: Tue, 26 May 2020 23:20 GMT

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

    The latest proposal we had is copied below. See to DDSIRTP23-6 for more background and previous discussions.

    Overall Approach
    -----------------------
    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • rtpsMsgLength

    The rtpsMsgLength indicates the length of the RTPS message

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

    Another option would be that the RTPSHeaderExtension (therefore not a header extension) would go after the SecureRTPSPrefixSubMsg, but it would be useless there because it can't be used before applying security. The length is no longer serving its purpose, so this is therefore not an option.

    RTF 2.3 Latest Proposed Revised Text

    In section 7.6 'The RTPS Transport Model', update the following bullet point as shown:

    The transport provides a means to deduce the size of the received message.



    In Section 8.3.2 (Type Definitions), Table 8.13 'Types used to define RTPS messages', update the 'Purpose' column for Type SubmessageKind to add RTPS_HE to the list of reserved kinds:

    Enumeration used to identify the kind of Submessage.
    The following values are reserved by this version of the protocol:
    RTPS_HE, DATA, GAP, HEARTBEAT, ACKNACK, PAD, INFO_TS, INFO_REPLY, INFO_DST, INFO_SRC, DATA_FRAG, NACK_FRAG, HEARTBEAT_FRAG



    In section 8.3.2 'Type Definitions' in Table 8.13 add the following rows after the row for 'Count_t'

    Checksum_t Type used to hold a checksum. Used to detect message corruption.
    MessageLength_t Type used to hold the length of an RTPS Message.
    The following values are reserved by the protocol: MESSAGE_LENGTH_INVALID


    In section 8.3.2 'Type Definitions' in Table 8.13 add the following row after the row for 'ParameterId_t

    PortNumber_t Type used to hold an RTPS port number.
    The following values are reserved by the protocol: PORT_INVALID


    In section 8.3.3 'The Overall Structure of an RTPS Message' : Update Figure 8.8 'Structure of RTPS Messages' with F_88_Submessages_Overview.svg attached to this issue.
    (Adds HeaderExtension.)



    In section 8.3.3 'The Overall Structure of an RTPS Message' update the final paragraph as follows:

    Each message sent by the RTPS protocol has a finite length. This length is not sent explicitly by the RTPS protocol but is part of the underlying transport with which RTPS messages are sent. This length is optionally sent in the RTPS HeaderExtension Submessage.

    The length may also be sent by the underlying transport that carries the RTPS message. In this case it may be omitted from the HeaderExtension. In For example, in the case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport headers.

    A In contrast, a stream-oriented transport (like TCP) would need to insert the length ahead of the message include the length in the RTPS HeaderExtension in order to identify the boundary of the RTPS message.



    In section 8.3.3.2 'Submessage structure
    Replace Figure 8.10 'Structure of the RTPS Submessages' with the figure F_810_Submessage_structure.svg, attached to this issue resolution. (Adds RTPSHeaderExtension)



    In section 8.3.4 'The RTPS Message Receiver', in table Table 8.16 'Initial State of the Receiver' perform the following 2 actions:

    (1) In the row for messageLength add the text "MESSAGE_LENGHT_INVALID" in the 'initial value' column.
    (2) Add the following 2 rows to the end of the table:

    checksum CHECKSUM_INVALID
    destinationPort PORT_INVALID


    In section 8.3.4.1 'Rules Followed by the Message Receiver', in the last numbered item list, modify the last sentence in item number 1 as shown below:

    In this version of the protocol, only the Header and the Submessages HeaderExtension, InfoSource, InfoReply, InfoDestination, and InfoTimestamp change the state of the Receiver.



    In section 8.3.5 'RTPS SubmessageElements' : Update Figure 8.12 'RTPS SubmessageElements' with F_812_Submessage_Elements_Details.svg attached to this issue.
    (Adds Checksum, MessageLength, and Port.)



    Add the following subsections following subsection 8.3.5.10 (Count):

    *8.3.5.11 Checksum*
    Checksum is used in the HeaderExtension Submessage and enables the receiver to detect messages corrupted by the underlying transport.
    Depending on the underlying transport used to send the RTPS message, the transport may already provide sufficient guarantee that messages are not corrupted. In these cases, the Checksum may be omitted from the HeaderExtension. The specific behavior shall be defined for each Transport PSM.

    *8.3.5.12 MessageLength*
    MessageLength is used in the HeaderExtension Submessage and enables the sender to indicate the lenght of the RTPS message.
    Depending on the underlying transport used to send the RTPS message, the length of the RTPS message may already or be derivable from the information in the transport header. In these cases, the MessageLength may be omitted from the HeaderExtension. The specific behavior shall be defined for each Transport PSM.

    *8.3.5.13 Port*
    Port is used in the HeaderExtension Submessage and enables the sender to indicate the destination port for the RTPS message.
    Each message sent by the RTPS protocol has a destination port. This port is optionally sent in the RTPS HeaderExtension Submessage. Depending on the underlying transport, this same port may be sent as part of the transport headers. In this case, the Port may be omitted from the HeaderExtension. The specific behavior shall be defined for each Transport PSM.



    In section 8.3.7 'RTPS Submessages' in the list of bullets that follow the sentence "The interpreter Submessages are:" add the following as the first bullet:

    • HeaderExtension: Provides additional information that logically belongs in the RTPS Header. The additional information is included inside this submessage, instead of the RTPS Header in order to preserve interoperability with earlier versions of the RTPS protocol. RTPS version 2.4 and earlier are not able to process the HeaderExtension and will skip this submessage.


    In section 8.3.7 'RTPS Submessages' Update Figure 8.9 'Structure of RTPS Message Header' with F_813_Submessages_Details.svg attached to this issue.
    (Adds HeaderExtension.)
    ----

    Following section 8.3.7.4 'Gap' add a new section 8.3.7.5 'HeaderExtension' with the content shown below:

    8.3.7.5 HeaderExtension
    8.3.7.5.1 Purpose

    The HeaderExtension Submessage is used to convey optional information about the RTPS Message. This submessage, if present, shall appear directly after the RTPS Header.

    8.3.7.5.2 Content
    The elements that form the structure of the HeaderExtension message are described in the table below.

    Table 8.XX - Structure of the HeaderExtension Submessage

    element type meaning
    EndiannessFlag SubmessageFlag Appears in the Submessage header flags. Indicates endianness.
    LenghtFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageLength field is present.
    ChecksumFlags (3 flags) SubmessageFlag Appears in the Submessage header flags. Indicate the presence and format of the rtpsMessageChecksum field.
    PortFlag SubmessageFlag Appears in the Submessage header flags.Indicates the rtpsPort field is present.
    InlineParamatersFlag SubmessageFlag Appears in the Submessage header flags. Indicates the the inlineParameters field is present.
    rtpsMessageLength ulong Present only if the LenghtFlag is set in the header. Contains the length of the RTPS Message starting from the beginning of the RTPS Header.
    rtpsMessageChecksum Checksum Present only if the ChecksumFlags are different than 000.
    Contains a checksum computed over the content of the RTPS Message, which includes the RTPS Header and HeaderExtension submessage.
    rtpsPort Port Present only if the PortFlag is set in the header.
    Contains the destination port for the RTPS Message. The meaning shall be defined by the transport PSM that carries the RTPS Message.
    inlineParameters ParameterList Present only if the InlineParamatersFlag is set in the header. Contains additional information.

    8.3.7.5.3 Validity
    This Submessage is invalid when any of the following is true:

    • The submessage is present but does not immediately follow the RTPSHeader.
    • The submessageLength in the Submessage header is too small to fit the fields that are present as indicated by the submessage flags.
    • The rtpsMessageLength is too small to fit the RTPS Header and the HeaderExtension.

    8.3.7.5.4 Change in state of Receiver
    The state of the Receiver changes is certain fields are present in the HeaderExtension as indicated below:

    IF ( LengthFlag ) {
        Receiver.rtpsMessageLength   = HeaderExtension.rtpsMessageLength
    }
    IF ( ChecksumFlags != 000 ) {
        Receiver.rtpsChecksum        = HeaderExtension.rtpsMessageChecksum
    }
    IF ( PortFlag) {
        Receiver.rtpsDestinationPort = HeaderExtension.rtpsPort
    }
    IF ( InlineParamatersFlag) {
        Receiver.inlineParameters = HeaderExtension.inlineParameters
    }
    

    8.3.7.5.5 Logical Interpretation
    The HeaderExtension may be sent to communicate the length of the RTPS Message, a checksum of the RTPS Message, the destination port of the message, or additional information about the RTPS message.

    The length of the RTPS Message (rtpsMessageLength) may be useful to for managing memory while receiving incoming RTPS Messages. The value of the rtpsMessageLength shall indicate the length of the entire RTPS Message starting from the beginning of the RTPS Header.

    The checksum (rtpsMessageChecksum) may be useful to detect message corruption by the underlying transport. It shall be computed over the entire RTPS Message. For the purpose of computing the checksum, the value of the rtpsMessageChecksum field in the RTPS HeaderExtension shall be set to zero.

    The destination port (rtpsPort) may be useful for specific transport PSMs. If used, it shall be defined by the corresponding Transport PSM.

    The inlineParamaters contain additional information about the RTPS Message. This is intended for future extensibility. This version of the specification does not define any inline parameters in the HeaderExtension.



    In section 9.4.5.1.1 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:

    enum SubmessageKind {
        @value(0x00)
        RTPS_HE,    /* RTPSHeaderExtension */
        @value(0x01)
        PAD, /* Pad */            
        @value(0x06)
        ACKNACK, /* AckNack */        
        @value(0x07)
        HEARTBEAT, /* Heartbeat */      
        @value(0x08)
        GAP, /* Gap */            
        @value(0x09)
        INFO_TS, /* InfoTimestamp */  
        @value(0x0c)
        INFO_SRC, /* InfoSource */     
        @value(0x0d)
        INFO_REPLY_IP4, /* InfoReplyIp4 */   
        @value(0x0e)
        INFO_DST, /* InfoDestination */
        @value(0x0f)
        INFO_REPLY, /* InfoReply */      
        @value(0x12)
        NACK_FRAG, /* NackFrag */       
        @value(0x13)
        HEARTBEAT_FRAG, /* HeartbeatFrag */  
        @value(0x15)
        DATA, /* Data */           
        @value(0x16)
        DATA_FRAG /* DataFrag */
    };
    


    Add the following subsection as the subsection directly following 9.4.5.1 'Submessage Header' in section 9.4.5 'Mapping of the RTPS Submessages':

    9.4.5.2 RTPSHeaderExtension Submessage
    Sub clause 8.3.7.1 in the PIM defines the logical contents of the RTPSHeaderExtension Submessage. The PSM maps the RTPSHeaderExtension Submessage into the following wire representation:

    0...2...........8...............16..............24..............32
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    RTPS_HE    |X|X|I|C|C|C|L|E|       octetsToNextHeader      |
    +---------------+---------------+---------------+---------------+
    |                ulong rtpsMsgLength   [iff L == 1]             |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     rtpsMessageChecksum  [iff CCC != 000]     ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     inlineParameters     [iff I != 0]         ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    


    In section 9.3.2, add the following IDL following the IDL for:
    typedef long Count_t;

    typedef octet  Checksum32_t[4];
    typedef octet  Checksum64_t[8];
    typedef octet  Checksum128_t[16];
    typedef octet  Checksum256_t[32];
    
  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Updated: Tue, 26 May 2020 23:12 GMT

Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Updated: Fri, 22 May 2020 21:56 GMT

Discriminating the reasons for a GAP

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

    In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

    Currently there is no way for the receiving application to tell the difference.

    There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Updated: Tue, 19 May 2020 18:39 GMT

currentGSN.value < lastGSN.value condition seems wrong

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value

  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Updated: Tue, 5 May 2020 03:37 GMT

PSM and PIM description of Gap message not matching

  • Status: open  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

    The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Updated: Tue, 5 May 2020 02:51 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Updated: Tue, 24 Mar 2020 14:41 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Updated: Tue, 18 Feb 2020 15:47 GMT

Update Acknowledgemts, Copyright and Statement of Proof

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

    We may also want to list contributor's names as we do for other specs.

    Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

    Copyright should be updated to include the companies in the 'Acknowledgments'

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Updated: Tue, 24 Sep 2019 21:23 GMT

Incomplete specification of how a Publisher and Subscriber are identified

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Updated: Sat, 2 Mar 2019 19:58 GMT

Unclear specification on how the Publisher GUID is communicated

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Updated: Sat, 2 Mar 2019 19:57 GMT