Distributed Interactive Simulation: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (adding link illustrating bandwidth issues (From FG forums))
Line 4: Line 4:


== Architecture ==
== Architecture ==
* Architecture to strive to support DIS/HLA ([http://sourceforge.net/tracker/index.php?func=detail&aid=1859058&group_id=161928&atid=821811 #1859058])
* Architecture to strive to support DIS/HLA ([http://sourceforge.net/tracker/index.php?func=detail&aid=1859058&group_id=161928&atid=821811 #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[http://sourceforge.net/tracker/index.php?func=detail&aid=1905987&group_id=161928&atid=821811 (#1905987)]
* 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[http://sourceforge.net/tracker/index.php?func=detail&aid=1905987&group_id=161928&atid=821811 (#1905987)]



Revision as of 13:21, 25 July 2009

This article is a stub. You can help the wiki by expanding it.

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

  • Protocol to conditionally publish own data, and conditionally subscribe to data from others, while multiplayer server acting as a data dispatcher (#1847251, #1905987)
  • Protocol to publish multiple aircraft/vehicles from one client (#1849308)
  • 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