SNIFOS server is designed to run many instances of single type of application (support of multiple application types is planned for future). Application can have two types of configuration:
Client can communicate with application through server communication module. Server can have many different communication modules. User which is connected through one of communication modules can access the same application instance that client connected through any other communication module. It does not matter what communication media is used by these modules - only important thing is that message received by communication module must be passed to server as an XML document.
Diagram which is shown below presents internal server communication in a simple situation.
Server first creates and configures communication modules (here it is one IP communication module), then creates, configures and runs application instances for each unique configuration (here it is only one configuration). After all unique applications are started, server starts all communication modules. In described example after the server has started communication module, client connects to this module and sends first message. Communication module passes this message to server, and server checks which application instance can service this client. The only existing application is unique application, which refuses to service a message, so server creates instance with typical configuration, configures it, runs it and then passes the message to it. Newly created application accepts request and even sends a response message to the client. Next message from client is passed directly to previously created application (server remembers client/communication module and client/application mapping). After sending second message user disconects. Comm module notifies server about this disconnection and server unregisters disconnected user from application.
Reference server implementation uses simple XML configuration file. Below there is an example of such file and description of all its elements.
<server> <commModule className="aigames.soccer.communication.SocketCommModule"> <property name="port">9669</property> <property name="name">SocketCommModule 1</property> <property name="charset-name">UTF-8</property> </commModule> <application className="aigames.soccer.application.SoccerApp"> <typicalConfiguration> <property name="xsd"> src/conf/soccer.xsd </property> <property name="width">10</property> <property name="height">8</property> <property name="goal">2</property> </typicalConfiguration> <uniqueConfiguration> <property name="name"> Unique app 1 </property> <property name="userId">3</property> </uniqueConfiguration> </application> </server>
<server> is main element of server
configuration. It describes server communication modules
and all application configurations.
|commModule||Defines main communication module class and
describes its configuration. Each
||YES (at least one)|
|application||Defines main application class and describes its
unique and typical configurations. In current
version each ||YES|
<commModule> element defines
configuration of one instance of communication module.
|className||Defines main communication module class. This class must implement SNIFOS communication module interface.||YES|
<application> element defines main
application class and configuration of all applications
|className||Defines main application class. This class must implement SNIFOS application interface.||YES|
|typicalConfiguration||Defines typical configuration of application. There can be only one such element.||NO|
|name||Defines property name. This name is the only property identifier inside server, so it should be unique in context of each configuration.||YES|
|value||Value inside ||YES|