DNS: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Status ==
Torsten created a branch {{flightgear source|b=topics/mpdiscovery-via-dns|t=branch}} with a first implementation - just in case somebody might want to have a look. It does contain full lookup of a server list by checking the SRV records and each server's properties via TXT records with name=value text and value being a base64-encoded<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35480316/
  |title  =  <nowiki> Re: [Flightgear-devel] base64 decoding in c++? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Nov 9th, 2016
  |added  =  Nov 9th, 2016
  |script_version = 0.40
  }}</ref> JSON string. It does not /yet/ contain a "is-online" check.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35482909/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 10th, 2016
  |added  =  Nov 10th, 2016
  |script_version = 0.40
  }}</ref>
The latter being considered to be implemented using UDP ‘ping’, i.e. because we can include some interesting info in it.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35483816/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Nov 10th, 2016
  |added  =  Nov 10th, 2016
  |script_version = 0.40
  }}</ref>
Torsten has meanwhile created the necessary DNS entries for the flightgear.org domain. The topics/mpdiscovery-via-dns branch should now be fully functional and discover the required multiplayer servers using DNS. It might take until Sat, 12th 00:00 UTC before the TTL of the old records have expired and your nameserver pulls in the changes.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35485218/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 11th, 2016
  |added  =  Nov 11th, 2016
  |script_version = 0.40
  }}</ref>
== Usage of DNS within FlightGear ==
== Usage of DNS within FlightGear ==


The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.
The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.
This page documents the used services in detail<ref>{{cite web
This page documents the used services in detail.
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35483751/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 10th, 2016
  |added  =  Nov 10th, 2016
  |script_version = 0.40
  }}</ref>.
 
Its creation was inspired by a discussion that took place on the FlightGear devel mailing list in 11/2016 to stop using a dedicated web service for retrieving a list of active multiplayer servers and instead use DNS <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35482909/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 10th, 2016
  |added  =  Nov 10th, 2016
  |script_version = 0.40
  }}</ref>, the idea of storing the information about multiplayer server in DNS instead of providing those through a web service. The motivation behind is to remove another single point of failure. If the current service goes away for some reason, the current implementation falls back to a hardcoded list of multiplayer servers. We consider DNS as an "always-on" service and already use it for looking up a mirror for terrasync<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35475777/
  |title  =  <nowiki> [Flightgear-devel] Proposal for storing the mp server information
in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 7th, 2016
  |added  =  Nov 7th, 2016
  |script_version = 0.40
  }}</ref>


== FlightGear systems using DNS ==
== FlightGear systems using DNS ==
Line 74: Line 10:


=== TerraSync ===
=== TerraSync ===
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. From the command line <code>$ dig terrasync.flightgear.org ANY</code>
 
As of version 2016.4, the configured entries are:
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .
Line 93: Line 31:


=== Multiplayer ===
=== Multiplayer ===
Expanding the use of DNS to multiplayer resulted from a discussion at fsweekend 2016 followed by a discussion on the mailing list. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35475777/
  |title  =  <nowiki>[Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 7th, 2016
  |added  =  Nov 7th, 2016
  |script_version = 0.40
  }}</ref>
Multiplayer discovery via DNS is an experimental feature found in FlightGear branch [https://sourceforge.net/p/flightgear/flightgear/ci/next/~/tree/ next]. It will be released with version 2017.1.1
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.


The SRV record for a multiplayer server looks like this:
The SRV record for a multiplayer server looks like this:
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code>
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code>
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance. The port number is zero for inactive servers.
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.


The TXT record for each referenced multiplayer server looks like this:
The TXT record for each referenced multiplayer server looks like this:
Line 106: Line 55:
decodes to
decodes to
  {"name":"mpserver01","location":"Frankfurt,Germany"}
  {"name":"mpserver01","location":"Frankfurt,Germany"}
Any FGMS changes will likely be quite small, but it would be good to ensure the ‘main network’ is relatively close to current versions. In a perfect would we would have an automated system to update the servers (any thoughts on ideas how to achieve that? Doesn’t need to be smart, could be as simple as git pull; make; make check -> if it passes make install; restart fgms) <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35488212/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Nov 13th, 2016
  |added  =  Nov 13th, 2016
  |script_version = 0.40
  }}</ref>
All our currently available mpserver seem to be running *nix[1], so indeed a cron'ed procedure [...] should be easy to implement<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35488265/
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
information in DNS instead of a web service </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Nov 13th, 2016
  |added  =  Nov 13th, 2016
  |script_version = 0.40
  }}</ref>


== References ==
== References ==

Latest revision as of 09:16, 2 March 2019

Usage of DNS within FlightGear

The Domain Name System This is a link to a Wikipedia article (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release 2016.2.1 as an experimental feature to resolve the location of the TerraSync servers. This page documents the used services in detail.

FlightGear systems using DNS

Currently, (as of version 2016.4.0) these systems use DNS for service discovery:

TerraSync

The TerraSync client queries NAPTR records This is a link to a Wikipedia article for the DNS name terrasync.flightgear.org. From the command line $ dig terrasync.flightgear.org ANY

As of version 2016.4, the configured entries are:

At system start, FlightGear sends a query for the DNS name terrasync.flightgear.org. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with !^.*$! and must end with !, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken. The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".

Algorithm to pick a Server

  • At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U".
  • All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)
  • The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)
  • a random entry from the remaining list is picked for the entire session of FlightGear.

This is implemented in SGTerraSync::WorkerThread::run() here.

The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. http://myterrasync.org/custom-scenery. This will disable the above algorithm.

Multiplayer

Expanding the use of DNS to multiplayer resulted from a discussion at fsweekend 2016 followed by a discussion on the mailing list. [1]

Multiplayer discovery via DNS is an experimental feature found in FlightGear branch next. It will be released with version 2017.1.1

The multiplayer client queries SRV records This is a link to a Wikipedia article for a list of multiplayer servers and TXT records This is a link to a Wikipedia article on each server for detailed information about the server.

The SRV record for a multiplayer server looks like this: _fgms._udp IN SRV 10 20 5001 mpserver01 All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.

The TXT record for each referenced multiplayer server looks like this:

mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="

with the text data used as in RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record. For the given example, the base64 string of

eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= 

decodes to

{"name":"mpserver01","location":"Frankfurt,Germany"}

References

References