fgms 0.11.8
The
FlightGear MultiPlayer Server
project
page_hosting.cxx
Go to the documentation of this file.
1 /*! \page hosting Hosting
2  *
3  *
4  * \section hosting_info Hosting an Mp Server
5  * If your are interested in hosting a server and joining the network then
6  * - Please read the guidelines below.
7  * - Use the \ref install_guide to setup and configure the server
8  * - Contact \ref support or one of the \ref developers if you are stuck.
9  * - Send and email to the \ref fg_mailing_list with details for \ref dns.
10  *
11  * \section pre_req Pre-Requisites
12  * - <b>A computer running a variant of *nix to compile and host the server</b>
13  * * Speed of the machine isn't of great consequence as the protocol is a multiplexer which doesn't require much processing grunt.
14  * - <b>Direct/physical or remote access to the server i.e. SSH/telnet</b>
15  * * a conventional web hosting package will usually not be sufficient!)
16  * * suitable hosting packages are:
17  * * dedicated root servers
18  * * virtual private servers
19  * * shell servers
20  * * for a collection of free shell account providers that may be suitable for fgms,
21  * * see Free Shell Providers http://wiki.flightgear.org/images/cache/d/d0/Free_Shell_Providers.html
22  * - If the server is meant to be a public internet server:
23  * * an <b>internet connection</b>
24  * * <b>sufficient upstream/downstream bandwidth</b> (see \ref bandwidth_req).
25  * - <b>Firewall policies</b> will need to be set up to allow
26  * * for incoming and outgoing UDP traffic for the corresponding ports
27  * * the same applies to the administration port (TCP)
28  * - Permission to run unattended background processes
29  * * (this may only be an issue with certain limited hosting packages)
30  * - About <b>5-10 MB of hard disk space</b> (mainly required for building the binary)
31  * - A working <b>GNU toolchain</b> including
32  * * gcc (compiler), gmake & ranlib (to compile the source code)
33  * - <b>git</b> to aqquire the fgms source code,
34 
35  *
36  * \section traffic Traffic & Bandwidth Considerations
37  * \note
38  * Currently (May 2008), the server code basically boils down to a packet multiplexer
39  * (i.e. most data is -unconditionally- transmitted to all 'active' clients), which may thus
40  * create considerable amounts of traffic; this ought to be taken into consideration due
41  * to bandwidth limitations in most hosting packages (i.e. fgms may create considerable amounts of traffic!).
42  *
43  * * For basic calculations:
44  * * inbound traffic is 25 Kilobit per second
45  * * outbound is 25 Kbits per second for each plane/client that can 'see' another. (see \ref server_out_of_reach)
46  * * By default, assuming a 10hz update interval, each active \ref fgfs client will currently
47  * cause I/O traffic of approximately 5 kbytes/sec with one update consuming ~500 bytes.
48  *
49  * \warning \ref fgms uses exorbitant much bandwidth. The reason for this is the client
50  * side configuration: We tell all our users to send 10 packets per second,
51  * but I do believe that this is much more than acutally needed. This
52  * number comes from the time when \ref fgfs was not able to "emulate" a remote
53  * aircraft while no data is received. The first multiplayer versions just
54  * updated a remote aircrafts position on data reception and the aircraft
55  * stayed where it was until the next position arrived. Since then a lot of
56  * things have changed, but we never tried to reduce the number of packets.
57  * I guess that 2 to 4 pps are enough.
58 
59  * As client updates have to be propagated to all other active clients by the server,
60  * this number has to be multiplied by the number of active clients -1
61  * (i.e. clients within a configurable range, minus the originating client).
62  * In addition, the fgms system allows for traffic updates to be sort of
63  * 'mirrored' on (relayed to) other configurable multiplayer/relay servers.
64  *
65  * This feature makes it possible for users/clients to use an arbitrary server
66  * (with acceptable latency), but still see clients/vehicles connected to different servers.
67  * Thus, such relay servers may additionally increase inbound/outbound traffic
68  * considerably as all traffic is mirrored/propagated to such relays.
69  *
70  * Having more servers should actually decrease the load on each server in high load situations,
71  * i.e. when most of the clients are within range of each other. See this brief note on the
72  * theoretical bandwidth behaviour of fgms.
73  *
74  *
75  *
76  * \section reduce_bandwidth Reducing bandwidth requirements
77  * Total network traffic is mainly determined by the number of active clients that
78  * 'see each other' and configured mirrors. If traffic considerations are relevant,
79  * the following options exist to reduce overall server/network load:
80  * - Configure a relatively low \ref server_out_of_reach value, so that clients
81  * outside a certain range are not provided with updates (usually about 100 nm on the main server network)
82  * - For virtual gatherings (i.e. fly-ins), have clients use airports and places that do not
83  * have lots of other traffic (i.e. in other words, avoid places like standard airports such as KSFO)
84  * - Avoid the use of unnecessary relay servers
85  * - If you are not interested in your server being publicly available,
86  * only share its address with your friends privately
87  * - For local testing/development purposes, you may want to run only a private fgms session,
88  * that may be specific to your LAN or even computer.
89  *
90  * \section next_dd > Next
91  * * \ref install_guide
92  *
93  */