Each HLA object must have an object name that is unique throughout the federation execution. When an object is registered, the federate can provide a name or let the RTI supply an object name. In the HLA 1.3 specification, when the federate supplies the name, it is up to the federate to make sure that the name is unique. If it isn’t, the RTI throws an exception. The HLA 1516 specification lets you reserve names to ensure that they are unique.
By default, the VR-Link publishers perform name reservation and object reservation at the same time - when the publisher is created. The name reservation process requires a round trip handshake between the local RTI component (LRC) and the rtiexec. Therefore, performing it just before an object is registered can delay the object registration process. If the federate is simulating a limited number of objects that are created at start up, this overhead is negligible. However, if the federate is creating many 100s of objects or if an object is being created in a time critical fashion (say a missile fly out), the delay caused by name reservation can become significant. One way to avoid the name reservation delay is to perform the name reservations ahead of time before the objects are registered. VR-Link can do this. (continued...)
To reserve names in advance, your VR-Link application needs to make name reservation calls. If the calls are performed through the exercise connection, the results are cached. When an object publisher is created, it first checks to see if the name is already reserved. If so, the name reservation call is skipped. We have a code snippet that shows how to do this, but it is a bit too long for this blog. We have put it on the MÄK Community Forum in the Link-Interoperate section. If you want to see the code and a somewhat more detailed explanation of this issue, click here!