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 files are rsynd.exe (Windows), rsynd (Unix), and 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. |
For example, you might 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 customer data, 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 users of the application.
How your application accesses files
As of Synergy/DE 12, there are two ways to access remote files:
- Specify the xfServer server name in your file specifications with @server syntax.
- Use the %CREATE_SERVER_CONNECTION and %DESTROY_SERVER_CONNECTION routines to connect and disconnect from the xfServer machine.
Accessing files with a file specification
The traditional way to access files on the xfServer machine is to specify the server name in your file specification, either directly or with a logical. We strongly recommend the latter, but describe both methods here. This method can be used with any client or server.
The direct file specification method appends 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, adapt it to various customer sites, 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.
Accessing files using the connect and disconnect routines
The %CREATE_SERVER_CONNECTION and %DESTROY_SERVER_CONNECTION routines were added in Synergy/DE 12. To use these routines, both the client and server machines must be running v12 or higher (and code must be compiled with -qrntcompat of 12010100 or higher).
There are several reasons you may want to use these routines rather than a file specification to access xfServer:
- Better performance: using the connection routine enables you to maintain xfServer connections across OPEN statements, which is more efficient than opening a connection each time with the @server syntax.
- Your application needs to have two or more connections to a single xfServer machine where the xfServer instances are on different ports.
- You have an application that uses Harmony Core and would like a simpler implementation of files and server connections in a thread pool environment.
- You need more control over when a server connection is disconnected.
The basic procedure is to call %CREATE_SERVER_CONNECTION, passing the server name and port number. That function returns a handle, which is then used with the SERVERCONNECTION qualifier on the OPEN statement to access a file on the server. When you are finished accessing files, call %DESTROY_SERVER_CONNECTION to close the connection. For an example, see %CREATE_SERVER_CONNECTION.
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. |
|
|
