2.2 Configuration: advanced settings
Once you've done the basic server settings you could be interested in exploiting some of the advanced capabilities of SmartFoxServer in order to obtain better security and performance:
SmartFoxServer comes with a configurable anti-flood
filter which allows to automatically kick and banish users that are trying to flood
your applications with messages.
By default this is how the anti-flood filter configuration looks like:
<AntiFlood active="true"> <MinMsgTime tolerance="5">1000</MinMsgTime> <MaxRepeatedMessages>10</MaxRepeatedMessages> <WarningsBeforeKick>2</WarningsBeforeKick> <WarningMessage><![CDATA[No flooding allowed!)]]></WarningMessage> <KickMessage><![CDATA[You've been warned! Now flooding! Now you're kicked]]></KickMessage> <BanMessage><![CDATA[Stop Flooding!! You're being banned]]></BanMessage> <BanAfter timeSpan="60">3</BanAfter> </AntiFlood>
The active attribute is used to toggle the filter on and off. Below follows a table with all the available settings:
<MinMsgTime> | It's the minimum time allowed between two messages. The server will
tolerate a number of messages sent below the specified rate before sending an automatic warning message to the client. The "tolerance" attribute represents the amount of messages the server will accept before sending the warning. |
<MaxRepeatedMessages> | The maximum number of identical messages a client can send in a row. After this value has been reached the server will automatically send an administrator warning message to the user. |
<WarningsBeforeKick> | The number of warning messages before a user is kicked from the server |
<WarningMessage> | A custom warning message (always enclose in a <![CDATA[ ... ]]> block) |
<KickMessage> | A custom kick message (always enclose in a <![CDATA[ ... ]]> block) |
<BanMessage> | A custom ban message (always enclose in a <![CDATA[ ... ]]> block) |
<BanAfter> | The number of kicks in the specified time range (timeSpan) before the user is banned. |
By looking at the above xml configuration you will notice that the server
tolerates a maximum of 5 messages sent under the specified rate (1 sec) before
sending a warning message. Also a maximum of 10 identical messages are allowed.
After the server has sent 2 warnings the user will be kicked, and if he continues
to flood with messages it will ba banned if he's been kicked 3 times in the
last 60 minutes.
With SmartFoxServer version 1.1.0 and later you can also filter the number
of users that can be created by one single IP Address.
The IP Address Filter is very easy to configure:
<IpFilter>10</IpFilter>
This way you allow a single IP address to create up to 10 users in the server.
To turn it off just set it to zero.
The filter is useful to avoid connection flooding from hackers and it is usually
reccomendable to keep it turned on and set to a value like 10 or 15 unless
you need to be more restrictive.
SmartFoxServer comes with a built-in and customizable bad
words filter which allow automatic moderation of chat applications and games.
You can provide a custom list of bad words that should be filtered and the
server will automatically replace them with asterisks or completely remove
the phrase.
Also you can turn automatic administrator messages and specify the amount
of warnings before the user is kicked and the amounts of kicks before the
user is completely banned from the server.
The <BadWordsFilter> config section may look like this:
<BadWordsFilter active="true"> <FilterMode>filter</FilterMode> <Warnings>true</Warnings> <FilterRoomNames>true</FilterRoomNames> <FilterUserNames>true</FilterUserNames> <WarningsBeforeKick>3</WarningsBeforeKick> <WarningMessage><![CDATA[No swearing!)]]></WarningMessage> <KickMessage><![CDATA[You've been warned! No Swearing! Now you're kicked]]></KickMessage> <BanMessage><![CDATA[Stop Swearing! You're being banned!]]></BanMessage> <BanAfter>1</BanAfter> <BadWordsList> <badWord>asshole</badWord> <badWord>shithead</badWord> <badWord>shit</badWord> <badWord>bitch</badWord> <badWord>slut</badWord> <badWord>ass</badWord> </BadWordsList> </BadWordsFilter>
The active attribute is used to toggle the filter on and off. Below follows a table with all the available settings:
<FilterMode> | you have two filtering modes called FILTER and REMOVE FILTER: it is the less strict mode. It will substitute the bad words with asterisks REMOVE: it will remove every phrase containing bad words |
<StripCharacters> | (Available from version 1.5.5 and higher) Specify which characters should be stripped from the original message / name etc... before checking for bad words It can be used to avoid the a certain "BadWord" is interspersed with other characters. Example: B_a_d_____W_o___r_d If you specify that the _ (underscore) should be stripped the bad word will be caught anyway. By default the following characters are stripped: , . ; : _ ! $ % & / # * - + |
<Warnings> | it toggles the warning messages on and off. If you turn them on the server will send a custom warning message to the user each time a bad word is detected or removed. |
<FilterRoomNames> | If set to TRUE it will filter bad words in room names |
<FilterUserNames> | If set to TRUE it will filter bad words in user nicknames |
<WarningsBeforeKick> | Here you can specify how many warnings are sent before the user is automatically kicked |
<WarningMessage> | The custom warning message |
<KickMessage> | The custom kick message |
<BanMessage> | The custom ban message |
<BanAfter> | Indicates how many kicks are tolerated before the user is automatically banned from the server |
<BadWordsList> | The custom list of bad words to be filtered. Each word is contained
in a <badWord></badWord> tag. Bad words should not contain white spaces. If you want to add a phrase that contains more than one word just eliminate spaces. |
^ top
» Database Manager (SFS
PRO only)
SmartFoxServer PRO can easily connect to any external database.
Each Zone in you server can connect to a different data source, allowing each
application to be completely independent from the others.
In order to setup your database connections you should configure the <DatabaseManager></DatabaseManager> section
in your Zone definitions. A tutorial is provided showing different examples
and explaining all the available parameters.
The tutorial is located in Section 6.3 of the documentation
^ top
» Mailer configuration (SFS
PRO only)
With SmartFoxServer PRO you can easily send emails without the need of external
software. In order to do so you only need to configure a valid SMTP account
that will be used for sending mail messages. The <Mailer></Mailer> block
contains three settings:
<MailHost> | The SMTP IP address or host name. Example: test.mail.com |
<MailUser> | A valid user name for the SMTP server specified. |
<MailPass> | The account password (if needed) |
» uCount updates and bandwidth
The user count updates are sent by the server to all users in the zone to
keep them updated about the number of users and spectators (for game rooms)
in each room. By default, from version 1.1.0, all non-game
rooms will receive these updates and all game-rooms won't.
These settings can be overridden by the developer at any time by changing
the server configuration or through the Flash API.
The most important thing to understand is that many messages can be sent by
the server in order to update all the clients about the changes that are happening
in each room. Imagine having 600 users in a zone: 20 users in 30 rooms. Each
time one user leaves a room and joins another one, the server should dispatch
400 messages to notify the change to all people in the zone. The more
users you have the more notifications should be sent on each change.
To avoid wasting precious bandwidth you should always specify which rooms
should receive these notifications and which shouldn't.
This can be done in
three ways:
1) By setting uCountUpdates attribute in the <Zone> definition: by setting it to "false" you will completely disable this feature. The deafult is "true".
2) By setting uCountUpdates attribute in the <Room> definition: the default value is "true" for normal rooms and "false" for game rooms.
3) By specifying the uCount property in the object passed to the createRoom() method, in the Flash API. (check the method docs for more info)
SmartFoxServer can easily scale to many different hardware configuration allowing to fully take advantage of single and multi-cpu server configurations.
The <OutQueueThreads> tag represents the number of Java worker threads
used for the SmartFoxServer EventWriter.
The EventWriter is the server stage responsible for broadcasting
messages back to the connected clients and it is usually one of the most busy
stages of the server.
A simple example: imagine a room with 100 clients chatting together, each time a client sends a text message this is sent to the other 99 clients. So the EventWriter will have to send 99 messages everytime one single message is received. To help this stage with its work we can increase the amount of Java threads (processes) used by the EvenWriter, especially if we're using a multi-cpu machine.
By default the EventWriter is assigned 1 thread and this configuration is
ideal for all single CPU or dual-CPU machines.
However if you're running 4
cpus or more you could increase this value to take advantage of your hardware
architecture. A good rule to help you decide how many threads to assign is:
(number of cpus / 2), so in a quad-CPU configuration you could assign 2 threads
to the eventWriter like this:
<OutQueueThreads>2</OutQueueThreads>
The <ExtHandlerThreads> tag sets the size of the thread pool used to run the server extensions.
By default SmartFoxServer uses 1 thread for this task, which is usually sufficient to run many extensions concurrently. You may want to increase this value only in special cases, for example when one extension blocks for a certain amount of time waiting for a resource, an external response or a complex database request etc...
In order to decide if you need multiple threads for running your extensions
you should profile your server side code and see if some of the above conditions are met. If you plan to use more than 1 thread for the ExtensionHandler stage, you will also need to review your code in order to prevent possible race conditions and synchronization issues.
An alternative to this approach (that we recommend) is to run your own thread(s) in the extension in order to handle the blocking/time-consuming operations: this way you can reduce the amount of synchronization needed in you server side code and you don't affect the other extensions running in the server.
^ top
» Other security settings (from version 1.3.0 and later)
For extra security it is possible to limit the amount of requests that the
server holds in its internal queues and the number of Server-side variables
that can be created. These extra settings allow the adminsitrator to fine-tune
the server performance and avoid possible crashes if too much memory is being
taken up by the server.
The maximum number of requests that can be enqueued by the server is handled
by the <MaxIncomingQueue> parameter. By default we suggest
a value of 8000 requests to avoid overloading the JVM heap memory.
During our tests we were able to keep more than 20.000 requests in the server
without problems and without changing the memory settings of the Virtual Machine.
However if you plan to let the server enqueue more than 20k requests we reccomend
to increment the memory settings of your JVM.
By default the server does not limit the number of Room/User variables that the
server can store, but we reccomend to the administrators to set these values
to provide better security.
For example, if your multiuser application never need more than 20 User Variables
for each user we suggest to set that value in the configuration. This will ensure
that even malicious clients will not be able to create unwanted variables.
You can find the variables settings in the <ServerSetup></ServerSetup> node.
<MaxRoomVars>-1</MaxRoomVars> <MaxUserVars>-1</MaxUserVars>
For better performance in a production environment we reccomend
to use a the server version of the Sun Java Virtual Machine.
This version is available in the Sun JDK for
Windows and in both
JRE and JDK for Linux and it can be invoked with the "-server" parameter
at command line.
If you want to use a server JVM with SmartFoxServer just
be sure to have it installed in your system and modify the SFS start script
by adding a "-server" in front of the "java" command.
The start script is located in the Server/ directory in your main SmartFoxServer installation folder and it's called start.bat (Windows) or start.sh (Linux / Unix / MacOS X)
Another important aspect related with server memory usage is related with the "client message queue"
SmartFoxServer allocates a "message queue" for each client connected: the queue is used to hold the server messages that are going to be sent. For a number of reasons (like network lag etc...) the server produces client responses at a much higher rate than what it can send through the network, so it is necessary to pile up these messages while the server waits for them be delivered.
By default each client is assigned a queue with a limit of 50 messages and in case this size is exceeded the 51st message is going to be dropped. We've found that a queue between 30 to 60 messages is ok for most applications and games, however you can change this value to accomodate your needs.
When modifying this value you should take a couple of variables in consideration:
- the amount of concurrent users you think you will handle
- the Java VM (virtual machine) heap limits
If for example you're going to handle 2000 clients with a Message Queue of 100 messages chances are you will run out of heap memory in the Java VM crashing the server. In this case you should manually increase the heap size (-Xms -Xmx) for the VM by modifying the launch.bat (Windows) or launch.sh (Unix/Linux/MacOS) script.
About setting the heap size you can read more here >> http://www.devx.com/tips/Tip/5578
and here >> http://docs.sun.com/source/817-2180-10/pt_chap5.html#wp57027
doc index |