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

» New Server side methods

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...

^top

» 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.

pic_01
(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.

pic02
(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: < > ' " & \ / ^

^top

» Java Extension

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