If the payload is not directly aligned with the Payload slots, it has
to be ensured that the rest of the payload slot is zeroed.
If we ran out of payload slots during the write process (Which can
happen since we don't know the size of the payload beforehand), we have
to abort the Key Hash Generation before parsing the next sample.
The rtps_endpoint only sends the source timestamp (TIME_INVALID if no
source timestamp provided). If ordering BY_RECEPTION, the sample is added
to the list tail. If ordering BY_SOURCE the samples are ordered
according to the source timestamp, but droped if the source timestamp is
earlier than a sample that has been read by the user or INVALID (Ensures
determenistic behavior).
Finalized DDS Reader interface. Implemented read/take,
read_next_sample/take_next_sample, read_instance/take_instance,
read_next_instance/take_next_instance operations.
Instance Get operations were made generic to allow returning 2 variants
of instance data.
in order to support the read_next_instance/take_next_instance
operations, the instances have to have a a logical order. Whie the
previous implementation did have a logical order for inserted instances
(Since they are added in a linked list), we need to support relative
ordering also for non-inserted instances (acording to DDS Spec), so we
just order them in ascending order.
Generation Counters are always needed (e.g. for the calculation of the
view_state, since they are dependent on the reading of samples of the
last generation). As such, the Generation Counters were "converted" to
mandatory fields.
It was decided to connect the DDS Endpoint directly to the RTPS
Endpoint. The history_cache Entity will be converted to a generic
History Cache acording to the RTPS Specification.
Because of consistency requirements the implementation was changed to a
single process/single port RAM design.
This should fully (blindly) implement the RTPS Reader side of the DDS
Entity.
