Define the Server Setup
Use the VTScada Thin Client/Server Setup dialog to create server lists, to identify each VTScada Thin Client Server in your system, the port on which they listen, whether the port will accept unsecured connections and whether the server is local so that the correct socket listener may be started.
The instructions to configure a server are the same for all client connection methods. It is the presence of the word "/mobile" or "/anywhere" in the connection address that distinguishes mobile device and Anywhere client connections from a thin client connection.
Localhost addresses are not permitted. ("Localhost", "127.0.0.1", and variants.) These are ambiguous when there is more than one VTScada server.
Refer to the notes that follow these instructions before configuring your server lists.
A server list can be configured only from a machine that is a member of the server list, and will remain a member of the server list after configuration.
- In the VAM, click on the VTScada Thin Client/Server Setup button.
The VTScada Thin Client/Server Setup dialog opens.
Colors within the list have meaning. Refer to the notes later in this topic.
- Enter the name of the first server you wish to add to the VTScada Thin Client Server list in the Server field.
The server list can be reordered later.
The name must be one to which clients can connect. In general, it is better to use a name than an IP address.
If you are using SSL, this must be the host + domain name, exactly as it appears in the "CN=" field on your SSL certificate.
- Enter the port number on which you wish this server to listen in the Port Number field.
The default port number is 80, the standard Hypertext Transfer Protocol (HTTP) port.
If you are using SSL, the standard port number is 443.
- Select the SSL check box if you wish to use Transport Layer Security to secure data that is transferred across the connection.
If this check box is not enabled, refer to discussion and instructions in the "Secure Your Application" topic, Internet Security (SSL, TLS, X509)
The Local check box will (later) be automatically checked if your network has a working name resolution system, and if the server name can be resolved to an IP address owned by this computer. Local is used so that the system can activate the correct socket listener.
The completed Add Server dialog for a remote server (not the local PC) should appear similar to the one displayed here.
- Click OK. The Add Server dialog closes, and you are returned to the Server Setup tab, where the server has been added to the server list.
- Repeat steps 2 through to 6 to add any other servers that should be part of this list.
The order that the server names appear in is significant for the ActiveX Internet Client. Should a connection be lost, that client will automatically attempt to connect to the next server in the list. The Anywhere and Mobile clients are not able to store this information.
- Click OK to save the server list and close the VTScada Thin Client/Server Setup dialog.
Notes:
The server list has two purposes:
- Provides the ordered list of servers that the thin clients will use to communicate with a server.
Under redundant operation, when the connection is lost to the current server, it will be picked up by the next in order. - Defines a license cluster. (License Clusters and Server Lists)
A server list can be configured only from a machine that is a member of the server list, and will remain a member of the server list after configuration.
For example, the following image shows a server list with two entries: Bridge-PC and EngineRoom-PC.
Color Coding:
After saving the list, entries are color-coded as follows:
- Black text: VTScada has contacted each listed server and all is well.
- Gray text: The server cannot be reached. It may be offline or there may be network issues.
- Red text: The server can be reached and has been found to be a member of another server list.
Servers cannot be members of two server lists simultaneously. It must be removed from one list or the other.
* Computer names (aka NetBIOS names) or IPs can be used in a server list only if all machines, including your VTScada Internet Servers and thin clients, are on an internal network.
* If some machines, clients or servers, are in different domains, then the list should include only fully-qualified domain names (FQDNs).
* If the names used by external clients to connect to your servers, (that is, names that are resolvable by an external DNS) are different from the internal machine names (those that are resolvable by your internal DNS or other methods) then your server list should include the external FQDNs. Your internal name resolution mechanism (DNS or other) should be configured to resolve those names to the internal IPs of the servers.
* Do not attempt to provide both internal and external names for the same server. Doing so will only cause slower overall performance.
In installations with many servers, there is no requirement that all of the servers be listed in a single license cluster. You might decide to maintain two or more smaller server lists in order to better manage license clusters.
If the Load Balancing option is selected, client connections will be distributed between servers automatically, reducing the load on any one particular server.
Server lists and configuration updates:
Server list members share information about all the connected client sessions across the cluster, along with license and configuration details. Updates to either the Realms or the Server Setup List on any one machine in the list are automatically propagated to all. Changes in timeouts or mode are automatically sent to all client sessions.
Clusters and Thin Client Connection licenses:
A cluster is a group of servers that serve Thin Clients. The servers in the cluster provide redundant failover for thin clients should one of the servers fail or be taken offline. You can have multiple clusters. As each thin client periodically tests the connection to each server in the cluster it is using, the more servers you have in a cluster, the higher the network traffic will be. A thin client that starts up and cannot contact all servers near the top of the server list for the cluster rapidly will have a slow startup. Therefore the number of servers in a cluster is a balance between redundancy and performance. If you have many thin client servers, it is better to organize the servers into small clusters. Note that a thin client cannot fail over across clusters - only to servers within a cluster.
License counts are combined within a cluster. You can connect more clients to any one server than would otherwise be allowed by its license limit, so long as the total number of connections within the server list does not exceed the license cluster’s limit. In theory, any one machine could support all the connections available within the cluster’s limits, although in practice this may exceed that machine’s CPU or RAM limitations.
If only one server in the list holds Thin Client Connection licenses, that machine must be added to the list first. If that machine is removed from the list, the remaining machines do not retain the ability to act as VTScada Thin Client Servers.
If a server fails, you do not lose its license count from the total during the time it is offline. All VIC connections to that machine are immediately re-routed to the remaining servers in the cluster that are running the application, even if this would exceed the licenses available on just those remaining machines.
If sub-networks within the organization become isolated such that the servers are temporarily unable to communicate with each other, each server will maintain the full license compliment of the cluster, even though this may exceed the license limit of that one machine.
When isolated servers reconnect, if the combined total number of connections exceeds the license cluster limit, no new connections can be made, but existing connections in excess of the limit are maintained.
While the server list maintains excess connections, an event will be logged in the alarm history every 10 minutes, warning of this state.
Realm session limits are maintained across a server list such that the total number of connections to a realm throughout the list may not exceed the configured limit.
Redundancy and Fail-Over
The following applies only to VIC and Anywhere connections. Both will receive the server list from whichever server it connects to and will periodically test the connection to each server in the cluster. If one fails, while a client is connected, the client will automatically connect to the next server in the list.
This does not apply to creating the initial connection, which must be made to an available server. The VIC stand-alone utility will maintain a list of the servers in the cluster, simplifying the task of connecting to the first available one if the preferred server is not available. The Anywhere client cannot do this because it is running within your browser and dependent on that for the initial connection. If using the Anywhere client and if you have multiple servers, you are advised to create a bookmark to each server's URL.
If the server to which a Mobile client (MIC) is connected fails, the connection is simply lost. The MIC makes no attempt to connect to an alternate server.
Server List / License Cluster Examples:
Reminder: The term "license cluster" refers to management of Thin Client Connection licenses. A Server List is a License Cluster.
A server list can be configured only from a machine that is a member of the server list, and will remain a member of the server list after configuration.
Servers A, B, C, D and E are all part of one network. VTScada is able to communicate across all.
On any of A, B or C, the following list is defined:
Server List
| A
| B
| C
This constitutes Server List 1. VTScada shares the thin client licenses between all three computers.
On any of D or E, the following list is defined:
Server List
| D
| E
If D were to be added to the first server list, it would appear as follows:
Server List
| A
| B
| C
| D
The red color indicates that D is already of member of another list and cannot be added to Server List 1. Its status in Server List 2 does not change. Server List 1 cannot "steal" a server from another list.
If your intent is to move D from Cluster 2 to Cluster 1, then first remove it from Cluster 2. Then add it to Cluster 1. Note that you cannot perform the second part of this action while working on machine D, as per the earlier warning. D cannot force itself into a cluster.
Port:
Set the port number to use on the selected server.
When configuring your server, ensure that you select a port that is not in use by any other process on your server. Port 80, the default HTTP port, is often used by other programs. You can check your server by opening a command prompt as an administrator, then running "netstat -ao". You can then check the process ID value in the Windows task manager. For example:
C:\WINDOWS\system32>NETSTAT -AO
Active Connections
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:80 MYSTATION-PC:0 LISTENING 4
TCP 0.0.0.0:81 MYSTATION-PC:0 LISTENING 10916This example shows that port 80 is in use by process id #4, which belongs to Windows. Port 81 is in use by process #10916, which happens to be a configured VTScada server in this example.
Fully Qualified Domain Names
* Computer names (aka NetBIOS names) or IPs can be used in a server list only if all machines, including your VTScada Internet Servers and thin clients, are on an internal network.
* If some machines, clients or servers, are in different domains, then the list should include only fully-qualified domain names (FQDNs).
* If the names used by external clients to connect to your servers, (that is, names that are resolvable by an external DNS) are different from the internal machine names (those that are resolvable by your internal DNS or other methods) then your server list should include the external FQDNs. Your internal name resolution mechanism (DNS or other) should be configured to resolve those names to the internal IPs of the servers.
* Do not attempt to provide both internal and external names for the same server. Doing so will only cause slower overall performance.
SSL:
Will be checked if this server uses a secure socket layer, as described in Internet Security (SSL, TLS, X509).
These notes and many VTScada dialogs will refer to SSL (secure socket layer) security. SSL and is an older technology and the term "SSL certificate" has become the de facto name for Internet security. Be assured that VTScada uses the more modern Transport Layer Security, implemented using X509 certificates.
Local:
Selected if this server allows connections from itself in addition to connections from other workstations
Connection Parameters: Read Timeout, Session Timeout and Mode
These three parameters are used to control how VIC sessions will switch servers in the event that the connection is lost to the one they are connected to.
Detecting a Lost Connection - Read Timeout
Under normal operation, the VTScada Internet Client works by sending requests to a VTScada Thin Client Server. The server will respond with data if there is any to send, or with an empty response if there is none.
If no response is sent to the VIC by the end of the read timeout period, then the VIC detects that a server has not responded. A loss of connection is assumed.
Therefore:
- A shorter read timeout results in more rapid detection of loss of the server, at the expense of increased network traffic.
- Too short a timeout may result in false detection of server failure.
If the VIC detects that the server has not responded, it closes its connection to that server and makes one attempt at re-establishing the connection. If this fails, the VIC will attempt to connect to the next highest-ranked server available, according to the order of the server list.
A read timeout of 15 seconds is recommended as the maximum setting for a LAN, and the minimum setting for a WAN. If your network serves both LAN and WAN connections then 15 seconds is recommended. Otherwise, adjust the value up or down as needed.
Because there is always one attempt to reconnect after a timeout, the time required for the VIC detect irrecoverable loss of communication with its server is twice the read timeout value.
Orphaned Sessions - Session Timeout
Loss of a connection between the VIC and the server will result in an orphaned session taking up resources on the server. The session timeout exists to let the server know when it should recover those resources and clean up such orphaned sessions.
When the server detects that there has been no communication from the VIC for the period of time specified in the Session Timeout, it destroys all resources used by the orphaned session.
The minimum session timeout that you can specify is four times the read timeout value. An orphaned session will remain visible in the Thin Client Monitor display until the server destroys it at the end of the session timeout.
Mode of Operation
The Mode of Operation determines how the VIC will behave when:
- The VIC loses communication with its current server.
- A higher-ranked server than the one the VIC is connected to becomes available.
There are two choices for the VIC Mode: Priority or Sticky.
The VIC will always attempt to establish communication with the highest-ranked available server when loss of communication to its current server is detected.
When the VIC detects that a server of higher priority than the one it is connected to becomes available, it will connect to that server and terminate the older connection.
The VIC will always attempt to establish communication with the highest-ranked available server when loss of communication to its current server is detected.
The VIC will not switch connections if it detects that a server of higher priority than the one it is connected to becomes available.
Note that the timeouts and VIC Mode are transmitted to the VIC at the start of each session, therefore the VIC will operate with whatever is configured on the server when it connects to it.
When the VIC makes its initial connection, it simultaneously attempts to connect to each server in the list and uses the server nearest the top of the list that it can successfully establish a session with. The VIC waits for an initial period of time, or until the highest-order server responds - whichever is shorter - then it selects and connects to a server. This initial timeout is left up to the TCP subsystem of the client computer and is normally around 20 seconds.
If there are no servers available, the VIC will continue to try to connect to each server.
This box is selected by default, but relevant only if you have more than one VTScada Thin Client Server for an application. When selected, new VIC connections will automatically go to whichever server in a cluster has the fewest connections.
Opens the Modify Server dialog, where you can change the port number of the selected server and you may choose to disable it.
The Enable option can be changed only if VTScada is able to detect the server - this may not be the case if the name resolution system is unable to find the specified server.
To change a server’s name or IP address, you must delete the old and create a new. An existing name or address cannot be changed.
Troubleshooting:
- Port conflicts.
You may configure a realm or a VTScada Thin Client Server on any port you desire. However, if connecting from a public network (e.g. the Internet), you will likely have to traverse firewalls and other security mechanisms. Configuring a realm or VTScada Thin Client Server to operate on other than the standard ports (port 80 for plain text HTTP, or port 443 for SSL-secured HTTPS), will likely require special configuration. It is therefore advisable to operate on the standard ports whenever possible.
