Kanzi Connect Server

Kanzi Connect Server is a system that hosts services. Services are generic and can suit almost any purpose, the server itself being unaware of their operation.

The default Kanzi Connect Server has these core services, which are usually required for all project types:

  • Configuration Service enables configuring remote services from a Kanzi Connect Server. See Configuration Service.

  • Connection Service enables networking. See Connection Service.

  • Content Service enables the distributed content system. See Content Service.

  • Diagnostics Service enables the collection of real-time performance data from the environment. See Diagnostics service.

  • Input Service enables general-purpose event routing between Kanzi Connect applications. See Input Service.

  • Persistence Service enables you to store information from Kanzi Connect Client applications, and local and remote Kanzi Connect services. The service preserves the stored information through Kanzi Connect Client application restarts. See Persistence Service.

  • Virtual File Service enables the publishing of content using Kanzi Connect Server built-in web server. See Virtual File Service.

    This image shows the architecture and class dependencies of a Kanzi Connect Server and the core services.

    ../_images/kanzi_connect_server.png

Start-up

The start-up of the Kanzi Connect Server can be split into two phases:

  1. You create the services and register them to the system.

  2. The server is asked to initialize(), which causes the server to also initialize and start all the registered services. During the initialization and start up, the server publishes all registered services to the Kanzi Connect network and starts to listen for incoming connections. The network code within the server is threaded and fully asynchronous. It does not cause the calling thread to block.

Runtime operation

Kanzi Connect Server is internally event-driven and executes based on some activity like incoming or outgoing data. Services can notify the Kanzi Connect Server when they have work to be done. This causes the Kanzi Connect Server to call service back from one of its worker threads.

Shutdown

When shutting down, uninitialize() automatically terminates all ongoing network sessions and tears down the services. This call blocks until all the registered services are shut down and the networking code is no longer running.

Kanzi Connect Server configuration

The default Kanzi Connect Server configuration is defined in the connect_server_config.xml file. This configuration contains all configuration options with comments.

Kanzi Connect installer places the Kanzi Connect Server configuration file to <KanziConnectInstallation>/configs/connect_server_config.xml.

When you start the Kanzi Connect Server, the server looks for the configuration file in these places in this order:

  1. If the environment variable CONNECT_SERVER_CONFIG is set:

    • If CONNECT_SERVER_CONFIG points to an existing file with the .xml extension, Kanzi Connect Server uses that file.

    • If CONNECT_SERVER_CONFIG points to a directory, Kanzi Connect Server that this directory contains a connect_server_config.xml and uses that file.

  2. If the current working directory contains a connect_server_config.xml file, Kanzi Connect Server uses that file.

  3. Kanzi Connect Server looks for the configuration file relative to the KANZI_CONNECT_SDK environment variable.

    For example, <KanziConnectInstallation>/configs/connect_server_config.xml.

    Kanzi Connect installer sets this path.

  4. Kanzi Connect Server looks for the configuration file relative to the directory where you run the server.

    For example, ../../../../configs/connect_server_config.xml

    Kanzi Connect installer places the configuration file in this location and this way Kanzi Connect Server can find this file even if the KANZI_CONNECT_SDK environment variable is not set.

  5. If Kanzi Connect Server cannot find a valid configuration file, it starts with default configuration options that include:

    • Connect TCP connections enabled at port 2002

    • Connect httpserver listening at port 8080

    • SSL functionality disabled on both Kanzi Connect sockets and the httpserver

    • All service plugins are loaded that can be found from the current working directory with pattern

      • service_*.dll (win64)

      • libservice_*.so (Linux, QNX)

Keep in mind that:

  • In the configuration file list the services in the order in which you want to start these services.

  • The service/name is used only in this configuration file to allow dependencies to be defined between services.

  • The service/optional when set to true enables the startup to succeed even if that service fails to load.

  • If you omit a fragment for a feature, Kanzi Connect leaves out that feature. For example, if you omit <protocol type="https"> below <httpserver>, Kanzi Connect leaves out the HTTPS protocol support for the web server.

    However, many items have a default value which Kanzi Connect uses, unless you specify a different value. For example, the default value for log is info, the default value for the policy filename is policy.yaml, and so on.

  • The software initialization order sets the log/level to become effective after policy is initialized. Regardless of the log/level setting Kanzi Connect always logs the policy information with the info level.

  • The <security> block must hold at least ca-certificate, certificate, and privatekey attributes. Kanzi Connect requires these settings to create a secured communication. The same principle applies to the Kanzi Connect Client.

Dependencies are used only when you use the resource manager API to load or control services. If the defined dependencies are not met, they can prohibit loading or unloading of a service.