Re: Questions about CERTI usage and implementation

[Eric Noulard]

2007/10/15, Christian Stenzel <address@hidden>:
> Hello,
>
> today I started first experiments with CERTI.
>
> So first questions and remarks occured, perhaps anyone can answer:
>
> 1)
> Following situation:
>
> I call createFederationExecution(...). After a successful creation
> I call immediately destroyFederationExecution(...).
>
> The destruction of the federation after a successful creation
> generates the following error output in rtia:
>
> /*******************************************************************/
> terminate called after throwing an instance of 'certi::SecurityError'
> Abgebrochen
>
> RTIA has thrown NetworkError exception.
> Reason: Connection closed by client.
> RTIA: Staying active to destroy federation...
> ********************************************************************/
>
> rtig reports:
>
> /******************************************************************/
> Security Error : Message has a unknown origin.
> /******************************************************************/
>
> Should this be the expected behaviour?

Don't know but this seems a bug.
You could file it to the tracker
https://savannah.nongnu.org/bugs/?group=certi

Ideally you could attach  an example source file
to the newly created bug item.

> When I additionally join the federation and resign the federate from the
> federation the behaviour mentioned above do not occur.

>
> 2)
> The location of the fed-File have to be relative to rtig. In my opinion
> a relative path to rtia would be a better solution.

The fact is RTIG may well be running on a completely different host
than RTIA. In current implementation Federate ask for a file then
RTIA ask the file to RTIG which will send the file to RTIA.

This is MUCH easier to deploy than what we had before.
Before that everybody was loading the file (every RTIA AND RTIG)
but this scheme has several weakness:
   - RTIAs and/or RTIG could load DIFFERENT files
   - you have to deploy FED file on each host running either
     RTIA/federate and RTIG.

With the current scheme you only need to deploy a SINGLE fed file
on RTIG running site. RTIG will send the file (using specialized message).
to each Federate which join the federation.

Thus RTIG looks for the file

1) with the path specified by the Federate (named FEDid_name in source code)
      1.a) may be absolute
      1.b) may be relative to RTIG workdir.

2) Using CERTI_HOME env var, RTIG looks for:
     getenv(CERTI_HOME)+"/share/federations"+ FEDid_name

3) default (unix) installation place plus FEDid_name
    i.e.     "/usr/local/share/federation/" + FEDid_name

See
http://cvs.savannah.nongnu.org/viewvc/certi/RTIG/Federation.cc?root=certi&view=markup
for detail.

The CERTI_HOME scheme may not be powerful enough and we may implement
as CERTI_FED_PATH or something.
This is not a high in priority list though.

>
> 3)
> Is it still necessary to "spin" until the join of a federate is successful
> (like in Billard class)?

I personnally don't know,

Could you point us to source code in Billard sources files?
If you are talking about the code snippet:

while (!joined && nb > 0) {
        nb-- ;

inside Billard.cc

I'm not sure because I have not authored it but
the case where the join is NOT successful correspond
to RTI exception where the Federation does not exists YET

RTI::FederationExecutionDoesNotExist

because the first Federate to join will trigger federation creation
which may effectively "take some time".

other Exception cases seems FATAL and will through you out of the loop:
RTI::FederateAlreadyExecutionMember
RTI::Exception

> I know, that this was no more required for RTI1.3-NG, .  It was
> necessary when using RTI-1.3v6 or lesser because the creation of a
> federation
> needs some time. RTI 1.3-NG was ready to accept joining federates
> upon return from the createFederationExecution() invocation.

I agree the preceding scheme seems awkward,
may be someone can check if we can get rid of it?

-- 
Erk