DDS 1.1 RTF Avatar
  1. OMG Issue

DDS11 — DDS ISSUE# 47] Allow application to not specify a timstamp

  • Key: DDS11-6
  • Legacy Issue Number: 6847
  • Status: open  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-157 Ability_of_the_application_to_not_specify_a_timestamp

    Getting a timestamp can be an expensive operation. It is desirable
    that the application can configure a datawriter such that it does not
    get/send the timestamp

    The option of letting the application not set a timestamp by means of
    calling write_w_timestamp() and passing TIME_INVALID is not good
    because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP
    require this. Also it would be hard to manage if the application could
    sometimes specify a timestamp and sometimes not for the same
    DataWriter/instance.

    **PROPOSAL**

    Add an "receptionTimestamp" field to the SampleInfo.

    Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For
    compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if
    you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers.

    Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP.

    The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED.
    And is set on both the DataWriter and the DataReader and also on
    Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED.

    The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has
    a kind that can be NOT_PROVIDED and PROVIDED.

    The SOURCE _TIMESTAMP indicates that data must be timestamped when
    sent.

    The RECEPTION_TIMESTAMP indicates that data must be timestamped when
    received.

    DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE
    _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE
    QoS.

    If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write
    operation does not put any timestamp and the xxx_w_timestamp operation
    silently ignores the timestamp and behaves normally. Upon reception
    the sourceTimestamp field in the SampleInfo will be TIME_INVALID

    If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will
    automatically get the timestamp by some means (i.e. the middleware
    will do it), the xxx_w_timestamp will allow the application to provide
    the timestamp. In either case the data will be sent with a timestamp
    and the SampleInfo.sourceTimestamp field will never be TIME_INVALID

    It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the
    DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is
    the relative order and that does not require to get a true
    timestamp. If this is too confusing we could rename
    BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER

    If RECEPTION_TIMESTAMP is NOT_PROVIDED then the
    SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise
    it will never be TIME_INVALID By default the source-timestamp is
    provided.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT