Server Configuration File

The server configuration file encompasses multiple parameters necessary for its operation.

To specify the path to the configuration file, you can use the command line argument -C when executing gcs. If no path is specified, the gcs.json file in the current directory will be utilized.

The configuration file follows the JSON format. Each JSON object may include a "comment" field, which serves as a brief description for readers and is disregarded by the gcs application. To ensure accuracy in the configuration file, gcs will terminate with an error if unexpected names or values are encountered.

Root Parameters

Here are the root-level parameters found in the configuration file, along with their corresponding types and descriptions:

Server Name

By specifying the value in the "server_name" you instruct the gcs to display the name of your server in the Statistics section of the Dashboard and enrich it with data related to the application counters.

Working Directory

The working directory path is set based on the configuration file read at the beginning of the gcs application. The current directory is changed to this working directory, and all related paths are resolved relative to it. The default working directory is $HOME/.gc.

SSL Files

To configure an SSL certificate, you need to provide three files with the extensions .key, .cert, and .cacert. These files can have the same name but different extensions. The "ssl_keys_path" field in the root section of the configuration file should be set to the path and filename without extensions. The default path is tls/game_carrier relative to the working directory.

Connection Monitoring

The "conn_notice" and "conn_critical" sections are used to configure connection monitoring parameters. These parameters include:

If any of these parameters in the "conn_notice" section are exceeded, the on_issue handler will be called. If any of these parameters in the "conn_critical" section are exceeded, the connection will be dropped.

"conn_notice" and "conn_critical" sets parameters for connection monitoring. The parameters are

Threading Parameters

The threading parameters are located in the threading section of the configuration file. These parameters govern the behavior of the gcs threads. The supported parameters are:

A recommended initial value for "worker_count" is typically the number of CPU cores minus one.

Counters Parameters

The counter parameters are located in the "counters" section of the configuration file. These parameters govern the behavior of performance counters in the gcs. The supported parameters are:

Logging Parameters

The logging parameters are located in the "logging" section of the configuration file. The following parameters are supported:

Log Levels

The log level mask is a bit mask where each bit corresponds to a specific level of logging messages. The supported log levels, starting from the zeroth bit, are ERROR, WARNING, NOTICE, INFO, and DEBUG. The 10th bit represents the USER level.

Additionally, there are two constants: "NORMAL" and "VERBOSE". The "NORMAL" includes "ERROR", "WARNING", "NOTICE", and "USER", while the "VERBOSE" includes "INFO" and "DEBUG" in addition to "NORMAL".

The log level can be configured both for the server and the application, for the server you must add the "gcs" property and the corresponding masks to the "level" object, while for the user you have to add the "user" property to the “level” object and the required masks. See the example below:

    "level": {
        "gcs": "ERROR | WARN | NOTICE",
        "user": "USER | ERROR"
    }

Flags

Flags represent bit masks where each bit corresponds to a specific level of logging messages. The supported log levels, starting from the zeroth bit, are "APPEND", "AUTOFLUSH", "THREADID", "STDERR", "NORMAL", and "DEFAULT".

Adapters Parameters

The configuration file includes an "adapters" section where adapter parameters are specified. The "adapters" section consists of an array of objects, each describing an adapter and its associated applications. It is important to set at least one adapter for the proper functioning of the "gcs". Each adapter supports the following parameters:

Additionally, specific adapter types may have additional parameters associated with them.

Adapter Types

native

This adapter type is the lowest level, where the adapter is a shared object file with the necessary exports. The dir parameter specifies the path to the directory where the shared object file is located. The name parameter corresponds to the name of the shared object file. In most cases, you can omit OS-specific details from the name, such as using "myadapter" instead of "libmyadapter.so" on Linux. Adapters for the .NET Framework are loaded as native adapters.

nethost

This adapter is designed to load .NET Core applications.

dynamic

This adapter is a user-customized implementation. Users can leverage the Game Carrier Adapter API to create their own adapters for various programming languages.

Adapter Applications

The "apps" array encompasses information about all the applications associated with the adapter. These parameters are provided to the adapter during the creation of applications. The common parameters include:

native No extra parameters, "type_name" and "file_name" are ignored.

nethost

dynamic The "args" argument is utilized for initializing the application with a specific string. The format of this string is determined by the dynamic adapter.

Vhost Parameters

The parameters for virtual hosts are defined within the vhosts section of the configuration file. Each virtual host is described by an object with the following properties:

Cloudflare

The cloudflare section includes additional settings specifically for Cloudflare. The following parameters are available:

The "mode" parameter determines the Cloudflare mode for the virtual host:

• "OFF": The virtual host accepts connections with or without Cloudflare. If a connection goes through Cloudflare, the header is not parsed and the connection is typically rejected.
• "OPTIONAL": The virtual host accepts connections with or without Cloudflare. If a connection goes through Cloudflare, the header is parsed, and the connection is accepted if the header is valid.
• "REQUIRED": The virtual host only accepts connections with Cloudflare. If a connection goes through Cloudflare, the header is parsed, and the connection is accepted if the header is valid. Connections without a Cloudflare header are rejected.

The "inet_proto" parameter determines the Interned protocol behavior:

• "TCP4": The virtual host only accepts connections specified as "IPv4" in the Cloudflare header.
• "TCP6": The virtual host only accepts connections specified as "IPv6" in the Cloudflare header.

The "version" parameter specifies the required Cloudflare protocol version: 1, 2, or "ALL" to support both versions.

Example

The example below showcases the usage of the server configuration file:

{
    "adapters": [
        {
            "comment": "Native adapter",
            "type": "native",
            "dir": "/home/gc/minimal_app/",
            "name": "minimal_app",
            "apps": [
                {
                    "name": "minimal_app",
                    "type_name": "minimal_app",
                    "file_name": "minimal_app"
                }
            ]
        }
    ],

    "vhosts": [
        {
            "comment": "Primary host",
            "ip": "0.0.0.0",
            "port": 7681,
            "protocol": "wss",
            "app": "minimal_app"
        }
    ],

    "logging": {
        "comment": "%p means PID",
        "log_file": "gcs.%p.log",
        "level": "NORMAL"
    },

    "keep_alive": {
        "comment": "zero timeout means no keep alive",
        "timeout": 0,
        "retries": 5,
        "interval": 100
    },

    "threading": {
        "worker_count": 12,
        "use_libuv": true
    },

    "counters": {
        "per_second_window": 10,
        "update_interval": 10
    },

    "group_max_size": 42,
    "max_groups": 1000,
    "max_client_connections": 99
}