Re: [certi-dev] FlightGear FOM / Java interface

[Eric Noulard]

2009/5/27 Martin Spott <address@hidden>:
> Eric Noulard wrote:
>
>> In fact the idea to chose the frontier between binding at the socket level,
>>
>> either Federate<->RTIA
>> or RTIA<->RTIG
>>
>> will really ease portability. We "only" have to describe the CERTI
>> Message protocol (either NetworkMessage or Message)
>
> /me trying to make sure I get the terms right while following your
> discussion:
> "Message" is Federate<->RTIA via Socket (or TCP) and "NetworkMessage"
> is [whatever]<->RTIG, aka "the wire protocol" !?
>
> As far as I understand the current approach of #6905, this is primarily
> about running the same RTIA locally as with the C/C++ client and to
> connect to the RTIA from a Java-implementation of the HLA API instead
> of implementing the wire-protocol in Java and connectig directly to the
> RTIG. Right ?

Yes.

The fact is "wire-protocol" is two-fold with CERTI:

    1) RTIA <--> RTIG, those are called NetworkMessage because
         the communication is message-based and goes through a TCP
socket, in order
         to makes it possible to run RTIG on a different hosts than
your federate.

    2) Federate <--> RTIA, those are called Message because
         the communication is message based but goes through a "local" link
         which used to be a Unix Socket, but was initially designed
for being usable
         with shared memory or other "local".
         "Local " meaning Federate and its RTIA sibling are running on
the same machine
         in fact the RTIA sibling is forked by the Federate itself.

This is due to the CERTI architecture choice.

RTIG is a unique standalone process, aka RTI Gateway.
RTIA is a child proxy process for each federate.

The  current approach of #6905 is to re-use the RTIA executable
(which may be launched by the Java libRTI interface) then implement
the Federate <--> RTIA wire protocol.

In this case the RTIA should be launched (from within Java) using
-p argument which tells the programs which **TCP** port to use.

We don't need such argument in the Unix case because the process is forked
and Federate and RTIA uses Unix Socket (which are not available in Java).

It's less work to implement Federate <--> RTIA wire protocol because
you do not have to re-implement the RTIA itself.

It's not "that" less portable because RTIA executable runs on many platforms.

The solution does not need mixed C++/Java programming because
the java version of the libRTI will be 100% java, using TCP socket to
speak with the C++ RTIA.

The "only" drawback of this approach is that you have to launch an external
program (RTIA) from Java, this is done with java.lang.Runtime.exec
family of standard java functions:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#exec(java.lang.String)

I'll try to get a copy of the student intnership report, but I think
it is written in french :-(
-- 
Erk