Talk:Remote Properties

This article or section contains out-of-date information Please help improve this article by updating it. There may be additional information on the talk page.

Remote Properties

(taken from Recommended Property Tree Enhancements and pasted here for the time being)

And see Core-dev/RFC/Extending the Generic Protocol System for a collection of enhancements required in order to leverage the generic protocol system for implementing remote property support.

• Remote Properties This discusses a way to have multiple property trees and "mount" them in one another (might be interesting for future subsystem implementations that may have their own property trees, this would make ownership much more explicit, and threading/locking would also be easier that way (more talk here [1] )
• the idea of remote properties (Erik Hofman) is basically all about distributing management of global shared state among different processes, it maps ideally not only 1:1 to parallelizing FlightGear using different processes (or threads for that matter) for standalone subsystems, but it also maps directly to multiplayer use, as well as other shared state (i.e. environmental).
• About remotely managed properties: "I think the current MP protocol could be enhanced to provide this function fairly easily. The first step would be to (re-add) function to export arbitary properties. Then define the FDM properties to be exported from the master computer (running the FDM), and define control inputs to be passed the other way from the slave (running null FDM)." [2]
• remote properties will require an extension of the current SGPropertyNode code (i.e. by subclassing it) to provide essential methods via RPC/IPC means
• LDAP referrals (map 1:1 to the concept of "remote properties"): [3], [4], [5], [6]
• publish/subscribe (event channel) [7], [8]
• In addition, "remote properties" could be directly used to implement the publish/subscribe mechanism [9] [10] [11] that has been repeatedly requested and discussed [12] [13] [14] [15] [16] in order to improve the multiplayer system
• regarding the need for subscription (push/pull) support, also see this discussion about atlas requiring a way to dynamically retrieve specific information from the property tree[17]
• see [18] regarding previous issues w.r.t implementing push/pull support, this could probably be directly addressed by requiring aircraft (-set.xml files) to explicitly enumerate all published properties, so that other clients could directly look up these properties locally in order to issue a corresponding subscription request.
• in the context of multiplayer support, remote properties could be directly useful for:
  • dual/multi control aircraft (shared state)
  • datalink communications
  • globally shared scenery state (wildfire, runway lighting, skid marks etc)
• In the context of managing shared remote state [19], remote properties would be ideally suited to handle consistency across all clients using a push/pull approach
• this also applies to synchronizing state for AI traffic that is propagated using the MP facility: Decoupling the AI Traffic System
• this issue would also be elegantly addressed by "remote properties".
• Also see [20], [21], [22], [23] (DIS/HLA, multiple vehicles related)
• regarding subsystem-specific property trees, see [24]

Implementation

• http://www.mail-archive.com/flightgear-devel@flightgear.org/msg03803.html
• http://simgear.org/doxygen/props_8hxx_source.html
• http://simgear.org/doxygen/classSGRawValue.html
• SGRawBase (readfrom)
• use stateful UDP for reliably sending binary UDP packets
• unlike the generic protocol, this will need a version field to allow the API to evolve
• a simple prototype may be coded by using and transferring just string properties
• compression, network byte order?
• push/subscribe (push/pull): see multiplayer DIS page
• expose important SGPropertyNode APIs via RPC methods
• just subclassing SGPropertyNode, will make everything transparent so that the fgSet*/fgGet* helpers will keep working and would be agnostic to how a property is being managed (no difference from a usability point of view)
• also see: Distributed_node_system_for_FlightGear
• if done well, the whole multiplayer system could be reimplemented on top of remote properties
• it's sort of message passing concurrency
• only one thread accesses each property tree
• however each component may have its own property tree to maintain internal state
• expose external state
• access will be automatically serialized
• dispatch reads/writes transparently, without the user being aware
• if this is pursued, there will need to be a way to make the base package ($FG_ROOT) available to any distributed processes, probably a dedicated fgroot process that reads and provides base package files on demand, to dispatch them to the requesting component
• viable components for prototyping include:
  • autopilot (entirely property driven)
  • ai traffic
  • weather
  • fdm (this is already done with the explicitly coded FDM interface to the property tree)