View source for Distributed Interactive Simulation

{{Out of date}}

{{Affected by HLA}}
{{Template:RFC Navigation}}

= Data Agnostic Server Architecture =
Designing the server so that it merely maintains arbitrary property hash/value pairs [http://sourceforge.net/tracker/index.php?func=detail&aid=1905987&group_id=161928&atid=821811] 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 ([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)]

== 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 [http://forum.flightgear.org/viewtopic.php?f=2&t=5532].

* Protocol to conditionally publish own data, and conditionally subscribe to data from others, while multiplayer server acting as a data dispatcher ([http://sourceforge.net/tracker/index.php?func=detail&aid=1847251&group_id=161928&atid=821811 #1847251], [http://sourceforge.net/tracker/index.php?func=detail&aid=1905987&group_id=161928&atid=821811 #1905987]) also see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23516.html]

* Protocol to publish multiple aircraft/vehicles from one client ([http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811 #1849308]) - This will be a prerequisite for decoupling the AI traffic system so that it injects traffic using the multiplayer protocol [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16075.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13222.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13223.html] (Also see http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg07536.html]

* Protocol to use selective data propagation mechanism ([http://sourceforge.net/tracker/index.php?func=detail&aid=1904577&group_id=161928&atid=821811 #1904577])

=== Medium Priority ===
* Protocol to support multi-crew and non aircraft-class vehicles ([http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811 #1883587])

* Clients to set TOS (SO_PRIORITY) in IP packets ([http://sourceforge.net/tracker/index.php?func=detail&aid=1904264&group_id=161928&atid=821811 #1904264])

* Protocol customizable using XML & Scripting ([http://sourceforge.net/tracker/index.php?func=detail&aid=1847251&group_id=161928&atid=821811 #1847251]) 
** allow multiplayer properties (property IDs) to become XML configurable [http://sourceforge.net/tracker/index.php?func=detail&aid=1906884&group_id=161928&atid=821811 (#1906884)] [http://sourceforge.net/tracker/index.php?func=detail&aid=1908456&group_id=161928&atid=821810 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 ([http://sourceforge.net/tracker/index.php?func=detail&aid=1866514&group_id=161928&atid=821811 #1866514])

=== Low Priority ===
* Protocol to allow datalink communication; clients (aircraft, ATC) should be queryable via network ([http://sourceforge.net/tracker/index.php?func=detail&aid=1849311&group_id=161928&atid=821811 #1849311]) 

* Protocol to have simple configuration ([http://sourceforge.net/tracker/index.php?func=detail&aid=1899371&group_id=161928&atid=821811 #1899371])

== Global state ==
* Server to support separate "worlds" to ensure that certain users only get to see certain users ([http://sourceforge.net/tracker/index.php?func=detail&aid=1866508&group_id=161928&atid=821811 #1866508])

* Server to maintain a global status for each world ([http://sourceforge.net/tracker/index.php?func=detail&aid=1866504&group_id=161928&atid=821811 #1866504], [http://sourceforge.net/tracker/index.php?func=detail&aid=1849311&group_id=161928&atid=821811 #1849311])
** date/time
** weather
** positions of automatic (random, AI) objects
** runway status

== Data filtering ==
* Support use of Kalman filters for multiplayer data ([http://sourceforge.net/tracker/index.php?func=detail&aid=1867389&group_id=161928&atid=821811 #1867389])

* Validate plausibilty of distributed flight data ([http://sourceforge.net/tracker/index.php?func=detail&aid=1866527&group_id=161928&atid=821811 #1866527])

== Related Discussions ==
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27653.html talks about the lack of listener support in the telnet interface]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22673.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16023.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16807.html
* http://sourceforge.net/projects/virtualair

= 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 ==
* [http://wiki.flightgear.org/index.php/Programming_Resources#Multiplayer_Design_.26_Programming Multiplayer Programming Resources]

[[Category:RFC]]
[[Category:Multiplayer]]