Distributed node system for FlightGear

Caution  Developer information: Some, and possibly most, of the details below are likely to be affected, or even deprecated, by the ongoing work on implementing and improving HLA support in FlightGear. For recent updates, please refer to HLA Timeline. Please see: High-Level Architecture for further information To avoid conflicting efforts, you are advised not to start working on anything directly related to this without first coordinating your ideas with FlightGear core developers using the FlightGear developers mailing list. talk page..

Also see Modularizing, parallelizing and distributing FlightGear and Remote Properties for a specific approach to addressing these requirements.

This is a proposal for a distributed node system for FlightGear. This should help to get FlightGear to a kind of multithreading and modularity.

It's a distributed property tree which can read and write from every module. On a write action the owner has to accept the changes.

It consists of two parts: NodeManager and NodeModule.

For testing I will build a prototype soon.

Distributed node system

NodeManager

The NodeManager is responsible to manage a local computer. He manages all NodeModules which run local. That means he started a new process for the module and run a specific library (.dll or .so) in there. Also he can stop an instance of the NodeModule. He holds a property tree which contains all data for the NodeModules. Moreover other property trees from different managers (www for multiplayer or local network for distributed run) or parts of them can link into the local property tree. Towards the nodes its like a local property tree.

NodeModule

Each NodeModule run in its own process. At start-up it will load a library (.dll or .so) that contains the module and will start it via a main method. The library contains all necessary elements for example to handle input or to make the simulation. Each NodeModule has access to the property tree from the manager. It can access it read only via shared memory but write access is encapsulated via network to the localhost. To the library is all encapsulated in a high level API, to get a easy object orientated access to the property tree. More over the access to shared memory is protected.

Advantages

• Distributed system without overhead for the single library
• Direct methode of multiplayer
• Property tree still exists, so little code changes in the modules
• Configuration only once for each computer
• Easy expansion
• Load balancing or other fetures can be done by manager
• Faster develop because each module has its own library file and only that have to compile
• Possible auto update for all nodes
• Crash of one module wouldn’t affect other modules.
• Possible redundancy working nodes to provide high availability (e.g. for science)

Disadvantages

• All modules must be changed (This must be done in all kinds to get multithreading)
• Much network traffic in case of wrong installation