7.3 Introducing the SmartFoxServer server-side framework
With the release of the SmartFoxServer 1.4 we have introduced
new important features for advanced server side development, security and
tuning of your multiplayer applications.
In this document we present a quick overview of the functionalities introduced
in the new version.
» | New server side methods |
» | Advanced Zones configuration |
» | Java Extensions |
The new 1.4 server side framework introduces 10 new methods
that allow to create rooms, join rooms, access server side variables and a
lot more. The purpose of these new commands is to give developers better control
over the server engine, allowing to create advanced server behaviours, custom
room management, challenge systems etc...
Below follows a quick tour of the new methods available:
createRoom() | creates a new room |
destroyRoom() | destroys an empty room |
disconnectUser() | immediately disconnect a client (kick) |
getUserByChannel() | return the user from its SocketChannel |
joinRoom() | join a room |
leaveRoom() | leave a room (when in "multi-room" mode) |
sendGenericMessage() | send a generic / custom xml message |
sendRoomList() | send the room list |
setRoomVariables() | create / update / delete one ore more room variables |
setUserVariables() | create / update / delete one ore more user variables |
switchSpectator() | switch a spectator into a player (in game rooms) |
All the above methods stay consistent with their counterpart on the client
side, so they should all look familiar.
The advantage of using them on the server side is the increased control you
can obtain and the baility to add your own application logic, data validation,
database integration etc...
» Advanced Zones configuration
As you may already know, Zones are the heart of SmartFoxServer development. Each Zone describes a single multiplayer application running in the server, it can set up its own database connection, its own extensions and define the application configuration.
We have added two new important configuration items called <DisabledSysEvents> and <DisabledSysActions>: the first allow to suppress the notification of certain default events and the latter can be used to disable certain user requests from the client side.
Their usage is straightforward:
<DisabledSysEvents> <event>onRoomDeleted</event> <event>onRoomAdded</event> </DisabledSysEvents> <DisabledSysActions> <action>createRoom</action> <action>joinRoom</action> </DisabledSysActions>
By adding these tags in your Zone configuration you will stop the onRoomDeleted and onRoomAdded events from being fired. Additionally the createRoom() and joinRoom() requests from the client side will be disabled.
Why would you need this?
When developing advanced server extensions you may need to override the default
server events with your own events, or just suppress unwanted notifications.
This can be quickly done by providing a list of event names to be disabled
in the current Zone.
Disabling client side requests is even more important for optimal application
security. In order to describe the advantages introduced by this option we
need a short digression.
As you already know the server can respond to a number of publicly available
commands, that are listed in the client side API.
These methods require a valid connected user to be executed, and they
always validate the incoming data. However they are called from the client side
which is always the most vulnerable part of a multiplayer application. The simple
diagram in figure 1 shows how the client communicates with the server
through the publicly available methods.
(figure 1)
For example a malicious user may try to decompile your SWF game file, understand
the game logic and try to re-create a modified version of the client in order
to cheat in the game.
The best solution for securing the server and your application from cheating/hacking attempts, is to implement all the game logic on the server side, plus setting the <DisabledSysActions> in your Zone so that all unused public commands are disabled.
An example: if your game handles all the joinRoom and createRoom actions from an Extension, you could safely add these commands to the <DisabledSysActions> list. Also if you don't make use of UserVariables and RoomVariables you should disable them as well, to prevent unwanted client requests to the server.
(figure 2)
The diagram in figure 2 shows how the green client dialogues with the server side extension while the malicious client (violet) tries to send unwanted client-side requests. The latter will fail in his attempt if the <DisabledSysActions> is correctly configured.
- User names and Room names filtering:
We also added a simple filtering system to disallow the usage of certain characters
in room names or user names. For example you may want to avoid characters that
don't work well in UI components or that may give problems in SQL strings (usernames)
etc...
You can set these filters very easily in each zone:
<UserNameAvoidChars><![CDATA[abc]]></UserNameAvoidChars>
<RoomNameAvoidChars><![CDATA[aABbCc_+-]]></RoomNameAvoidChars>
You simply need to specify the list of characters that are not allowed in user names or room names. These characters will be automatically stripped by the server.
By default the characters that are filtered are: < > ' " & \ / ^
From version 1.4 SmartFoxServer PRO officially supports server side extensions
written in Java.
The default folder for java extensions is called javaExtensions/ and
it is found under the Server/ directory. We reccomend that
you put all your files in this folder, organizing them into packages.
Java extensions follow the same architecture of those based on Actionscript: you will need to implement a basic interface that handles the initialization, destruction, internal server events, and client requests.
In order to compile your extensions you will need to point your classpath to the smartfoxserver.jar file (for SFS 1.4), which contains all the java classes that your code will use. Here's a simple example:
javac -cp /path/to/smartfoxserver.jar ClassName.java
In order to compile your source file called "ClassName.java" just make sure to provide the correct path to your smartfoxserver.jar file.
Similarly, if you use a Java IDE like Eclipse or Netbeans for your source files, you should add the smartfoxserver.jar file to your project classpath in order to successfully compile it.
For a complete overview of how to develop Java extensions check this detailed article.
- Java vs Actionscript:
Apart from personal preferences, the main advantage of using Java instead
of Actionscript is performance.
While Actionscript can be great for most common server side tasks, some
extensions would definetely
benefit from the extra performance that can be achieved by compiled java classes.
For example math-intensive simulations, pathfinders, complex AI game logic
etc... would perform better if written in pure Java.
Another interesting option provided by SmartFoxServer is the ability to use
java classes inside your Actionscript Extensions. To learn more about
this feature you can read the article at Chapter 6.5
doc index |