[certi-dev] FW: RE: using CERTI as a fgms replacement?

[Gotthard, Petr]

FYI, here is a test-report concerning running the FlightGear-plugin with 
various CERTI versions.

I very glad that these tests have happened. I believe the following CERTI 
issues can be drawn from this report:

(1) protocol compatibility checks
The CERTI protocol changes and RTIA/RTIG/federates running different CERTI 
versions are very often incompatible. To avoid incompatibility problems in a 
geographically distributed environment, introducing CERTI protocol versioning 
and compatibility checks is critical.
https://savannah.nongnu.org/bugs/index.php?24854

(2) federation problems when a federate is joining/leaving/failing
The need to restart the server is related to unnability of RTIG to detect RTIA 
crash.
https://savannah.nongnu.org/bugs/?23746
I will do more testing once I fix all FlightGear-plugin bugs.


Petr

-----Original Message-----
From: address@hidden
To: "'Oliver Schroeder'" <address@hidden>
Sent: 17.11.2008 01:04
Subject: RE: Re: using CERTI as a fgms replacement?

Oliver,

Thank you for forwarding this. Anders Gidenstam, Jon Stockill, Csaba Halász, 
and I have been carrying out some testing over the last few days with mixed 
results. This is a short report on our findings.

I was running Windows XP (SP2) with MSVC9 (SP1). The remainder, various 
flavours of Linux. We all downloaded and installed the FG patch without 
difficulty. I downloaded the pre-cooked MSVC version Certi 3.3.0. This installs 
and runs. It seems to run "Billards", but since nothing actually happens, it is 
hard to tell if this is actually correct. Anders ran rtig, and I attempted to 
connect. This appeared to happen correctly. The setting was 
--hla=10,NAVY400,VirtualAir. The VirtualAir FOM appears to be a good basis for 
developing our own federation. We noted that the frame rate at KSFO was around 
9 using the Seahawk. This is about half that which we would expect with 
MultiPlayer (MP). So far so good. However when any other client attempted to 
join, the Windows client throws an error and RTIA stops in
SocketUN.cc: 

        line 460 - throw NetworkError("Error while receiving UN message.");

This stops the RTIG server, and this in turn stops all clients. Linux clients 
do not seem to experience the first stop, but the Windows client stop brings 
down all other clients. This effect is also seen when a Linux client leaves the 
network which stops all other clients. This requires that the server is 
restarted. 

We thought that this might be down to an incompatibility between versions of 
Certi, so we decided to try Certi 3.3.1. I downloaded the pre-cooked version of 
3.3.1 MSVC. This appears to be terminally broken as has already been reported 
on the Certi devel mailing list. I downloaded the cvs version of 3.3.1, and 
after a bit of fiddling with the dependencies, built that version under MSVC9. 
The result was the same as for version 3.3.0. 

We then repeated the tests with rtig run by Jon, with the same results.
Next, I downloaded and built cvs-head, and tested that with Jon; same results.

Finally, I ran 2 instances of FG on my machine with Certi 3.3.0. Same result.

In summary:

- The frame rate hit is excessive and unacceptable.

- Certi Windows client fails if any client (Windows or Linux) joins the net.

- Linux clients fail if any client leaves the net

- Any exit from the net stops RTIG which stops all clients.

- HLA seems to introduce stagger into the FG frame rate.

Recommendations:

- To be usable in FG HLA must not have a greater effect on frame rate than MP, 
and preferably less.

- HLA must not introduce stagger into FG.

- The RTIG server must not be affected by clients joining or leaving the net, 
or failing.

- Clients must not be affected by the failure of the RTIG server.

- Consideration should be given to running HLA in its own thread.

- Certi must be multi-platform, and proved to be so. 


Conclusions:

- HLA shows good promise, but in its current state cannot be considered to be 
fit for inclusion in FG.

Finally:

- We wonder if Certi has actually been tested under Windows? We look forward to 
testing HLA again once at least some of the shortcomings have been addressed.

Vivian


> -----Original Message-----
> From: Oliver Schroeder [mailto:address@hidden
> Sent: 10 November 2008 08:38
> To: Vivian Meazza
> Subject: Fwd: Re: using CERTI as a fgms replacement?
> 
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Re: using CERTI as a fgms replacement?
> Date: Thursday 09 October 2008
> From: "Petr Gotthard" <address@hidden>
> To: address@hidden
> 
> Hi Oliver,
> 
> >On Mittwoch 08 Oktober 2008, Petr Gotthard wrote:
> >> So: If the HLA standard is able to support all features you planned 
> >> for
> the
> >> new fgms, then I think HLA/CERTI would be a good replacement. Even
> though
> >> the current CERTI version might not have required features and
> acceptable
> >> quality, I think having a standartized multiplayer is worth the effort.
> >
> >The most important things are:
> >- define which properties are to be sent (there are attributes which 
> >are aircraft specific, eg. a helicopter uses different properties 
> >then an
> >airoplane)
> 
> Possible, but the concept is different. The HLA uses a FOM (Federation 
> Object
> Model) concept. Each FG property more-or-less corresponds to one 
> attribute in the FOM. Many of the attributes are standartized to 
> assure compatibility between different simulators.
> The FOM most suitable for FlightGear is here:
> http://www.aviationsimnet.net/ASN/doc/aviationsimnetV3.1.html
> 
> Anybody is allowed to define own attribute, so basically any property 
> can be transported.
> 
> >- define conditions for when a property is sent, eg. there are 
> >one-time properties (like the aircraft in use), "on-change" 
> >properties (like flap settings or speed-settins) and "always" 
> >properties (like position and
> >orientation)
> 
> Possible, but out of scope of HLA. Each object (e.g. Aircraft) has a 
> set of attributes, but only a subset may be updated. The simulator may 
> decide (based on whatever condition) to send any values it likes. The 
> HLA (reliably) delivers all attributes that were sent.
> 
> >- define which client gets what properties. Eg. a "normal" client 
> >does
> not
> >need to get position data of an ATC client, but needs to get the ATC
> chat.
> 
> Possible. Different objects may subscribe to different attributes. 
> Only the subscribed attributes are delivered. Moreover, you can define 
> an "observed region" in space, so an aircraft gets position of its 
> neighbors only, while a simulation monitor may receive (the 
> subscribed) information from all aircraft.
> 
> >I guess those are the most important features. Everything else, as 
> >listed
> in
> >your list like authentication etc., can be added when needed.
> >
> >Of course there are a few nice-to-have features, too. Like 
> >interconnected servers (CERTI instances) which exchange data.
> 
> Possible, but out of scope of HLA. The interconnected servers may 
> implement any sophisticated data distribution algorithm they like. 
> However, the current CERTI implementation doesn't support any 
> distributed data delivery.
> 
> >And one thing that makes me suspicious is the lack of free and public 
> >available documentation about HLA.
> >
> >Perhaps you have some pointers for me?
> 
> The documents are here. The HLA 1.3 documents seem to be freely 
> distributable (although no longer officialy distributed by DMSO). More 
> details in my previous e-mail this morning.
> http://sslab.cs.nthu.edu.tw/~fppai/HLA_Documents.htm
> 
> If you're interested, I recommend you to read the HLA 1.3 Programer's 
> Guide first. It's the best introduction available. The IEEE standards 
> are usable only as an expert reference.
> 
> Regards,
> Petr
> 
> 
> 
> -------------------------------------------------------