Distributed Interactive Simulation
| IMPORTANT: Some, and possibly most, of the ideas discussed here are likely to be affected, or even deprecated, by the ongoing work on improving HLA support. Please see: FlightGear HLA support (High Level Architecture) for further information|
Also see Developing with HLA
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..
- 1 Data Agnostic Server Architecture
- 2 Requirements
- 3 Protocol Details
- 4 Possible Design Approaches
Data Agnostic Server Architecture
Designing the server so that it merely maintains arbitrary property hash/value pairs  would allow for it to be directly used for maintaining other global state using the same design and even binary.
In addition, this approach allows for the conceptual and technical separation of essential runtime state (think namespaces/scopes) that is going to be required by all clients (such as position, velocity, course) and other client-specific "meta state" (i.e. aircraft specific animations) that may not be required by all active clients during most of the time (e.g. due to clients being sufficiently apart).
Thus, resulting in decreasing server load by decoupling propagation of essential state and optional state, basically running multiple instances of the same server binary (using different ports) in order to maintain different classes of "state".
Eventually, other state such as environmental state (date/time of day, weather settings) could also be maintained and optionally propagated/applied using the same approach.
In the same sense, there's other environmental state that may be only relevant according to the client's own position, such as for example certain shared/synchronized scenery state (animations), which should also only be propagated on a push/subscribe basis.
This would for example also apply to PCL (Pilot Controlled Lighting) or other airport-specific state such as for example surface/runway contamination (in order to propagate valid friction coefficients), but also for providing a feature to optionally fail ground equipment such as navaids or approach lighting.
Similarly, other client-side state such as ATC comms, flight plans or datalink communications (think TCAS) could be maintained using a dedicated instance of the same server binary.
Such facilities could be easily implemented by having yet another instance of the same server binary in order to maintain specifically this type of state, which is in turn only subscribed to on demand.
This section describes requirements to the FlightGear multiplayer protocol, basically describing a complete redesign of the current protocol with the primary goals of making it more flexible and efficient.
- Architecture to strive to support DIS/HLA (#1859058) (note: as of 07/2009, this is work in progress, discussed on both, the fg forums, as well as the mailing lists)
- generic, data/purpose-agnostic server architecture that allows for arbitrary hash/value pairs to be published/subscribed to, so that a server's purpose would be only determined by the sort of data (properties) it is used to maintain/propagate(#1905987)
These items were categorized as being "high priority" because they were not only repeatedly requested and discussed within the community but also because it can be expected that having these features in place would significantly improve the fgfs multiplayer system, in particular bandwidth consumption could decrease rather significantly so that multiplayer servers could also be set up in more confined environments .
- Protocol to conditionally publish own data, and conditionally subscribe to data from others, while multiplayer server acting as a data dispatcher (#1847251, #1905987) also see 
- Protocol to publish multiple aircraft/vehicles from one client (#1849308) - This will be a prerequisite for decoupling the AI traffic system so that it injects traffic using the multiplayer protocol    (Also see http://email@example.com/msg07536.html]
- Protocol to use selective data propagation mechanism (#1904577)
- Protocol to support multi-crew and non aircraft-class vehicles (#1883587)
- Clients to set TOS (SO_PRIORITY) in IP packets (#1904264)
- Protocol customizable using XML & Scripting (#1847251)
- allow multiplayer properties (property IDs) to become XML configurable (#1906884) Note: there's a related patch available via the fgms patch tracker
- Clients to display a default model of a given category (light single engine, light twin engine, light helicopter, light twin jet, spacecraft) when missing exact aircraft model (#1866514)
- Protocol to allow datalink communication; clients (aircraft, ATC) should be queryable via network (#1849311)
- Protocol to have simple configuration (#1899371)
- Server to support separate "worlds" to ensure that certain users only get to see certain users (#1866508)
- Server to maintain a global status for each world (#1866504, #1849311)
- positions of automatic (random, AI) objects
- runway status
- Support use of Kalman filters for multiplayer data (#1867389)
- Validate plausibilty of distributed flight data (#1866527)
- talks about the lack of listener support in the telnet interface
The protocol header will minimally need to provide the following information:
- size of message in bytes (WORD)
- type of originating peer: (BYTE)
- fgfs client
- multi-vehicle client)
- protocol version (BYTE)
- flags (priority) (BYTE)
- message ID (packet number) (DWORD)
- timestamp (simulation time) DWORD)
- (possibly: authentication ID?) (DWORD)
- data/payload part (contains actual messages) (~ 500 BYTES)
Protocol: Message Types
(based on discussions in aforementioned RFEs)
- HASH_ID_NEGOTIATE (obtain unique, server-side UINT id for any given hash of a property path, to reference all properties using 32 bit IDs)
- SUBSCRIBE (to property, using unique server-side ID)
- PUBLISH (property, using unique server-side ID)
- UNSUBSCRIBE (from property, using unique server-side ID)
(based on http://fgms.sourceforge.net/protocol.php)
- subscribe to properties at fixed update interval (i.e. 5hz, basically polling)
- subscribe to properties based on property changes (listeners) (only propagate a property to clients once it has been updated)
- subscribe to properties based on configurable property changes (listeners) (only propagate a property if a different property was updated)
- TODO: differentiate between UPDATES and CHANGES?
- publish local properties at fixed update interval (i.e. 5hz, basically polling)
- publish local properties based on property changes (listeners) (only propagate a property to clients once it has been updated)
- publish local properties based on configurable property changes (listeners) (only propagate a property if a different property was updated)
- TODO: differentiate between UPDATES and CHANGES?
Protocol: Session specific Data
Some data will only need to be set once during the lifetime of a session, this includes:
- type of vehicle (aircraft, vessel etc)
- name of vehicle
- version of vehicle
- callsign of aircraft
- registration of aircraft
- associated 3D model
- vehicle traffic ID (i.e. to update multiple different targets at once)
These data items will need to be transmitted using high reliability (i.e. making use of the protocol's ACK facility) to ensure that relevant changes are properly propagated.