OpenRTI

OpenRTI

An rti library with an rti1516, rti1516e as well as a RTI13 interface.

The key features are:

• Easy to use.
• C++ interface.
• (Java interface. No coding resources allocated yet ... hint)
• Extensible.
• In process RTI.
• Server tree hierarchy.
• Shortest path is in memory without copying data.
• Only depends on a c++98 compiler/stl or newer.

Installation

It's a usual cmake project.

Execute cmake from within a build directory of your choice, give this cmake the source directory, generate build files for your native build environment and compile the set of libraries/tests.

Specifically under a UNIX like environment:

cd <builddir> cmake -DCMAKE_INSTALL_PREFIX=<prefix> <srcdir> make make test make install

Specifically under windows using cl:

cd <builddir> cmake -DCMAKE_INSTALL_PREFIX=<prefix> <srcdir> cmake --build . --config Release ctest --build-config Release cmake --build . --config Release --target INSTALL

Or depending on your c++ compile environment, you may need to take different steps. For details refer to www.cmake.org.

Dependencies

The 'dependency only on a c++ compiler' in the key features table means more specifically that: The rti libraries and all tool programs like the server process rtinode that are required to run a rti, the client rti libraries as well as the complete test suite depends on nothing but a working c++ compiler and a usually included stl implementation. This aims to ease the installation and should keep potential collisions with respect to run time libraries possible required by the calling application at a bare minimum. OpenRTI requires at least an c++98 implementation, but can be compiled also with a c++11 compiler and stl library.

OpenRTI can make use of additional components like zlib for on the wire compression, that is used if it is available. OpenRTI's on the wire protocol negotiates if this is used or not. So, mixing different builds one with zlib and one without shall interact seamlessly. The python binding is obviously only available if python is available.

That said, much more specifically, there is no dependency on boost as of today and there will not be any in the future. The same goes for any other dependency library that is not strictly needed.

C++ language standard version

C++11/14 Should just work. Starting with cmake 3.1 you can enable use of an other standard version conveniently in the build system by setting the CMAKE_CXX_STANDARD cmake variable to an appropriate value. For example switching to c++11 can be achieved via adding the -DCMAKE_CXX_STANDARD=11 command line option to the initial cmake command. Consult the cmake documentation for more information on setting cmake variables.

Platforms

Everywhere! Seriously, if it does not work yet on your platform, please provide patches to make it work.

Development is done currently on Linux, Win32, MacOS and Solaris. HP-UX did work at some time in the past but is no longer tested.

Linux is tested on current fedora variants and centos 4, 5 and 6.

Windows is tested so far with 32 and 64 bits on XP with VS 2010/VS2012.

Macos X is fully supported starting with 10.6. Starting with this version a workaround for a problem originating from the standardized cyclic link dependency is available. On earlier macos versions OpenRTI triggers a race in resolving dynamic symbols from the logical time libraries. This problems shows up in a lot of the tests for OpenRTI. For single threaded HLA applications or applications having only a single thread accessing the RTIambassador this problem should not show up even on macos versions prior to 10.6.

On Solaris, OpenRTI is tested with CC='cc -mt' CXX='CC -mt' cmake ...

On HP-UX, OpenRTI is tested with CC='cc -Aa -mt' CXX='aCC -AA -mt' cmake ...

Supported RTI Features

In general OpenRTI supports HLA1.3, rti1516, rti1516e interfaces. The implementation among them is on the same level - according to the features available on the appropriate level. The basic transport is currently tcp/ip based so everything is basically delivered reliable. Object Model Modules are supported for rti1516e. Update rate reduction is not implemented.

• Federation Management: Connect/Disconnect is available. Create/Destroy including Modules is available. Join/Resign including Modules is available. List is available. Synchronization Points are available. Save/Restore is not available. Connection Lost is available (1).
• Declaration Management Publish/Subscribe for Object Class Attributes is available. Publish/Subscribe for Interaction Classes is available. Start/Stop Registration for Object Class is called whenever published (2). Turn On/Off Interactions is called whenever published (2).
• Object Management Reserve/Release (Multiple) Object Instance Name is available. Register/Discover/Delete/Remove Object Instance is available. Update/Reflect Attribute Values is avaiable. Send/Receive Interaction is available. Local Delete Object Instance is missing. Attributes In/out Of Scope is missing. Request/Provide Attribute value update is available. Turn Updates On/Off is missing. Request Change/Query/Report Attribute Transportation is missing. Request Change/Query/Report Interaction Transportation is missing.
• Ownership Management Is missing.
• Time Management Is available with the exception of message retraction.
• Data Distribution Management Is missing.
• Support Services Are available.
• Management Object Model Is present with the object model but does not provide any data or methods.

(1) The general behavior of OpenRTI on lost connections does not conform to the standard. But the cases where OpenRTI recognizes a lost connection in the sense of the standard it is reported by the Connection Lost service. (2) Rather than tracking subsriptions the service is only called once the current rti ambassador published itself. This helps for applications that rely on the callbacks being called but does not help for reducing the load on the application.

Operation

OpenRTI can operate in several ways:

The most important one is probably the client/server scenario: Have one server process and some federates in several processes on some machines in a network.

Often it would be also good to exploit some locality in an RTI. To get this, an OpenRTI server can operate as slave servers under a parent server. That means that every server in that tree seed all the federations in that server tree but messages are only routed to servers that need these messages. So having a sub server on a local subnet, traffic just interesting for federates connected to that slave server originating from federates connected to that slave server will never be sent to the parent server.

But OpenRTI also can work without any external server running. When all federates are living in one program - may be in different threads, messages are just exchanged in that program. While this is probably the fastest operation mode it is also the one that is the easiest to set up.

Connecting to an rti

As of this writing, there are three different c++ bindings available and implemented. All of them have different ways to connect, to an rti create a federation execution and finally join a federation execution. With OpenRTI all of them share a common backend implementation including the means of communication. Below a general description followed by the way how the possible connections are encoded into the api calls.

Protocols

To select between the different modes of operation above, OpenRTI knows some protocols. This is the basic way of the transport used to communicate.

rti: This is the preferred tcp/ip protocol variant for networked communication. This is the default with a default hostname of localhost.

thread: Just use the in memory communication between threads within a single application. Requires no external server setup and is extremely fast.

rtic: Like rti above but compresses the data stream if available on both transport ends. Compression needs extra cpu cycles and introduces some latency spent in compression of the transfered messages. Nevertheless if your available bandwidth is limited, this can help getting the data over the line. This url is accepted even if compression is not available on one or both of the communication ends. In such a case the data is not compressed before it gets sent over the wire.

http: (currently just an idea) This is a less efficient variant of the rti protocol for networked communication. The trick is that his kind of connection uses standard http headers and encapsulates the rti messages into that. It should be possible to bypass firewalls with that protocol. Not yet sure if this idea also helps for proxies. Note that this does not use the CONNECT proxy method but really uses native http messages. Which simplifies configuration a lot.

pipe: Uses the rti binary protocol on a named pipe. Can be used for machine local communication in presence of tight packet filters.

rtinode: (experimental, only available in the ambassador) A meta protocol to be able to run an rtinode just from inside of any ambassador. The protocol uses url query key value pairs to configure this rtinode like server. Query keys understood are: config=<config file name> to provide a configuration file for rtinode listen=<listen url> to provide a listen url for rtinode parent=<parent url> to provide a parent url for rtinode Note that you may need to escape the queries properly if they contain characters that make the url parsing ambiguous else.

A simple example url setting up an rtinode on localhost on the default port reads "rtinode:///FederationExecutionName?listen=rti:///".

The implementation is prepared to some degree to move protocols into a user provided sha