Contents

1. Contents
2. Description
3. Architecture
4. Sequence diagram
5. Configuration file description

Description

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:

• unique configuration - each application can have any number of specific configurations. After the server starts it creates one application instance per each specific configuration.
• typical configuration - each application can have only one typical configuration. Server creates application instances with typical configuration only when uniquely configured applications will not accept client connection. If a newly created typical application will refuse to service client it is assumed that client cannot be serviced by this application configurations and the client is disconnected.

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.

Architecture

Diagram which is shown below presents architecture of reference SNIFOS server.

Sequence diagram

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.

Configuration file description

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>