summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorrubidium <rubidium@openttd.org>2010-11-30 20:09:44 +0000
committerrubidium <rubidium@openttd.org>2010-11-30 20:09:44 +0000
commit8d5323799841301e9e8e9dc419635bc35ba592b8 (patch)
treea1d6579e64f5bb20f6491214153b263211ccf6c6
parentfe9db129355b390890e2470685df975c157229d2 (diff)
downloadopenttd-8d5323799841301e9e8e9dc419635bc35ba592b8.tar.xz
(svn r21365) -Document: the reasoning for some of the network configuration defaults
-rw-r--r--docs/multiplayer.txt27
1 files changed, 27 insertions, 0 deletions
diff --git a/docs/multiplayer.txt b/docs/multiplayer.txt
index eaa87576e..b85724d46 100644
--- a/docs/multiplayer.txt
+++ b/docs/multiplayer.txt
@@ -114,6 +114,33 @@ Multiplayer Manual for OpenTTD
about 1.5 kilobytes per second up and down. To decrease this amount, setting
'frame_freq' to 1 will reduce it to roughly 1 kilobyte per second per client.
+ - OpenTTD's default settings for maximum number of clients, and amount of data
+ from clients to process are chosen to not influence the normal playing of
+ people, but to prevent or at least make it less likely that someone can
+ perform a (distributed) denial-of-service attack on your server by causing
+ an out-of-memory event by flooding the server with data to send to all
+ clients. The major factor in this is the maximum number of clients; with
+ 32 clients "only" sending one chat message causes 1024 messages to be
+ distributed in total, with 64 clients that already quadruples to 4096. Given
+ that upstream bandwidth is usually the limiting factor, a queue of packets
+ that need to be sent will be created.
+ To prevent clients from exploiting this "explosion" of packets to send we
+ limit the number of incoming data, resulting in effectively limiting the
+ amount of data that OpenTTD will send to the clients. Even with the default
+ limits it is possible to generate about 70.000 packets per second, or about
+ 7 megabit per second of traffic.
+ Given that OpenTTD kicks clients after they have not reacted within about 9
+ seconds from sending a frame update packet it would be possible that OpenTTD
+ keeps about 600.000 packets in memory, using about 50 megabytes of memory.
+ Given that OpenTTD allows short bursts of packets, you can have slightly
+ more packets in memory in case of a distributed denial of service attack.
+ When increasing the amount of incoming data, or the maximum number of
+ clients the amount of memory OpenTTD needs in case of a distributed denial
+ of service attack is linearly related to the amount of incoming data and
+ quadratic to the amount of clients. In short, a rule of thumb for, the
+ maximum memory usage for packets is:
+ #max_clients * #max_clients * bytes_per_frame * 10 KiB.
+
6. Some useful things
----------------------