Re: [certi-dev] RTIA shutdown

[Eric Noulard]

2010/12/1 Michael Raab <address@hidden>:
> Hi all,
>
> I'm wondering what is causing the RTIA process to shutdown.
> At the moment I call ResignFed and DestroyFed at the end of the simulation
> in each federate and then exit the appropriate simulation system.
> Sometimes RTIA quits, sometimes not. Ideas? Best practices?

The RTIA quits when it receives the CLOSE_CONNEXION message
from its federate, because of the endless loop in RTIA::execute()
which check for the
fm->_connection_state != FederationManagement::CONNECTION_FIN
condition.

Since there is no "Close Connection Service" in HLA 1.3 nor in IEEE-1516-200
(it comes in 1516-2010) currently we send this message in the
RTIambassador destructor.

The RTIA may finish itself if it detects a "NetworkError" when reading message
from its federate or RTIG. In that case it put itself in the
FederationManagement::CONNECTION_FIN state without receiving the
CLOSE_CONNEXION message.

So I see two possible reasons to the non-termination of RTIA:

1) The federate cannot/did not send the message because the
    destructor is not properly called ?

    Is your RTIambassador a plain object or do you do something like:
    RTI::RTIambassador* myRTIA = new RTI::RTIambassador();

    and [sometimes] forgot to call
    delete myRTIA;

    Note that even in case of crash or not nice termination
    of the Federate RTIA should properly stop because
    it must detect the network error on the Federate socket.

2) There is a race inside the RTIA endless loop which leads
    to a state where execute() is in a blocking state.


There may be some difference on Windows platform because the
socket used between RTIA and its Federate is a TCP
(its an Unix Socket on Unix :-]) so TCP socket may have some builtin
"delay" before being closed.

If you wait says 3-5 minutes after federate stopped
does the dangling RTIA terminates itself ?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org