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.


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.

  <commModule className="">
    <property name="port">9669</property>
    <property name="name">SocketCommModule 1</property>
    <property name="charset-name">UTF-8</property>
  <application className="">
      <property name="xsd">
      <property name="width">10</property>
      <property name="height">8</property>
      <property name="goal">2</property>
      <property name="name">
        Unique app 1
      <property name="userId">3</property>


The <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 <server> element can have multiple <commModule> elements. YES (at least one)
application Defines main application class and describes its unique and typical configurations. In current version each <server> element can have only one <application> element. YES


Each <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
property Each <property> element defines one property of communication module configuration. Each communication module configuration can have multiple properties.NO


The <application> element defines main application class and configuration of all applications instances.

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
uniqueConfiguration Each <uniqueConfiguration> element defines configuration for unique application instance. Each application can have multiple unique configurations.NO


property Each <property> element defines one property of typical application configuration. Each application configuration can have multiple properties.NO


property Each <property> element defines one property of typical application configuration. Each application configuration can have multiple properties.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 <property> tag is assigned to property name. If this value contains XML parts (like < or > characters) then it should be surrounded with CDATA tag.YES