Revise Publish-Subscribe Subsystem
As of now, each topic holds a list of messages, arranged in a ring buffer. Every time a new message is published, it is "appended" in that buffer, i.e. the oldest message is overwritten. While this method is very efficient implementation-wise, it has a mayor flaw: messages are ordered not by origin time of the content but the time when they are published. This may cause undesired situations, where the information carried by the next message in the buffer is actually older than the information of the previous one.
The proposed solution is to replace the ring buffer by a queue, similar to the one used by services in RPC interaction, but singly-linked instead of doubly-linked (from oldest to latest). Whenever a new message is published, the oldest element of the queue is detached (if no HRT subscribers are pending) and enqueued again according to the origin time set for that message. Therefore, the latest message should be checked first, because appending the element is assumed to be the most common case and computational complexity remains constant. If the newly published message holds an origin time older than the latest message so far, though, it should be enqueued, starting from the oldest message (not the latest). The reasoning behind this is, that enqueuing has linear instead of constant complexity, but old messages should be made available as soon as possible, because timing constraints like latency are most likely to be missed. Moreover, this method avoids the need for a doubly-linked queue since all iterating operations will move forwards.
With this approach, subscribers can still detect whether their last message has been re-used by checking the unique identifier as it is already implemented. Tracking of pending HRT subscribers can be a bit tricky, though, because a newly enqueued (not appended!) message may be in front or already behind the current "viewpoint" of a certain HRT subscriber. However, the message subsequent to the enqueued one already holds the correct counter of pending HRT subscribers, which can be set for the new message as well. The topic has to track the latest and the oldest messages (even if it has not even been used so far), so the oldest messages can be detached in constant time and a new message can be appended in constant time as well. In case the new message needs to be enqueued, the queue is iterated from the back (therefore complexity scales linear), so that there may be invalid (not yet used) messages first, followed by old messages (there may be 0, though) until the latest message at the end. Yet unused, invalid messages can be identified by an invalid identifier, as it is already implemented.