Distributed Interactive Simulation

From FlightGear wiki
Jump to navigation Jump to search
This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.


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..

Request for Comments:

Data Agnostic Server Architecture

Designing the server so that it merely maintains arbitrary property hash/value pairs [1] 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.

Requirements

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

  • 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)

Protocol features

High Priority

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 [2].

  • 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 [3]
  • Protocol to use selective data propagation mechanism (#1904577)

Medium Priority

  • Protocol to support multi-crew and non aircraft-class vehicles (#1883587)
  • Clients to set TOS (SO_PRIORITY) in IP packets (#1904264)
  • 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)

Low Priority

  • Protocol to allow datalink communication; clients (aircraft, ATC) should be queryable via network (#1849311)
  • Protocol to have simple configuration (#1899371)

Global state

  • 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)
    • date/time
    • weather
    • positions of automatic (random, AI) objects
    • runway status

Data filtering

  • Support use of Kalman filters for multiplayer data (#1867389)
  • Validate plausibilty of distributed flight data (#1866527)

Related Discussions

Protocol Details

Protocol: Header

Based on http://fgms.sourceforge.net/protocol.php

The protocol header will minimally need to provide the following information:

  • size of message in bytes (WORD)
  • type of originating peer: (BYTE)
    • server/relay
    • fgfs client
    • observer
    • 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)
  • CHAT
  • ACKNOWLEDGE

Subscription Modes

(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 Modes

  • 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?


Unsubscribe Modes

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.

Protocol: Messages

Protocol: Message Fields

Possible Design Approaches

Incoming Message Handler Thread

Message Validation

Traffic Filter Thread

Response Thread

Further Resources

Retrieved from "https://wiki.flightgear.org/w/index.php?title=Distributed_Interactive_Simulation&oldid=75152"