MomManager not able to cope with 1516e-style names

[timpokorny]

The MomManager is responsible for handling Portico MOM related requests (defined in the MIM when talking in 1516e terminology).

In HLA v1.3 this part of the FOM was standardized with a certain set of names for classes, attributes, etc... In 1516 (and 1516e) the standard group changed all the names. On federation creation, Portico is now throwing NPE's when it attempts to register an instance of Manager.Federation. The problem is that this class doesn't exist in the standard 1516e MIM, but HLAmanager.HLAfederation does. So, fetching by the v1.3 name returns null and Portico then tries to use that to instantiate from, hence the NPE.

I thought I had fixed this in the 1516 interface with a name translator. Regardless, it isn't happening in 1516e yet and this needs to be fixed.

Glance estimate of 2h to fix and write a couple of unit tests. It'll get fixed pretty easy, but tests are required to validate it for future regression testing.

[timpokorny]

Trying to put proper 1516e support in now for #162 and getting this crash.

Name resolver currently updated to work happily with 1516e names, but this is causing the problem. When the LRC goes to work to create the various MOM bits and pieces, it is looking up the handles to use by the name Manager.Federate and Manager.Federation. Not valid in 1516e (or 1516 for that matter).

Updates to the data creation and updating process needed in the MomManager and associated classes.

[timpokorny]

Working through this - it is not simple.

Currently stuck on the insertion of the MOM into 1516e federations. The ModelMerger which merges all modules works fine in that it correctly identifies with the MIM isn't present and adds it (or does nothing if it is present). However, the problem is that it is then getting allocated handles as per any other class in a FOM (starting at 500 and moving up). The MOM is meant to get handles under 500 as a special type of class. Subsequently, when we come to get updates later, the MomManager is parsing the requested attributes to update and it doesn't recognise any of the handles.

Only two ways around this:

1. Change the way MOM insertion works for FOMs
2. Update, somehow, the manager to dynamically initialize its handles so that it isn't looking up on hard-coded numbers

While the second seems to make a bit of sense, it was done this way for clarity and consistency, so I am a little apprehensive.

The allure of rewriting MOM support from scratch to be version-specific is getting stronger, especially because after this problem I still have the issue of different encoding rules across the versions that I have to deal with somehow, and it's going to get messy when I jam that all into the one central place. Separate implementations per-version would be nice (but would fail in mixed version federations). Thinking cap time.

[icemagno]

What if you break Pórtico in legacy and Evolved versions? Em 19/01/2016 14:43, "Tim Pokorny" notifications@github.com escreveu:

Working through this - it is not simple.

Currently stuck on the insertion of the MOM into 1516e federations. The ModelMerger which merges all modules works fine in that it correctly identifies with the MIM isn't present and adds it (or does nothing if it is present). However, the problem is that it is then getting allocated handles as per any other class in a FOM (starting at 500 and moving up). The MOM is meant to get handles under 500 as a special type of class. Subsequently, when we come to get updates later, the MomManager is parsing the requested attributes to update and it doesn't recognise any of the handles.

Only two ways around this:

1. Change the way MOM insertion works for FOMs
2. Update, somehow, the manager to dynamically initialize its handles so that it isn't looking up on hard-coded numbers

While the second seems to make a bit of sense, it was done this way for clarity and consistency, so I am a little apprehensive.

The allure of rewriting MOM support from scratch to be version-specific is getting stronger, especially because after this problem I still have the issue of different encoding rules across the versions that I have to deal with somehow, and it's going to get messy when I jam that all into the one central place. Separate implementations per-version would be nice (but would fail in mixed version federations). Thinking cap time.

— Reply to this email directly or view it on GitHub https://github.com/openlvc/portico/issues/55#issuecomment-172912316.

[timpokorny]

G'day mate - that is what I am considering, but it has two implications:

1. Will take more work (although be simpler in the end)
2. The current approach tries to make it agnostic, so 1.3 and 1516x federates can mix in the same sim and all use the MOM in their own appropriate way

I like the idea of the second point, just the current way it is done is a bit brittle. Decision time!

[timpokorny]

@icemagno After a long, long battle I believe the basics are now implemented. You will be able to subscribe to the HLAmanager.HLAfederate and HLAmanager.HLAfederation classes and get discover/remove notifications when federates come on and off line.

Some notes:

• Most of the attributes are not supported and will have dummy values, but the core ones are supported.
• You will have to use the Encoding Helpers in hla.rti1516e.encoding to deserialize the information
• Currently this is only on the port55-mom1516e branch.

Once the build system tells me everything is cool I will merge into master. From there, it will be available around 5am the following morning in the latest nightly build, or you can build it from source yourself to test and confirm.

[timpokorny]

And it looks like the build has already failed. SIGH! I will go back and take a look tomorrow morning to see what is wrong.

[timpokorny]

Miracle of Miracles I think they pass now.

[timpokorny]

OK, I have pushed this to master and it will be in the next nightly. Please just comment and we'll reopen if I have missed anything!

[icemagno]

Hi Tim, "You will be able to subscribe to the HLAmanager.HLAfederate and HLAmanager.HLAfederation classes and get discover/remove notifications when federates come on and off line."

It's enough for me by now. I just to know when a Federate crashes to kill all ghosts from my Federation..

I'll try ASAP and tell you the results.

Thanks. Carlos Magno Abreu Brazilian Navy