Next Previous Contents

3.  Server Configuration 

3.1  gns.conf

When a GNS server starts, the first thing it does is read information in from the configuration file. The working directory is checked for the file gns.conf. If it does not exist, the server will initialize with no zones, authorities or active listening capabilities.

Each line from gns.conf is read in as if it were being typed into the console. The sample gns.conf which comes with gns-0.2.tar.gz  is used for demonstration purposes. Comment lines begin with # symbols.

In the current implementation, text parameters must be separated by tabs.

 

3.2  Server Commands

3.2.1 auth

Usage: auth <id> <rank> <zone> <address> <protocol> <port> <content home directory> <ttl> <tasks>

ID: The unique ID of the authority
Rank: The authority rank (1 is the highest, 2 is lower, 3 is even lower, etc.)
Zone: The FQGN of the zone that the authority exists in. If the authority exists in the rootmost server, this must be a . symbol.
Address: IP address or FQDN name of the physical server. (Examples: 12.34.56.78, www.mygamesite.com)
Protocol: The protocol of the network connection that the authority listens on. 1 = TCP, 2 = UDP
Port: The port of the network connection that the authority listens on.
Content home directory: The absolute path to the location on the computer where content may be downloaded from by clients.
TTL: The TTL of the authority's existence. When the time expires, the authority will no longer handle incoming requests.
Tasks: The tab-delimited tasks of the authority. The list of possible tasks includes:

zone = zone related (A fancy way of saying you can request active game lists)
content = content management (massive upload/downloads)
chat = chat room serving
mgr = gns server management (statistical transfers and coordination)
ping = high level ping (usually UDP protocol)

Description: In specifying an authority in the configuration file, a server will create a listening socket on the given port for the given protocol on its default network adapter, and incoming requests will be processed based on the designated tasks. Without authorities, GNS servers have no purpose.

 

3.2.2 authgroupperm

Usage: authgroupperm <id> <permission flags> <group>

ID: The ID of the authority
Permission Flags: A number which consists of the following values OR'ed together:

1 = Login
2 = Read
4 = Write
8 = Create
16 = Destroy
32 = Grant permissions to others
64 = Deny permissions from others

Group: The name of the group

Description: This command specifies group permissions for a specific authority. Users associated with this group will inherit those permissions. Users require zone permissions in order to access authorities in the zone. Those may be assigned with zonegroupperm.

 

3.2.3 catalog

Usage: catalog <authority>

Authority: The numeric authority ID

Description: Creates a comma-delimited string of directory information pertaining to the default content folder of the specified authority. This string is sent to GNS clients that request a GNS_PURPOSE_CONTENT_CATALOG packet.

3.2.4 group

Usage: group <name>

Name: The name of the group

Description: This does nothing except declare a group's existence. A group is associated with multiple users to easily associate assign common permissions to those users. Use groupmember to add users to a group.

 

3.2.5 groupmember

Usage: groupmember <name> <user id>

Name: The name of the group previously declared by the group command
User ID: The ID of the user previously defined by the user command

Description: Adds a user to a group. The user will inherit all of the group's permissions.

 

3.2.6 home

Usage: home <FQGN>

FQGN: The fully qualified game name of the home zone

Description: The home command designates the home zone of the server itself. Servers that have no parents must still declare a home zone; in that case, the home would be a . symbol. Otherwise, the home zone should be the FQGN of the zone in which the server resides in your logical GNS topology.

 

3.2.7 interface

Usage: interface <alias>

Alias: The name of the plug-in

Description: Connect to a plug-in from a console. All further console commands are routed to the plug-in directly.

 

3.2.8 listen

Usage: listen <authority>

Authority: The numeric ID of the authority

Description: Listens for connections on an authority that is not in the server's logical home zone

 

3.2.9 loadplugin

Usage: loadplugin <alias> <filename>

Alias: The name of the plug-in
Filename: The path of the plug-in module relative to the server application

Description: Loads a plug-in from disk. This should be executed only upon server startup.

3.2.10 plugingroupperm

Usage: plugingroupperm <alias> <permission flags> <group>

Alias: The name of the plug-in
Permission Flags:

1 = Login
2 = Read
4 = Write
8 = Create
16 = Destroy
32 = Grant permissions to others
64 = Deny permissions from others

Group: The name of the group

Description: Assigns plug-in permissions to a user group

3.2.11 propnumber

Usage: propnumber <name> <value>

Name: The name of the property
Value: The numeric value

Description: Assigns a generic global property string to use totally at the application's discretion.

 

3.2.12 propstring

Usage: propstring <name> <value>

Name: The name of the property
Value: The string value

Description: Assigns a generic global property number to use totally at the application's discretion.

 

3.2.13 user

Usage: user <ID> <name> <password> <home zone> <concurrency flag> <full name>

ID: The unique ID of the user
Name: The name of the user
Password: The password of the user, or null for no password.
Home Zone: The home zone of the user. The user will not exist outside its home zone.
Concurrency Flag: 0 if the user can only be logged on one connection at a time, or non-zero if the user can be logged into multiple connections concurrently.
Full Name: The full name of the user

Description: The user command adds a user to the GNS server under the given home zone. GNS users, including gnsroot and anonymous, are referenced when client connections send login packets, and used to determine what permissions the clients may use.

 

3.2.14 zonegroupperm

Usage: zonegroupperm <FQGN> <permission flags> <group>

FQGN: The fully qualified game name of the logical zone the permissions apply to
Permission Flags:

1 = Login
2 = Read
4 = Write
8 = Create
16 = Destroy
32 = Grant permissions to others
64 = Deny permissions from others

Group: The name of the group

Description: This command specifies group permissions for a specific zone. Users associated with this group will inherit those permissions. Users require zone permissions in order to access authorities in the zone.

 

3.3  Error Reporting

To have your GNS server actively collecting error reports, you must perform a series of steps on server startup. Please refer to the gns.conf file included in this project for examples:

1 Load the GNS MySQL plug-in

The GNS MySQL plug-in must be loaded on startup. You may download the plug-in at http://www.gamieon.com/gns if you have not already. Once downloaded and built, place it in your servers working directory. Then, add the following line near the beginning of your gns.conf file:

loadplugin gnsMySQL gnsMySQLD.dll

2 Add an error report authority

In the gns.conf file, add an auth[ority] line to designate an error reporting manager. It must have the errreport task flag.

3 Grant authority permissions to the player user group

In the gns.conf file, add an authgroupperm line allowing WRITE access to the authority.

4 Assign MySQL information to the configuration file

The GNS server has no inherit way of knowing the MySQL server settings, so it must be given the connection information. Here is an example of what to add to your gns.conf:

propstring bugrep_mysql_ip 192.168.1.102
propstring bugrep_mysql_user gns
propstring bugrep_mysql_pwd null
propstring bugrep_mysql_db gns
propnumber bugrep_mysql_port 3306

 

When an error report is submitted to a GNS server, it will write the information to the MySQL server. If the GNS tables do not exist, they will automatically be created. Please refer to gnsException.cpp for details on table generation and query execution.

 

3.4  Product updates

The following takes place in a complete product update transaction:

  1. Client send a GNS_PURPOSE_CONTENT_CATALOG packet to the server. The authority used in the transaction points to a directory on the server which contains an image of the product's installation folder.
  2. Server responds with the catalog; a comma-delimited Unicode string with directory listing information.
  3. Client disconnects from the server.
  4. Client traverses the catalog string looking for missing files, or deviations in file checksums or sizes. These files are added to a download request list.
  5. Client reconnects to the server, then sends a GNS_PURPOSE_DOWNLOADCONTENT packet once for each file in the download request list. This is done one at a time. The server responds to each request and sends the file. The client saves these files in a temporary directory.
  6. Client disconnects from the server.
  7. Client copies the files from the temporary directory to the installation path of the application.
  8. Client deletes the temporary folder

 

To support product updates, the GNS server must do the following on startup:

1 Add a content authority

In the gns.conf file, add an auth[ority] line to designate content management. It must have the content task flag. The content directory of the authority must point to an image of an already-installed version of the application.

2 Catalog the authority

From the gns.conf file, the GNS server must be instructed to catalog the files in the authority's content folder.

Example: catalog 2 7 1

In the example, the authority with the ID of 2 will have the filename, CRC32, and file size of each file catalogged recursively.


Next Previous Contents