xfServer is a data server that provides remote access to Synergy DBMS databases from Synergy applications. It uses a proprietary data transfer protocol to speed network communication and supports encryption for the secure transfer of sensitive data across networks. xfServer also includes system management utilities to monitor system activity and provides server-side logging of remote access requests, data passed and returned, and error information.
xfServer uses a fixed-port TCP/IP implementation. The default port is 2330, but it can be overridden, enabling users to resolve port conflicts and run multiple servers on a single host.
The basic xfServer system consists of a Windows and/or UNIX client application connected by a TCP/IP-based network to a Windows, UNIX, or OpenVMS server system. The client portion of xfServer is incorporated into the runtime of Synergy DBL for Windows and UNIX systems. The server portion of xfServer is a background process that can reside on any Windows, UNIX, or OpenVMS system. Once started in the background, the server program continually accepts requests from any client computers. The server program’s executable file is rsynd.exe (Windows), rsynd (UNIX), or rsynd.exe and rsdmse.exe (OpenVMS).
|
Although you can access remote data with a mapped drive or on an NAS (network-attached storage) drive, we recommend that you use xfServer instead. Mapped and NAS drives are known to cause data corruption. With xfServer, there is less chance of data corruption because xfServer properly closes files when a network connection is lost. In addition, xfServer is more efficient than mapped drives for file I/O. For more information on using mapped or NAS drives to access remote data, see Synergex KnowledgeBase article 2008. For information about configuring a client/server system for maximum performance, see Design and configuration for client/server systems and Optimizing network data access with xfServer. |
How the xfServer system operates
Let’s say we have a business contact application that is used by the account managers and support representatives in a large software company. The Synergy application is located on the PCs (the client systems) of the sales and support staff, while the data about customers, which needs to be shared, resides on a server. xfServer is what enables the server to accept client requests for data and send data back to the client PCs. Data requests and transfers between the client and the server will be completely transparent to the users.
How your application accesses files
To access remote files, you must specify the server name in your file specifications. You can do this directly or using a logical. We strongly recommend the latter, but describe both methods here.
The direct file specification method is to append the server name, in the form @server, to the filename in your Synergy DBL statements and subroutines. You can use either the host name of the server or the server’s fully qualified domain name. Alternatively, you can specify the server by IP address, using the form @address. For example, if your server’s host name is “tiger” and the IP address is 234.52.47.128, you can specify the file using either of the following forms:
file@tiger
or
file@234.52.47.128
If you are accessing a file on a separate domain, you can specify the file in the following form:
file@tiger.subdomain.com
|
|
A remote file specification cannot reference another remote file specification when the first file specification is on Windows. |
We recommend that you use a logical to specify the server address rather than using a direct specification. It is much easier to maintain your code and keep up with potential changes in the client/server system architecture if your application uses logicals. Ultimately, your system will translate your file specification to the direct form and use it to access the data, but under most circumstances, your program should not hard-code the file location. See Why use environment variables with xfServer? for more information about setting up logicals.
How the server works remotely on Windows and UNIX
The designs for the Windows and UNIX xfServer platforms are similar, with only a few differences. Because Windows and UNIX servers can handle multiple clients’ requests quickly, and starting a new session server process is transparent to the user, “standby” session servers are not needed. Instead, a Windows or UNIX server starts a new session server only when it receives a new client request.
xfServer operates on Windows and UNIX as follows:
| 1. | The server receives a request from a client application. |
| 2. | The server’s dispatcher starts a new session server process (server thread on Windows). |
| 3. | The new session server completes the connection to the client application. |
| 4. | The session server processes the client’s requests. After the process has completed all of the client’s requests, the session server process (server thread on Windows) terminates. See figure 1. |
|
|
How the server works remotely on OpenVMS
xfServer starts a pool of session server processes at server start-up. These processes maintain and communicate their status (“I’m busy” or “I’m waiting for a client request”) to the server connection manager.
As the session server pool is depleted by client requests, the connection manager starts additional servers in order to maintain the free pool. If there are a sufficient number of session servers in the free pool, these temporary processes are deleted after servicing the client’s request.
xfServer operates on OpenVMS as follows:
| 1. | The connection manager process (RSDMS$MGR_port) receives a request from a client application. |
| 2. | The connection manager assigns a session server process (SYNSRV_pid for xfServer and SYNLAU_pid for xfServerPlus, where pid is the system-assigned process ID) from the pool of processes. |
| 3. | The assigned process completes the connection to the client application. |
| 4. | The process services the client’s request. During processing, the connection manager won’t assign the process to another request. After the process has completed the client’s request, the process sends a message back to the connection manager and waits to be reassigned. See figure 2. |
|
|
