The Remote Server and Client

The Remote Server and Client are the modules responsible for distributing Dataworks Enterprise data between target hosts using TCP/IP virtual circuits.

Dataworks Enterprise Remote System, supplied as part of Dataworks Enterprise product, allows the content of a Cache on one host to be ‘replicated’ on one or more other hosts using TCP virtual circuit technology. The Remote system consists of two standard Dataworks Enterprise components, the Remote Server and the Remote Client.

The Remote Server accepts connections from one or more Remote Clients. Sources that reside on the Remote Server are replicated in the Caches of each connected Remote Client. Applications residing on a Remote Client host can make requests for data in the normal fashion. The Remote Client accepts the request on behalf of the Server and passes the request information on to the server via the virtual circuit connection. The operation is completely transparent to the client. The Remote server receives the request information and passes the request on to the ‘real’ source. Replies from the source are passed back to the requesting application via the Remote Server and Client. From the application perspective, it is as if the sources that reside on the Remote Server are actually connected locally.

The Components of The Remote System

The Remote Client and Server interact with the underlying Cache message streams through standard COM interfaces. They take data from the system prior to local caching algorithms being applied. As a result, the Remote Server and Client do not maintain separate Cache copies of requested data, which considerably reduces the processing and memory overhead of these components.

In the event that the Remote Server has a connection to a platform (using a distribution system plug-in) all clients retrieve data using the connection at the Server. Thus, permissioning of information is applied according to the permissions of the Remote Server.

Remote System User Interface

In most installations the Remote Client and Server are launched by the launcher application and are hidden by default. When shown, via the launcher task dialog, the component displays a message log. Right clicking on the message log offers the option to delete the log. In addition, the Remote Server displays a tree view of its currently connected clients.


This component formed part of the basic component for the first release.






Remote System Installation

The Remote Data System can be installed directly from the distribution CD. During installation, the appropriate binaries and configuration files are copied to the disk and the launch scripts updated appropriately. Typically, the Remote Server is installed on a central host and one or more clients configured to connect to it. Usually, the Remote Client software is the only ‘data connection’ component running on the client, all data being requested via the server. In cases where the client needs to publish back to the distribution system, Dataworks Enterprise Publishing Client may also be installed.

The Remote Data System with Publishing via Dataworks Enterprise

Prior to execution, some additional changes may need to be made to the hosts running the software to allow the client to identify the hosts that are running the server software. If the client and server are run on the same IP sub network, Dataworks Enterprise Components automatically deduce the settings making further configuration unnecessary. This may be achieved in a number of ways depending on the site configurations. This might involve:

  • setting the Remote Client configuration to specify the hostname of the server, or
  • updating the HOSTS file to add ‘rtremote’ as an alias for an existing server, or
  • updating a local DNS system to add ‘rtremote’ as an alias for an existing server.

    The client and server also have configurations for port numbers and TCP optional parameters which, depending on the site, may also need to be changed.

    Running More than One Remote Client

    As described above, multiple clients can connect to a single Remote Server. This allows multiple applications in each client to retrieve data from the sources available in the server. In some complex scenarios, it may be necessary to attach to more than one Remote Server, for instance, where there is more than one distribution system in operation.

    As a result, a single client host may run more than one Remote Client, each of which connect to different Remote Servers. Each client uses its executable name as a configuration name, allowing more than one server to be configured. In the description provided below, we only use the standard client name ‘RemoteClnt’. For instance, the TCP port configuration is described as:

    Tosca.RemoteClnt.Port: 6511

    If there a second instance of the client is required, copy the binary into the user binary area and rename it (for example, ‘RemBkUp.exe’). The new binary will now read its port from the configuration:

    Tosca.RemBkUp.Port: 6521

    The clients will retrieve source data from each of the server. Note, however, that there are restrictions. For instance, each source must be unique to a given Remote Server (i.e. The same source cannot appear twice within any given host). If a second source is mounted with the same name as a already existing source, the first source is removed forcibly from the Cache. In this event, the removed component will, typically, generate an error and fail.

    The Remote Server is a single instance component and will not allow itself to be run more than once as there is no benefit to doing so.

    The system-supplied configuration files are installed into the standard configuration directory. Users should not edit these files. Instead they should create their own user configuration files (REMOTESVR.USR and REMOTECLNT.USR) and place these files in the configuration search path. These files will be included automatically by the standard configuration file. (See Configuration Files and Databases).

    All entries in the Remote Client configuration file begin with the prefix ‘Tosca.RemoteClnt’ indicating that the client is a standard Thomson Financial component called RemoteClnt. Similarly, all entries in the Remote Server configuration file are prefixed with ‘Tosca.RemoteSvr’.

    The Remote Client and Server have the same set of configurations. In the following situations, <component> should be replaced by ‘RemoteClnt’ or ‘RemoteSvr’ as necessary.

    General Configurations

    The Remote Client and Server support application-level heartbeats with an associated timeout in seconds. These are configured using ‘Tosca. <component>.Heartbeats’, which has a value 0 or 1, and ‘Tosca. <component>.Timeout’. Each component sends a heartbeat message every timeout seconds. If the peer does not receive either data or a heartbeat in the timeout, it attempts reconnection. Reconnection attempts are operated on every timeout during the disconnection phase.

    TCP Specific Configurations

    Many of the TCP configurations are shared between the Remote Client and the Remote server. These include the service, port and many optional TCP parameters.

    ‘Tosca.<component>,Service’ specifies the name of the service used to connect to the well-known socket of the Remote Server. If the service name is not defined, the components attempt to retrieve a port number to use as specified by ‘Tosca.<component>.Port’. If this is not defined, the Remote system uses port number 6511.

    In the case of the client, the configurations also define the name or names of servers to which to connect. This is held in the ‘Tosca.RemoteClnt.Server’ configuration. The configuration is a semi-colon delimited list of server names. This may be a DNS name, an IP address in dotted notation or an alias as provided in the HOSTS file.


    This component may optionally have a management source that provides statistics on current usage. For the client, the name of the source is:


    For the server it is:


    To use these sources, request the instrument "CATALOGUE". This will return a record containing a list of other records which can be requested and a list of commands that can be executed by the component. The actual content of this record depends on the module in question and is subject to change from time to time.

    Known Problems