Distributed Interactive Simulation: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 105: Line 105:
* associated 3D model
* associated 3D model
* vehicle traffic ID (i.e. to update multiple different targets at once)
* 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: Messages ==

Revision as of 17:04, 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 (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