Add Docs, updated TODO

src/TODO.txt

@@ -59,7 +59,7 @@
     - Yes: 8.6 Implementations of this version of the RTPS protocol should be able to process RTPS Messages not only with the same major version but possibly higher minor versions.
 * If a DATA Submessage is invalid in any way, the Sequence Number is never marked as received, and thus processing of remote Endpoints could stall on corrupt Messages.
 * Can a Participant unmatch an Endpoint by marking it's announcing sequence number in a GAP message?
-* Is DEADLINE per-INSTANCE or per-INSTANCE-and-WRITER?
+* Is DEADLINE per-INSTANCE or per-INSTANCE-and-WRITER? (From the perspective of a reader)
     - It is per-INSTANCE
 * Only a sub-part of the DDS QOS are actually relevant for the RTPS. Should I remove the QoS Specifications from the RTPS Package?
 * What happens if we get a sample with a source timestamp earlier than the last sample that was accessed by the DataReader when using DESTINATION ORDER BY_SOURCE_TIMESTAMP? Is the sample dropped?
@@ -105,6 +105,13 @@
 * Testbench did not catch rtps_writer not sending HEARTBEATS if PUSH_MODE=FALSE & DURABILITY=TRANSIENT_LOCAL
 * DATA sent before first HEARTBEAT: https://github.com/ros2/rmw_cyclonedds/issues/367
 * If VHDL-2019 is used, we can use "conditional analysis statements" to see if we are in a simulation (see https://insights.sigasi.com/tech/what-is-new-in-vhdl-2019-part4/)
+* [2.2.3.12 TIME_BASED_FILTER, DDS 1.4] states:
+    "In the case where the reliability QoS kind is RELIABLE then in steady-state, defined as the situation where the DataWriter
+    does not write new samples for a period “long” compared to the minimum_separation, the system should guarantee delivery
+    the last sample to the DataReader."
+    We have to change the RTPS Reader to request the last SN, if the RTPS Writer did not publish for a minimum_separation period.
+* [8.4.7.1 RTPS Writer, DDSI-RTPS 2.3] states:
+    "nackSuppressionDuration = ignore requests for data from negative acknowledgments that arrive ‘too soon’ after the corresponding change is sent."
 
 * Fast-RTPS does not follow DDSI-RTPS Specification
     - Open Github Issue
@@ -131,12 +138,18 @@
         Add IDL Specification for CacheChange_t
     - 8.3.4 The RTPS Message Receiver, Table 8.16 - Initial State of the Receiver
         Port of UnicastReplyLocatorList should be initialized to Source Port.
+    - 8.3.7
+        "Contains information regarding the value of an application Date-object."
+            Shoulbe be Data-object
     - 8.3.7.4.3 Validity
         gapList.Base >= gapStart
     - 8.3.7.10.3 Validity
         'This Submessage is invalid when the following is true:
             submessageLength in the Submessage header is too small'
         But if InvalidateFlag is set, Length can be Zero. Since the length is unsigned, there cannot be an invalid length.
+    - 8.3.7.11.1
+        "Given the size of a SequenceNumberSet is limited to 256, an AckNack Submessage is limited to NACKing only those samples whose sequence number does not not exceed that of the first missing sample by more than 256."
+            Remove one not
     - 8.4.7 RTPS Writer Reference Implementation
         According to 8.2.2 the History Cache (HC) is the interface between RTPS nad DDS, and can be invoked
         by both RTPS and DDS Entities.
@@ -144,8 +157,9 @@
         the common HistoryCache.', implying that a DDS Writer adds changes directly to the HC, which is then
         read by the RTPS writer and handled accordingly. This means that the DDS Writer is responsible for
         assigning Sequence Numbers.
-        This goes against 8.4.7, which states that the RTPS Writer is adding the Cache Changes to the HC
+        This goes against 8.4.7 (and Table 8.5), which states that the RTPS Writer is adding the Cache Changes to the HC
         and is responsible for assigning Sequence Numbers.
+            - Well, according to the Virtual machine, the new_change() method is invoked on the RTPS Writer
     - 8.7.2.2.1 DURABILITY
         'While volatile and transient-local durability do not affect the RTPS protocol'
         But in case of Durability TRANSIENT_LOCAL the writer has to send historical Data.
@@ -175,13 +189,36 @@
         which means that the default value is 0.
 
 * DDSI-RTPS 2.5 ISSUES
+    - 7.4.1 The Structure Module
+        Figure 7.2 (RTPS Structure Module) does not correspond with actual RTPS Strucuture Module defined in 8.2 (Figure 8.1)
+    - 8.2.4.2 The GUIDs of RTPS Participants
+        The bulletpoints list seems malformed and makes no sense.
     - 8.7.10 Key Hash
         Wrong reference 9.6.4.3 (correct 9.6.4.8)
+    - 9.3.1.2 Mapping of the EntityId_t
+        Malformed bits in entityKind description
+    - 9.4.5.7.1
+        Should be "The value of the GroupInfoFlag" (instead of LivelinessFlag)
+    - 9.6.1 ParameterId definitions in the HeaderExtension
+        "[...] shall either skip and the parameter or reject [...]" (And is superflous)
+    - 8.2.1 Overview
+        Figure 8.1 should contain the RTPS Group Entry (it even has its own section 8.2.6)
+        It should also get an Entry in the Table 8.1
+    - 8.7.5 Group Ordered Access
+        "A DataReader attached to a Subscriber configured with access scope GROUP" should be Reader (RTPS), and not DataReader (DDS)
+            - This section has general incosistency in the use of the RTPS and DDS counterparts
+    - 9.3.2.5
+        IDL definition is missing the "EntityId_t" name in the struct definition
         
 * DDS 1.4 ISSUES
     - 2.2.3 Supported QoS
         Partition is marked as RxO=No, but should be RxO=Yes? Or not?
         -   Existing Issue: https://issues.omg.org/issues/DDS15-245
+    - 2.2.3 Supported QoS
+        OWNERSHIP is marked optional as a whole, but defines a default (SHARED) if unspecified (Since it is RxO)
+        Define only the values other than SHARED as optional (consistent with other QOS Policies)
+    - 2.2.3 Supported QoS
+        Under DURABILITY_SERVICE is states "And three integers:", while there are 4 integeres
     - How is History QoS affecting MAX_INSTANCES handling (if at all). When is an instance eligibale for 
       replacement.
     - 2.2.2.4.2.5 register_instance
@@ -357,9 +394,12 @@ DESIGN DECISIONS
     lead to inconsistent behavior (see REF.txt). RTI has thus decided to only delete unregistered 
     instances. I will copy this behavior.
     
-*   DATA WRITER: Once an instance is unregistered, it is eligible for deletion except if it is 
+*   !REJECTED! DATA WRITER: Once an instance is unregistered, it is eligible for deletion except if it is 
     Re-registered, or a write operation occurs on that instance. Disposal of an unregistered Instance
     does not re-register the instance (State remains NOT_ALIVE) and is still eligible for deletion.
+        NOTE:   The statement above is incorrect, as a writer wanting to dispose an Intsnace has to re-register
+                the Instance. Hence, it is re-registered (and the disposing writer is again active), the state
+                Instance remains howerer in a NOT_ALIVE state.
     
 *   The DDS Specification does not explicitly state that the behaviour of the Register/Unregister/Dispose
     Operations have on non-keyed Topics. RTI basically does a NOP and does not modify the instance in 
@@ -382,8 +422,12 @@ DESIGN DECISIONS
     that it now has a live writer again. On the other hand there is no transition from NOT_ALIVE_DISPOSED
     to NOT_ALIVE_NO_WRITERS.
 
-*   Unregister/Filtered Samples of unknown Instances are droped. On the other hand, Dispose Samples of
+*   Unregister/Filtered Samples of unknown Instances are dropped. On the other hand, Dispose Samples of
     unknown Instances are accepted (Implicitly adding the new Instance).
+        NOTE: According to [2.2.2.4.2.13 dispose, DDS 1.4]
+            "In general, applications are made aware of the deletion by means of operations on the DataReader
+            objects that already knew that instance. DataReader objects that didn't know the instance will never see it."
+            So I think this has to be changed to also drop Dispose Samples of unknown Instances.
 
 *   The DDS Specification is not entirely clear on what happens in the DDS Reader on reception of 
     Meta Samples (Unregister/Dispose Samples). One simple solution would be to make Data-less Samples for 
@@ -408,7 +452,7 @@ DESIGN DECISIONS
 *   MUTABLE extensibility is currently unsupported, as the PL_CDR encoding needs to be able to dynamically
     calculate the sizes of type members, which was deemed to complicated.
 
-*   Similar to the previosu decision, only optional members with fixed size are supported (Since the optional
+*   Similar to the previous decision, only optional members with fixed size are supported (Since the optional
     members need a parameter list header, which has a length field).
 
 *   The RTPS Writer is only sending GAPs when processing ACKNACK Requests or sending Historical DATA.
@@ -420,7 +464,7 @@ DESIGN DECISIONS
     This means that a Reliable RTPS Writer in PUSH_MODE = FALSE cannot communicate with Best Effort Readers.
     Historical Data is also only sent out on request (But NACKed in the HC, until the remote Reader ACKs them).
 
-*   Where as the DDS Writer/Reader are flexible in the handling of variable sized Payloads - they write the
+*   Whereas the DDS Writer/Reader are flexible in the handling of variable sized Payloads - they write the
     payload in multiple memory slots, effectively eating away from the MAX_SAMPLES limit, since there are 
     only MAX_SAMPLES memory slots avialable - the decoding in TYPENAME_interface requires and explicitly 
     enforces absolute maximums for all Type members. Those upper bounds are either explicitly defined in