Howto:Set up a multiplayer server

This page is dedicated to providing a short overview of installing the FlightGear Multiplayer Server ('fgms'). The reader is assumed to be reasonably familiar with working in a Unix/Linux shell environment.

Pre-Requisites

• A computer running a variant of *nix to compile and host the server. Speed of the machine isn't of great consequence as the protocol is a multiplexer which doesn't require much processing grunt.
  • For specific documentation for setting up on FreeBSD see Howto:Set up a multiplayer server on FreeBSD.
• direct/physical or remote access to the server (i.e. SSH/telnet, a conventional web hosting package will usually not be sufficient!)-suitable hosting packages are: dedicated root servers, virtual private servers, shell servers - for a collection of free shell account providers that may be suitable for fgms, see Free Shell Providers (you may want to check this out if you are interested in running fgms but don't have hosting yet)
• if the server is meant to be a public internet server: an internet connection, featuring sufficient upstream/downstream capabilities (see below for details concerning bandwidth requirements).
• firewall policies will need to be set up to allow for incoming and outgoing UDP traffic for the corresponding ports, the same applies to the administration port (TCP)
• permission to run unattended background processes (this may only be an issue with certain limited hosting packages)
• a working GNU toolchain including gcc/g++ (compiler), make & cmake
• fgms source code, currently version 0.10.23
• about 5-10 MB of hard disk space (mainly required for building the binary)

Traffic & Bandwidth Considerations

Note: Currently (May 2008), the server code basically boils down to a packet multiplexer (i.e. most data is -unconditionally- transmitted to all 'active' clients), which may thus create considerable amounts of traffic; this ought to be taken into consideration due to bandwidth limitations in most hosting packages (i.e. fgms may create considerable amounts of traffic!). For basic calculations: inbound traffic is 25 Kilobit per second while outbound is 25 Kbits per second for each plane/client that can 'see' another.

By default, assuming a 10hz update interval, each active fgfs client will currently cause I/O traffic of approximately 5 kbytes/sec (one update consuming ~500 bytes) [1].

As client updates have to be propagated to all other active clients by the server, this number has to be multiplied by the number of active clients -1 (i.e. clients within a configurable range, minus the originating client). In addition, the fgms system allows for traffic updates to be sort of 'mirrored' on (relayed to) other configurable multiplayer/relay servers.

This feature makes it possible for users/clients to use an arbitrary server (with acceptable latency), but still see clients/vehicles connected to different servers. Thus, such relay servers may additionally increase inbound/outbound traffic considerably as all traffic is mirrored/propagated to such relays.

Having more servers should actually decrease the load on each server in high load situations, i.e. when most of the clients are within range of each other. See this brief note on the theoretical bandwidth behaviour of fgms.

Facts

In March 2008, the main fgms multiplayer server (pigeond.net) was reported to consume approximately 15 gb of bandwidth per day, with an average throughput of 200 kB/sec and peak loads of up to ~ 650 kB/sec [2].

During the same month (the much less used but interconnected) mpserver06.flightgear.org had on average 742 MB incoming and 688 MB outgoing traffic per day (i.e. 72 kbit/sec respective 66 kbit/sec on average).

In September 2009, mpserver 05 had a massive peak bandwidth of 1.0 MB/sec. Average bandwidth consumed was about 9 GB of bandwidth per day. The average bandwidth usage per day is climbing due to more users moving from 02 to 05.

In July 2013, mpserver01 load was reported averaging at 10 MBit/sec

Reducing bandwidth requirements

Total network traffic is mainly determined by the number of active clients that 'see eachother' and configured mirrors. If traffic considerations are relevant, the following options exist to reduce overall server/network load:

• configure a relatively low "server.out_of_reach" value, so that clients outside a certain range are not provided with updates (usually about 100 nm on the main server network)
• for virtual gatherings (i.e. fly-ins), have clients use airports and places that do not have lots of other traffic (i.e. in other words, avoid places like standard airports such as KSFO)
• avoid the use of unnecessary relay servers
• if you are not interested in your server being publicly available, only share its address with your friends privately
• for local testing/development purposes, you may want to run only a private fgms session, that may be specific to your LAN or even computer.

Getting & Building fgms

• You will need the build tools cmake and make, and also g++ to compile the fgms application. These can usually be found in the package manager for most the common Linux distributions. You will also need the git client to fetch the source code from the repository, if you plan to download it from the command line interface (see below).
• Once the build tools are installed on your machine, create a directory to hold the source code. This could be named anything, such as fgms. Create it in your user home directory. Note that this WILL NOT be the directory where the program will be compiled.
• Now 'cd' into the directory you just made, where you will run the command to fetch the source code from the git repository (see below).
• To download the latest stable version via HTTP, you can use direct your browse to the URL https://sourceforge.net/projects/fgms/. Download and unzip the source code, and place it in the directory you created above.
• To download a file directly to your server from an ssh session, you can use git tools with the following command:

git clone https://git.code.sf.net/p/fgms/src

Compiling FGMS

For FreeBSD-specific instructions, please see Howto:Set up a multiplayer server on FreeBSD

NOTE: In general, on any current machine this process should not take longer than about 60 seconds.

• Once you have the source code, 'cd' into the ~/fgms/ directory and note the presence of the CMakeLists.txt file and the README.cmake file. Open the README.cmake file and take a minute to read it over. Also, note the path to the CMakeLists.txt file, as you will need this in the following steps.

• Now create a build-fgms directory in your home directory, and 'cd' into it. From inside the ~/build-fgms/ directory, run the cmake command using the path to the CMakeLists.txt as an argument. For example: cmake /home/<user_name>/fgms/

• Once the build finishes, you can either run the "cmake --build ..." command as shown in the README.cmake file, or you can simply use "make" to build the program.

• Once the compilation process finishes, you need to install the program using "make install" (as user), or you can also install as root.

• Once the program has been installed, you need to copy the example *.conf files from the /fgms/contrib/etc directory, into the build-fgms directory. To do this from inside the /fgms/contrib/etc directory, you can use e.g. this command: cp ./fgms_local.skel.conf ~/build-fgms/

• Now 'cd' into the build-fgms directory, and rename the file you just copied as "fgms.conf" so that fgms can find the proper configuration.

Running in docker

• • WARNING - this is currently under development, consider this experimental **

If you have docker installed or are willing to do so, there are pre-built docker images available at The docker hub. There are images for amd64/linux systems as well as for raspberry pis running arm/linux. Sorry, no windows based binaries are currently available.

Installing docker on any linux or the pi is as easy as

curl -sSL https://get.docker.com | sh

and adding your user to the docker group.

If you have docker running, you are all set to start your multiplayer-server for localhost usage:

docker run -p5000:5000/udp -p5001:5001 flightgear/fgms:0.13.4

This starts fgms in local-lan mode, redirects the log to the console and exposes ports 5000 and 5001 to your local loopback network. To use your own fgms.conf, simply link it into the container like

docker run -p5000:5000/udp -p5001:5001 -v /path/to/my/fgms.conf:/usr/local/etc/fgms.conf:ro flightgear/fgms:0.13.4

where /path/to/my/fgms.conf is the absolute path name of your fgms.conf. You MUST use absolute paths names.

The docker image wraps the fgms binary so you can add any command line option that fgms accepts:

$ docker run flightgear/fgms:0.13.4 -h
fgms: version 0.13.4, compiled on Apr 13 2019, at 09:11:11

options are:
-h            print this help screen
-a PORT       listen to PORT for telnet
-c config     read 'config' as configuration file
-p PORT       listen to PORT
-t TTL        Time a client is active while not sending packets
-o OOR        nautical miles two players must be apart to be out of reach
-l LOGFILE    Log to LOGFILE
-v LEVEL      verbosity (loglevel) in range 0 (few) and 4 (much). 5 to disable. (def=2)
-d            do _not_ run as a daemon (stay in foreground)
-D            do run as a daemon

the default is to run as a daemon, which can be overridden in the
config file.

syntax: /usr/local/sbin/fgms options

Setting up the config file

At this point you should have a working 'fgms' binary in the build-fgms directory. If the server will be offline or for private use (i.e. LAN-only, please comment out the relay servers section. This will save bandwidth from the server being consumed.

• Edit the fgms.conf file according to the instructions found elsewhere on this page, then save and close the file.

As long as you are not absolutly sure what you are doing you should: - disable tracking - disable HUB setting — Oliver Schröder

fgms will ignore traffic comming from unknown relays and since the multiplayer network is a star topology you should list only mpserver01 as your only relay. Currently mpserver01 is the only HUB, Although multiple HUBs should work I have not tested a multi HUB environment yet. And for those interrested: Current traffic load on mpserver01 is around 10 MBit/s — Oliver Schröder

your fgms.conf should look like: # basic setting server.name = mpserver02 server.port = 5000 # you can telnet to this port with this username/password # and see statistics (nice cisco like CLI) server.admin_port = 6002 server.admin_user = fred server.admin_pass = fred server.admin_enable = fred # mpserver01 does this server.tracked = false # mpserver01 is hub server.is_hub = false — Oliver Schröder

# don't set this too high server.out_of_reach = 100 # your only relay should be mpserver01 relay.host = mpserver01.flightgear.org relay.port = 5000 # you don't need a crossfeed, it's only interresting for fgms-developers # crossfeed.host = foo.example.com # crossfeed.port = 5002 # you can add static entries of IPs which get blocked, # but it's generally not needed and you can add them via # the admin CLI # blacklist = 123.123.123.123 — Oliver Schröder

Running FGMS for the first time

In addition to its configuration file, FGMS supports a number of configuration parameters that can be passed at startup (and that will by default override any configuration file settings), to get a summary of supported parameters, you may want to run:

$ ./fgms --help

Which should present you with the following output:

options are:
-h            print this help screen
-a PORT       listen to PORT for telnet
-c config     read 'config' as configuration file
-p PORT       listen to PORT
-t TTL        Time a client is active while not sending packets
-o OOR        nautical miles two players must be apart to be out of reach
-l LOGFILE    Log to LOGFILE
-v LEVEL      verbosity (loglevel) in range 1 (few) and 5 (much)
-d            do _not_ run as a daemon (stay in foreground)
-D            do run as a daemon

the default is to run as a daemon, which can be overridden in the
config file.
commandline parameters always override config file options

After having finished the fgms configuration, you can try running fgms and start up fgfs to use the new server.

Check the status of the server through Telnet

The telnet port is a simple way to query the server and get some data including list of pilots. E.g.

$ telnet mpserver14.flightgear.org 5001

Results in something like:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
# This is dockedfgms # fgms in a box
# FlightGear Multiplayer Server v0.13.4
# using protocol version v1.1 (LazyRelay enabled)
# 2 pilot(s) online
HB-VANX@LOCAL: 4304016.687143 629048.412642 4649750.031792 47.101246 8.315123 1415.678443 -3.118597 0.827892 1.212815 Aircraft/f-14b/Models/f-14b.xml
HB-VANO@LOCAL: 4305667.595355 627753.717342 4648406.524079 47.083489 8.295110 1418.320698 -0.610899 -2.304818 0.360544 Aircraft/f16/Models/F-16.xml
Connection closed by foreign host.

Public Server

If you'd like to make it a public server, you can simply use your external (public) IP address to set up the multiplayer in fgfs.

For others to know about your public server you should notify the developers of the existence of your server by posting a message to the developers mailing list.

Add your server to this list: http://wiki.flightgear.org/Howto:Multiplayer#Servers

Related content

• Website: fgms.freeflightsim.org
• Multiplayer howto
• MPmap