Ensure that Time Constrained federates receive messages in timestamped order #323
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Page 21 of the HLA standard defines timestamp order (TSO) as the guarantee that if two messages M1 and M2 have timestamps T1 and T2, then message M1 will always be delivered to a time-constrained federate before message M2 if T1<T2.
At the moment, timestamped messages can be polled from the LRC Message Queue as long as their timestamp is lower than the time the federate has currently requested to advance to. However, there is no guarantee that the federate might not receive a message with a lower timestamp than this later on, since the federate might request to advance to an arbitrary timestamp, and other federates might have a smaller lower bound on timestamp than this.
The CRC currently maintains a federation wide lower bound on timestamp. If the LRCs were aware of this, they could make sure to only return messages with a lower timestamp than this, meaning no new messages with a lower timestamp could be added later. This would guarantee that all messages are delivered in timestamp order.
This pull request adds a message class to broadcast the federation LBTS to all LRCs whenever it changes. The federation LBTS is recalculated each time a federate requests to advance, so some code was added to broadcast this message whenever the LBTS changes. The LRCs receive the broadcast message and store the current federation LBTS in their LRCState, and can then check against this whenever deciding to return a message from the TSO queue.
Possible bug: There are other places in the code where the federation wide LBTS is recalculated. These do not currently trigger an LBTS broadcast message.