Issue 17284: History and Reliability should be orthogonally independent concerns (data-distribution-rtf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Revision Severity: Significant Summary: The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader. In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" -- this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why. Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being). Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message. Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast(n). In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers -- without holes -- might finds him-/her-self surprised by the fact that some samples might be missing. 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: DDS v1.2 Section: 7.1.3 FormalNumber: formal/07-01-01 Version: 1.2 Doc_Year: 2007 Doc_Month: January Doc_Day: 01 Page: 96-120 Title: History and Reliability should be orthogonally independent concerns Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Description: The current DDSv1.2 specification provides a slightly different semantics for the history on the writer side and on the reader. In addition, the DDS v1.2 specification allows to use the data-writer history as the "reliability-send-queue" -- this is combined with the fact that History is (correctly) not an RxO policy leads to a serious bug in the spec (luckily not all DDS implementations follow this path) . Let's try to understand why. Firs, it is important to comprehend that unless a data writer uses KeepAll history, reliable data delivery is not guaranteed to matching data readers. This can't be guaranteed even when using Reliable communication (obviously ignoring data-writer crashes for the time being). Essentially, under this scheme a DataWriter is allowed send/re-send only what is in its history cache. If a sample is out of history a DataWriter won't do anything, thus leading to potential inconsistencies in case some reader has lost the message. Things get very messy when a DataReader with KeepAll History is matching a DataWriter that does uses KeepLast(n). In this case, the poor DataReader which might legitimally expect to have on his history all the samples written by the writers -- without holes -- might finds him-/her-self surprised by the fact that some samples might be missing. Considering the problems described above, we suggest the following changes to the DDS specification: 1. De-correlate history on the data-writer w.r.t. reliability. Let the history only represent the amount of data that is kept on the DataWriter to serve late joiners readers under a TRANSIENT_LOCAL durability 2. Forbid the use of KeepAll for the DataWriter History, as this does not really makes sense -- at least once history and reliability have been de-correlated. 3. Extends the DDSI/RTPS specification with configuration of reliability queues. As this is where it really belongs.