[[ Frozen-Bubble server ]]


    Copyright (c) 2004, 2010 Guillaume Cottenceau.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
version 2, as published by the Free Software Foundation.


The Frozen-Bubble server is a standalone program acting as a
bridge between Frozen-Bubble clients (where the players are). It
uses the IP protocol thus players need Internet connectivity
(though it's possible to play LAN games on a LAN with IP support
but no Internet connectivity). It has some logic to control
creating and joining a game, and then becomes a pure relay for
in-game information communicated between players.


]] Suitability to clients

Because all clients connect to the server, the problems arising
to clients/gamers behind NAT private networks and firewalls are
suppressed. A central repository (triply redundant) provides the
list of active servers, which are then presented to the player
sorted best pings first. Thus Frozen-Bubble network gaming should
be available to most people.


]] Suitability for hosting

Because of its bridging nature, the Frozen-Bubble server does not
need the Perl game engine and the data. It is written in C
language in the hope to be as portable as possible and imposing
the lowest dependancy constraints on servers hosting it. It tries
to behave as a good citizen by daemonizing and sending log
messages to syslog. It is typically distributed as source code or
statically linked binary (to prevent a dependancy on a precise
libc version and on the glib).

Check the contents and README of directory 'init' for init tools.


]] Security

C programs are ideal targets for crackers, essentially via format
attacks. This is why the Frozen-Bubble server has undergone a
couple of verifications to ensure it is quite secure and won't
compromise your server:

- it doesn't use arbitrary formats (the format string is always
  a constant in the program)

- valgrind has been used to spot and fix any reported memory
  allocation/manipulation problems, to prevent from exploits and
  leaks hosing the other services of the server

- random data has been fed to it ("fuzz testing"), under which a
  complete remaining stability has been witnessed; then
  additional or substituted random data has been fed at different
  places of the protocol with the same goal; this should
  hopefully reduce exposure to buffer overflows

- strcpy/strcat/strncpy/strncat are never used; a similar
  function to OpenBSD's strlcat is used when strcat functionality
  is needed

- flawfinder has been used and each spotted item checked/fixed

- it doesn't need root permission to operate

Please notice that no serious security guy has audited the code,
thus the above described tasks are a mere attempt of the author
to do his best, while remaining problems are possible.

Consider also -fstack-protector for compiling the server if
you're using a recent enough gcc.

Because the security of your server is crucial, our advice is to
create and use a special user to run it, in order to prevent from
any damage on your personal files if anything bad would happen.
You might also want to run it in rbash or with specially crafted
ulimits.


]] Scalability

The Frozen-Bubble server is not scalable. It is not multi-
threaded nor will fork to better handle a lot of parallel
requests (though it will handle network messages from players in
game before messages from players in lounge, to provide the best
gaming experience possible). Additionally, it is limited to 255
simultaneous players.

Due to its rather low upload and CPU consumption, administrators
can host more than one logical server (multiple Frozen-Bubble
server processes on a single machine), provided they use
different TCP ports. The initscript proposed in directory 'init'
supports multiple Frozen-Bubble servers out of the box.


]] Server resource limits

A built-in upload counter allows to set a limit after which no
new players can connect to the server. It is useful for
administrators who can't spare more than a defined limited of
bandwidth from their hosting solution. It is believed to be
better than using kernel shaping or an external tool such as
trickle, because reaching the bandwidth limit wouldn't impair
existing players.

Note that server upload bandwidth use is typically between a
couple of tens and 1000 bytes/second per connected player (the
more players in one game, the more bandwidth is needed per
player).

CPU use is not measurable (always stays at 0% on my p4 machine
even when serving 100 simulated players producing high traffic).