Re: [certi-dev] Keep getting FederateAlreadyExecutionMember

[Monday Morning]

> My answer is going to vary because I'm on holiday with more time [than
> usual] away from the keyboard.

Of course, France stops in August!

> you should be able to find some woikring examples on 1516 federate in:
> http://cvs.savannah.gnu.org/viewvc/applications/HLA_TestsSuite/?root=certi

Thank you for that and I now see that HLA 1516 has a very different
API (I was under the impression changes were minor) which explains all
the errors. I will try to re-write my examples in 1516.

As an aside, one problem I've noticed with 1516 is that object handles
are now first-class objects rather than simple numbers as before. I
don't know how this maintains compatibility with HLA13.
For example, in the RPR FOM, the Designator which is an Object, has a
"DesignatedObjectIdentifier" attribute. The RPR FOM docs say that this
does not need to be set, but suppose a designator points at an object
and moves off, then how to go about unsetting the object? Does HLA
1516 mind if an invalid handle is passed in? I suspect that .encode()
just throws an exception.

> IEEE-1516 2010 has some new "failure tolerance feature", that said the failure
> tolerance for a 1516 or 1.3 RTI depends on the RTI itself, CERTI
> hasn't been much concerned with fault tolerance so no features in this area 
> were
> implemented.

Essential in my view. I might claim to have never been involved in a
large simulation where somebody hasn't crashed. Restarting the RTI is
possible (as it stores no data) but not really desirable.
Can't the RTI just delete all objects that are owned by that
particular Federate when that Federate's connection is dropped?

Regardless, my problem was that even disconnecting cleanly causing
problems with CERTI if that application tries to reconnect.


Thank you for your time, and I will continue with 1516.