Re: [certi-dev] CERTI-Devel Digest, Vol 64, Issue 1

[Eric Noulard]

2011/8/11 Monday Morning <address@hidden>:
> Eric, thank you for your prompt response.

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

>>  1) Which version of CERTI are you using on which platform ?
>
> The latest, on Win32 (XP) using supplied installer.
>
>>
>>  2) Which binding do you use
>>        C++ HLA 1.3
>>        C++ IEEE-1516
>>
> My include files are simply
>
> #define RTI_USES_STD_FSTREAM
> #include <RTI.hh>
> #include <NullFederateAmbassador.hh>
> #include <Enums.h>
>
> Which I think means I am using C++ HLA 1.3. Ultimately I want to
> support 1516, but my attempts to include any of those files were met
> with hundreds of errors.

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

>>
>> Some generic answer:
>>  - 2 separate federate of the same federation shall not have the same name
>
> I know this, and they never attempt to connect two federates of the
> same name, except when one reconnects again after resigning.

Ok I see.

>>
>>  - If a federate did not resign currently CERTI does not resign it by
>> some timeout mechanism
>>   even less destroy the federation, this is a implementation choice
>> however I'll check HLA
>>   document in order to this what is told about that case.
>
> This might be why all simulations I've seen using HLA have been
> 'flaky' at best. A federate might crash, and then all other
> simulations will have out-dated objects.

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.

Since CERTI is an Open Source user-need driven project if more user are wanting
failure tolerance feature then may it will be implemented by some of
CERTI developer community.

> With DIS, if things go badly wrong you only have to wait 12 seconds
> and it all sorts itself out, normally quicker (12 second timeout for
> DIS state PDU).
> With DIS simulations I've seen regular applications crashing and
> issuing of NaN for number fields (these really screw up filters). Both
> of them can be normally fixed by restarting the application, but that
> relies on the RTI refreshing the object list.
>
>> This should be a bug I'll try to see if I can reproduce this.
>> Do you get the very same error in this case?
>
> I have written an example program, code included at the end.

I'll try it when I get some time on the keyboard :-]
Th best way to report suich "possible bug with example" is to open a bug entry
in the  tracker
https://savannah.nongnu.org/bugs/?group=certi
and attach the example.

(if you create new bug report it's better to open a Savannah account
(it's free) and
 log-in before reporting, that way you'll get automatic follow-up
messages concerning the bug
 and we do not forget some mail message in the e-mail holiday pile :-].

Providing such example files is very kind and helps a lot to reproduce problems.
[...]

More feedback about your problem when I have time to test this.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org