fgms 0.11.8
The
FlightGear MultiPlayer Server
project
Hosting

Hosting an Mp Server

If your are interested in hosting a server and joining the network then

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.
  • Direct/physical or remote access to the server i.e. SSH/telnet
  • If the server is meant to be a public internet server:
    • an internet connection
    • sufficient upstream/downstream bandwidth (see bandwidth_req).
  • 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)
  • About 5-10 MB of hard disk space (mainly required for building the binary)
  • A working GNU toolchain including
    • gcc (compiler), gmake & ranlib (to compile the source code)
  • git to aqquire the fgms source code,

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
    • outbound is 25 Kbits per second for each plane/client that can 'see' another. (see server.out_of_reach)
    • By default, assuming a 10hz update interval, each active fgfs client will currently cause I/O traffic of approximately 5 kbytes/sec with one update consuming ~500 bytes.
Warning
fgms uses exorbitant much bandwidth. The reason for this is the client side configuration: We tell all our users to send 10 packets per second, but I do believe that this is much more than acutally needed. This number comes from the time when fgfs was not able to "emulate" a remote aircraft while no data is received. The first multiplayer versions just updated a remote aircrafts position on data reception and the aircraft stayed where it was until the next position arrived. Since then a lot of things have changed, but we never tried to reduce the number of packets. I guess that 2 to 4 pps are enough.

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.

Reducing bandwidth requirements

Total network traffic is mainly determined by the number of active clients that 'see each other' 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.

> Next