Portico is an open source, cross-platform, fully supported HLA RTI implementation. Designed with modularity and flexibility in mind, Portico is a production-grade RTI for the Simulation and Training Community, so come say hi!
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.
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.