Re: [certi-dev] CERTI - Move to HLA 1516

[Eric Noulard]

2010/1/8 Gotthard, Petr <address@hidden>:
> Hi again,
>
> First of all, it's great that you consider CERTI as a possible
> replacement for your RTI. I'll try to answer some questions from my
> perspective.

+1

>> I was wondering if you could give your estimate on how much work it
>> would actually be to implement the 1516 interface for CERTI.
>
> The HLA 1516 functions that are similar to HLA 1.3 and implemented in
> CERTI RTIA/RTIG can be implemented quite easily. I believe most of your
> "high priority" services are in this category.
>
> I'd guess ~1 month (full time) for an experienced C++ developer that
> knows the basic IEEE 1516 behaviour but doesn't have experiences with
> CERTI. (It's a great HLA training exercise.)

I do agree with Petr on that time evaluation, however I may add some
1/2 week startup time for a new-comer in CERTI base code.


>> Is this something that someone with only basic HLA knowledge would
>> be able to do?
>
> The "easy services" yes. The "not so easy services" like name
> reservation would require some help from the experienced CERTI
> developers, but they're always very helpful. :-)

[talking as CERTI core team]
Thank you for that we try to be :-)

We usually do our best to help contributors.
Some initial new comers (Christian, Petr, Mathias to name a few) did get
enough knowledge of CERTI internals to provides very good patches
for bug fixes or new feature in a limited time range.

I may not speak for them regarding their timeline for startup time,
but I'm pretty sure good willing developer will be efficient in
a reasonable amount of time (1/2 weeks).

And for sure we will help to boost the startup time with hopefully
valuable answers to questions.

>> Furthermore, are they also other parties interested in working on this
> task?
>
> I'm interested, but currently able to perform only minor tasks.

We are. But we nevered secured enough full-time activity on this
in order to be able to do it.
I will definitely help people wanting to do this.

>> Also, how would you broadly envision such an implementation?
>
> This was discussed here:
> http://lists.nongnu.org/archive/html/certi-devel/2008-10/msg00009.html
>
> There should be both 1.3 and 1516 interfaces. As there is a socket
> interface between libRTI and RTIA, the 1516 specific modifications can
> be limited to the libRTI1516 only. Ideally, the RTIA/RTIG will be able
> to serve both 1.3 and 1516 without recompilation.

Right, If we need Standard (either 1.3 or 1516) specific messages
we may make the RTIA/RTIG handle that at the message level.

There is a small sketch of the current CERTI architecture here:
http://www.nongnu.org/certi/certi_doc/User/html/execute.html

Basically each Federate has an RTI-proxy process named RTIA
(RTI Ambassador) while RTIG (RTI-Gateway) handles a set
of federation. Thus the Federate<-->RTIA<-->RTIG.

Federate communicates with RTIA using a Socket.
RTIA communicates with RTIG using a Socket.

> I hope some of the CERTI experts will add their comments later.

The communications between CERTI components Federate(libRTI), RTIA, RTIG
is message based such that adding a new service usually means defining
a new [set of] message or modifying existing ones.

Adding 1516 does not look like a *difficult* task but it should require
some reasonable amount of full-time work because some initial work
may not be splitted easily.

One the first effort
- Setting up build systems for 1.3 + 1516
- Basic Federation functionality (create, join, destroy)
- Object management (create, discover, update, etc)

is done, other tasks may be done as part time long term work.

Note that the developer should have some knowledge of
"portable development" since CERTI is currently running on
a fair amount of platform (Windows, Linux 32/64, Solaris etc...)
and we must keep it this way.

Another needed knowledge will be the use of CVS or may be GIT
if your are wanting to have a git-cvs-imported cloned source tree.

We do help developer to do their work on dedicated CVS branch
(created on purpose) in order to make it easy for them to do
their work while we integrate the change on the trunk.

I don't really know what to add, ask any question you have
and we'll answer the best we can.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org