search

openlvc / portico

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!
http://www.porticoproject.org
151 stars 81 forks source link

Loading FOM on Federation Join Results in Inconsistent Handles for attributes/parameters #293

Open adlaws opened 5 years ago

adlaws commented 5 years ago

(NOTE: possibly related to, or will be solved by #275)

TL;DR Two federates loading identical FOM modules at the point of the federation join seems to result in consistent handles for interactions and objects, but inconsistent handles for the parameters and attributes associated with them.

The same problem does not seem to occur if the federates load the FOM at federation creation.

Longer Story... The full setup is a federation "coordinated" by a federation manager, which is just a federate which starts up before everything else, creates the federation and then issues special "control" interactions to the other federates in the federation.

The federation manager doesn't need to know anything about what the other federates publish or subscribe to. It only cares about the "control" interactions SimEnd, SimPause, SimResume etc interactions which it publishes (it doesn't subscribe to anything).

The other federates under the control of the federation manager do need to know about these control interactions (which they will subscribe to), so these interactions are "core" to the entire federation.

So when the federation manager starts up and creates the federation, the "core" FOM is loaded.

Once the federation manager has started and created the federation, the other federates may be started. When they "join" the federation, their FOMs (with their specific interactions and objects) are loaded .

This all initially seems to work, and the interaction and reflection handles are all consistent between the federates.

However the handles for the parameters and attributes of those interactions/object between the federates do not seem to be consistent.

To elaborate, imagine there is a Ping interaction with various parameters defined in the FOM loaded by both federates at join. One of the federates publishes a Ping interaction, the other side subscribes to Ping interactions.

The publishing of the Ping from one federate and receipt of the Ping by the other federate works correctly. The interaction is correctly recognised as a Ping on receipt (by the handle).

However the handle for parameters on the Ping interaction don't appear to match on either side. The handle for parameter someInteger on a Ping on one side might end up being the handle for parameter someDouble on the other side. This makes it impossible to reliably extract data from the interaction's parameters.

As a quick explanatory diagram:

+-------------+-------------+
| Federate A  | Federate B  |
+-------------+-------------+
| Ping (h123) | Ping (h123) |
|   anInt(h1) |   anInt(h2) |
|   aDbl (h2) |   aDbl (h3) |
|   aStr (h3) |   aStr (h1) |
+-------------+-------------+

...which hopefully makes sense.

The same is true for objects and attributes.

The issue is somewhat hidden if there is only one parameter /attribute on an interaction/object. If there are multiple parameters with the same type the problem is still there but less apparent (decoding doesn't fail because the types match, but the extracted value is from the wrong parameter/attribute).

As mentioned at the top, the problem can be "fixed" by having the FederationManager load all the FOMs at the point of creation of the federation, rather than at join time.

icemagno commented 4 years ago

I think all common stuff must be loaded by the first one to came.