Relay Server Configuration (rs.config)

The rs.config file is divided into four sections:

[relay_server] – defines configuration for a single Relay Server
[backend_farm] – defines a homogeneous group (e.g., a cluster) of back-end servers, which are targeted by client requests
[backend_server] – defines the connection to each back-end server, supported by one or more RSOEs
[options] – defines general configuration properties that apply to all Relay Servers in a cluster (farm)

[relay_server] Section

enable – Specifies whether the Relay Server is included in a Relay Server cluster.
Possible values are:
- yes
- no
Default is yes.
host – Host name or IP address to be used by the Outbound Enabler to make a direct connection to the Relay Server.
http_port – HTTP port to be used by the Outbound Enabler to make a direct connection to the Relay Server.
Possible values are:
- 0 or off — Disable HTTP access from Outbound Enabler
- 1 to 65535 — Enable HTTP access on the specified port
Default is 80.
https_port – HTTPS port to be used by the Outbound Enabler to make a direct connection to the Relay Server.
Possible values are:
- 0 or off — Disable HTTP access from Outbound Enabler
- 1 to 65535 — Enable HTTP access on the specified port
Default is 443.
description – User-definable description of the Relay Server, up to 2048 characters.

[backend_farm] Section

active_cookie – Specifies whether a cookie is set to maintain client-server session affinity.
Possible values are:
- yes — Relay Server injects a standard HTTP set-cookie command, with a proprietary cookie name in the response.
- no — Use this option when the back-end farm serves a sessionless browser application.
active_header – Specifies whether a header is set to maintain client-server session affinity.
Possible values are:
- yes — Relay Server injects a proprietary header in the response, in case intermediaries tamper with the active cookie.
- no — Use this option to reduce traffic volume, if the back-end farm serves only browser applications, or if the active cookie works for all clients of the back-end farm.
backend_security – Specifies the level of security required of an Outbound Enabler in the back-end farm.
Possible values are:
- on — All connections from the back-end farm must use HTTPS.
- off — All connections from the back-end farm must use HTTP.
If no value is specified, the Outbound Enabler can use either HTTP or HTTPS.
client_security – Specifies the level of security the back-end farm requires of its clients.
Possible values are:
- on — All clients must use HTTPS.
- off — All clients must use HTTP.
If no value is specified, the clients can use either HTTP or HTTPS.
description – User-definable description of the back-end farm, up to 2048 characters.
enable – Specifies whether to allow connections from the back-end farm.
Possible values are:
- yes
- no
Default is yes.
id – User-definable string that identifies the back-end farm, up to 2048 characters.
verbosity – Relay Server logging verbosity.
Possible values are:
- 0 — Log errors only.
- 1 — Session-level logging.
- 2 — Request-level logging.
- 3 - 5 — Detailed logging, used primarily for technical support.
Default is 0.

[backend_server] Section

description – User-definable description of the back-end server, up to 2048 characters.
enable – Specifies whether to allow connections from the back-end server.
Possible values are:
- yes
- no
Default is yes.
farm – User-definable string that identifies a back-end farm.
This property associates the back-end server with a back-end farm. This value must match the id value in a [backend_farm] section.
id – User-definable string that identifies the back-end server, up to 2048 characters.
MAC – MAC address of the network adapter used by Outbound Enabler to make a connection with the Relay Server.
If this property is not specified, Relay Server does not check the MAC address on Outbound Enabler connections.
token – A security token used by Relay Server to authenticate the back-end server connection, up to 2048 characters.
verbosity – Relay Server logging verbosity.
Possible values are:
- 0 — Log errors only.
- 1 — Session-level logging.
- 2 — Request-level logging.
- 3 - 5 — Detailed logging, used primarily for technical support.
Default is 0.

[options] Section

start – Method used to start the State Manager.
Possible values are:
- auto — State Manager is started automatically by Relay Server Web extensions.
- no — State Manager is started as a service.
- full path — Full path to the State Manager executable (rshost).
Default is auto.
shared_mem – Maximum amount of shared memory used for state tracking.
Specify a value and a unit (units are KB, MB, or GB); for example 2048 GB. If you do not specify a value, the default is 10MB. Sybase recommends adding the unit to the value to clarify the configuration setting.
verbosity – Relay Server logging verbosity.
Possible values are:
- 0 — Log errors only.
- 1 — Session-level logging.
- 2 — Request-level logging.
- 3 - 5 — Detailed logging, used primarily for technical support.
Default is 0.

Example: N+2 Architecture Configuration

There are two Relay Servers in a Relay Server farm: RS1.sybase.com and RS2.sybase.com. There are also two back-end server types: Afaria and Unwired Server. The Afaria system has two servers: Afaria1.sybase.com and Afaria2.sybase.com. There is one Unwired Server: SUP.sybase.com.

Relay Servers use Microsoft IIS, and the Web server is configured with the following paths:

\ias_relay_server\client – the install location of rs_client.dll.
\ias_relay_server\server – the install location of rs_server.dll, rshost.exe, and rs.config.

#---------------------------- # Relay server with auto start option #------------------------------------- [options] start = no verbosity = 1	Start State Manager as a Windows service.
#-------------------- # Relay server peers #-------------------- [relay_server] enable = yes host = RS1.sybase.com http_port = 80 https_port = 443 description = Machine #1 in RS farm [relay_server] enable = yes host = RS2.sybase.com http_port = 80 https_port = 443 description = Machine #2 in RS farm	Because there are two Relay Servers, both instances need to be defined in the peer list. This list is used by the RSOE to establish a connection with each Relay Server node in the farm.
#--------------- # Backend farms #--------------- [backend_farm] enable = yes id = AfariaFarm client_security = on backend_security= on description = This is the definition for the Afaria farm. [backend_farm] enable = yes id = SUPFarm client_security = on backend_security= on description = This is the definition for the SUP farm.	There are two types of back-end farms in this example. Unwired Server and Afaria. Each farm requires an entry in the [backend_farms] section, and each must have a unique Farm ID.
#----------------- # Backend servers #----------------- [backend_server] enable = yes farm = AfariaFarm id = for Afaria1.sybase.com mac = 01-23-45-67-89-ab token = 7b2493b0-d0d4-464f-b0de-24643e1e0feb [backend_server] enable = yes farm = AfariaFarm id = for Afaria1.sybase.com mac = 01-23-45-67-89-ac token = de1aac83-a653-4e0f-8a6c-0a161a6ee407 [backend_server] enable = yes farm = SUPFarm id = for SUP.sybase.com mac = 01-23-45-67-89-ad token = 621ece03-9246-4da7-99e3-c07c7599031c	There are three back-end server nodes in this scenario. Two are part of the AfariaFarm and the third is part of the SUPFarm. Afaria back-end servers use the Transmitter ID as the Server ID. Unwired Platform typically uses the machine name as the Server ID. The Server ID must be unique for each back-end server entry.

Note: When Relay Servers have been deployed and configured, clients connect to severs in the back-end farms differently:

For the AfariaFarm example, clients would use:

url_suffix=/ias_relay_server/client/rs_client.dll/AfariaFarm

For the SUPFarm example, clients would use:

url_suffix=/ias_relay_server/client/rs_client.dll/SUPFarm