Issue 17285: The Writer Liveliness Protocol should be removed (ddsi-rtps-rtf) Source: ADLINK Technology Ltd (Angelo Corsaro, PhD., angelo.corsaro(at)adlinktech.com) Nature: Revision Severity: Critical Summary: 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. Resolution: Revised Text: Actions taken: March 29, 2012: received issue Discussion: End of Annotations:===== m: webmaster@omg.org To: Subject: Issue/Bug Report ******************************************************************************* Name: Angelo Corsaro Employer: PrismTech mailFrom: angelo@icorsaro.net Terms_Agreement: I agree Specification: Data Distribution Service Interoperability Wire Protocol Section: 8.4.13 FormalNumber: formal/2009-01-05 Version: 2.1 Doc_Year: 2009 Doc_Month: January Doc_Day: 05 Page: 136 Title: The Writer Liveliness Protocol should be removed Nature: Revision Severity: Critical CODE: 3TMw8 B1: Report Issue Description: 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.