Distributed Interactive Simulation: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 88: Line 88:


=== Publish Modes ===
=== 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 ===
=== Unsubscribe Modes ===

Revision as of 16:43, 22 May 2008

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

Requirements

This section describes requirements to the FlightGear multiplayer protocol.

Architecture

  • Architecture to strive to support DIS/HLA (#1859058)
  • 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

  • Protocol to publish own data, and 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
  • type of originating peer:
    • server/relay
    • fgfs client
    • observer
    • multi-vehicle client)
  • protocol version
  • flags (priority)
  • message ID (packet number)
  • timestamp (simulation time)
  • (possibly: authentication ID?)
  • data/payload part (contains actual messages)

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

Protocol: Messages

Protocol: Message Fields

Possible Design Approaches