Difference between revisions of "Core-dev/RFC/Extending the Generic Protocol System"

From FlightGear wiki
Jump to: navigation, search
m (Goals)
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{Afd|reason=no actual content, seems heavily outdated and unmaintained ?}}
= Goals =
= Goals =

Latest revision as of 06:15, 25 November 2020

This article has been nominated for deletion. To discuss it, please visit the talk page.

Do not remove this tag until the discussion is closed.

Reason for the nomination: no actual content, seems heavily outdated and unmaintained ?


Determine required modifications and enhancements to the FlightGear generic protocol system in order to make it more generally applicable and useful, with the particular focus on using it as the infrastructure backend for re-architecting the current inflexible FlightGear multiplayer system to cater for new requirements (as laid out in Distributed Interactive Simulation) by using so called Remote Properties for dealing with replicating distributed state across an arbitrary number of FlightGear multiplayer clients (and property trees).

Required Features

  • provide support for protocol versioning
  • provide support for a publish/subscribe mechanism (push/pull)
  • internally, only use property IDs)
  • provide support for runtime configurable update conditions (SGCondition)
  • provide support for binary UDP (related patches available)
  • provide support for XDR encoding packet fields (code available in the MP component of FlightGear)
  • provide a state machine implementation exposed using the PropertyList XML format
  • internally differentiate between PACKET, MESSAGE TYPE, MESSAGE and MESSAGE FIELDS in the markup
  • provide means to get/set (update) groups of properties at once (efficiency)
  • i.e. provide a way to register property groups
  • or better use "property classes" - which map nicely to the property tree structure (orientation, velocities, position, fdm)


  • provide support for packet compression (optional?)
  • delta compression means were discussed on the FlightGear forums, this would require reference frames to be provided at regular intervals
  • make protocol scriptable using Nasal? (see forum discussions from first quarter of 2010)