Re: [certi-dev] RTIG process behavior

[Eric Noulard]

2013/5/9 Gilles LASNIER <address@hidden>:
> Hi everybody,
>
> I'm Gilles Lasnier, postdoctoral researcher at ISAE/Supaero. I'm currently
> extending the PtolemyII simulation tool to make it interoperable with a
> HLA/CERTI Federation.
> I already finished a first implementation and developped demos about this
> work. They are available on the PtolemyII svn tree. I'm visiting the
> University of California Berkeley right
> about this project and to finish its integration.

This is very good news.
If you provide me with the appropriate URL I may add it to the list of
"External CERTI related projects" h which may be found there:
http://www.nongnu.org/certi/

>
> The Ptolemy team asks me to simplify the deployment phase for the user and
> to automatize the lunch of HLA demos from Ptolemy models (one Pt. Model =
> one federate) including the launch of the RTIG. A part of this
> implementation is already done but I have some difficulties to shutdown the
> RTIG correctly from the model that has launched the process.
>
> In some case I get an exception from the other federates. It appears that
> the simulation terminates correctly but sometimes the RTIG is killed before
> the other Federates are able to leave the federation.
>
> So, I'm wondering it there is a way to allow the RTIG to finish its
> execution after the destruction of a federation (maybe based on argument
> options, etc...).
>
> Any ideas or suggestions are welcome.

Here comes some explanations and thoughts:

  1) RTIG is not meant to be stopped once launched it is a pure
reactive process.

  2) RTIG may possibly handle "multiple federations" so that one cannot
      automaticllay end it when 1 federation is destroyed, we "may"
      add a command line option to stop it when the
      LAST one is destroyed. This kind of approach is subject to
distributed races if some
      concurrents process create / destroy federation at the same time.

  3) It should be easy to add command line option to RTIG executable
      in order to support optional behavior as soons as the default behavior
      is backward compatible.

  4) We could add specific [Network] messages and/or API
      between Federate/LibRTI and RTIG:
       - One which would test whether RTIG is running and alive
         ready to create federation. Currently this done when RTIAmbassador
         gets created and one gets an RTIinternalError Exception because
         Federate/LibRTI cannot connect to RTIA because the later failed
         to connect to RTIG (if it is not running).

       - Another one which would ask RTIG to terminate.
         NB: we already have OPEN_CONNEXION, CLOSE_CONNEXION
                which are used between Federate/libRTI and RTIA
               but those do not propagate to RTIG.

Those API will be non-standard w.r.t. HLA 1.3 or IEEE-1516-2000 or 2010
so if we introduce those we should try hard to remain DLC compatible
(see http://www.sisostds.org/ProductsPublications/Standards/SISOStandards.aspx
   SISO-STD-004-2004, SISO-STD-004-2004.1)

Whatever the solution remember that libRTI/Federate do not even know
the existence
of RTIG, if we implement (some day) a fully distributed RTIG
(decentralized RTI)
the Federate shouldn't be changed.

Anyway on my side any patch proposal will be seriously examined, just put it
on the patch tracker:
https://savannah.nongnu.org/patch/?group=certi
and start a discussion here on the ML about the patch.



--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org