1. OMG Mailing List
  2. DDSI-RTPS 2.6 RTF mailing list

Open Issues

  • Issues not resolved
  • Name: ddsi-rtps-rtf6
  • Issues Count: 6

Issues Descriptions

Network amplification

  • Status: open  
  • Source: Trend Micro Inc. ( Federico Maggi)
  • Summary:

    Details available to RTF members

  • Reported: DDSI-RTPS 2.5 — Fri, 24 Sep 2021 13:16 GMT
  • Updated: Thu, 21 Oct 2021 08:15 GMT

Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long'

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

    RTPS version 2.3 updated modified Time_t to have the 'seconds' be of type unsigned long so that there would be no rollover in 2038.

    This matches when it is shown in the IDL definition in 9.3.2.1 'IDL Definitions'

    However Section 9.4.2.9 Timestamps illustrates the 'Timestamp' sub-message element with a 'long' instead of 'unsigned long' for the seconds part. It should be changed to illustrate 'unsigned long' as in:

    Timestamp:

    0...2...........8...............16.............24. .............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                 unsigned long    seconds                      | 
    +---------------+---------------+---------------+---------------+ 
    |                 unsigned long    fraction                     | 
    +---------------+---------------+---------------+---------------+
    
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 23:32 GMT
  • Updated: Thu, 10 Jun 2021 23:32 GMT

Inconsiastent notation used to represent bit positions pictorially

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

    The spec uses two numbering schemes for bits:

    For example 9.4.1 (Overall Structure)

    0...2...........7...............15.............23. .............31
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    But then in 9.4.4 (Mapping of the RTPS Header)

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

    It should be consistent. The more correct scheme appears to be:

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

    With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.

  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 22:20 GMT
  • Updated: Thu, 10 Jun 2021 22:20 GMT

SequenceNumberSet validity could be too strict

  • Status: open  
  • Source: Object Computing, Inc. - OCI ( Adam Mitz)
  • Summary:

    9.4.2.6 SequenceNumberSet defines one of the rules for validity as
    bitmapBase >= 1

    We have observed that other implementations use bitmapBase 0 in AckNack submessages. There seems to be no downside to just accepting these as valid even though the spec currently says they are not.

    The RTF should determine if this condition in 9.4.2.6 can just be removed.

  • Reported: DDSI-RTPS 2.3 — Mon, 7 Jun 2021 22:55 GMT
  • Updated: Mon, 7 Jun 2021 22:55 GMT

Support transport-level RTPS message compression

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

    Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Updated: Fri, 9 Apr 2021 12:28 GMT