2.5. Mirroring Data to Windows or other nodes in Linux or QNX

Cascade DataHub™ for Linux and QNX : Version 7.2
	Chapter 2. Using the Cascade DataHub

The Cascade DataHub can mirror data with one or more other DataHubs in running in Windows, as well as Linux or QNX, across a LAN, WAN, or the Internet, using TCP. Mirroring means that the data and any updates to that data on one DataHub are exactly mirrored across the network onto another DataHub, and vice-versa. The only difference between the master DataHub and slave DataHub is that the slave initiates the connection, and a connection license is consumed on the master. Once the connection is established, they function exactly the same.

Each participating DataHub must be configured as mirroring master (server) or mirroring slave (client), or in some cases, both. If your system requires it, a single DataHub can act as a master to one DataHub and as a slave to another.

Each master-slave pair must have matching port numbers and domain names. Specifying port numbers and domain names is explained below.

2.5.1. Exchanging data between Windows and Linux/QNX

There are three possible ways to set this up:

To have the Windows DataHub initiate the connection, you would need to set it up as a slave, and set up the Linux or QNX DataHub as a master.
To have the Linux or QNX DataHub initiate the connection, you would need to set it up as a slave, and set up the Windows DataHub as a master.
As a third alternative, you can use Cascade Connect instead of the DataHub in Windows, however you must keep in mind that Cascade Connect always functions as a slave, and it only connects to DDE-enabled programs. Please refer to the Cascade Connect manual for details on setting it up for mirroring. You would set it up the Linux or QNX DataHub as a master

2.5.2. Exchanging data between Linux/QNX and Linux/QNX

For this scenario, you would set up whichever DataHub you wanted to initiate the connection as a master, and set up the other DataHub as a slave.

2.5.3. Mirroring Master Setup - Linux or QNX

You can set up the Cascade DataHub to act as a mirroring master on Linux or QNX in either of these two ways:

Run the DataHub with the -p option. This tells the Cascade DataHub to listen as a TCP master on the port or service you specify. Normally you would use port 4600, which we have arbitrarily chosen as the "normal" port, but any port number will do so long as the client (slave) uses the same port number.
```
[sh]$  datahub -p port/service
```
For example:
```
[sh]$  datahub -p 4600
```

Create a configuration file or use an existing one. Make sure the following lines are in the file:

(tcp_service 4600)
(enable_tcp_server 1)
(enable_mirror_master 1)

Then run the DataHub with the -f option:

[sh]$  datahub -f /path/to/my/configfile.cfg

For example:

[sh]$  datahub -f /usr/local/misc/dhconfig.cfg

2.5.4. Mirroring Slave Setup - Linux or QNX

You can set up the Cascade DataHub to act as a mirroring slave on Linux or QNX in either of these two ways:

Run the DataHub with the -m, -M and -n options.

[sh]$  datahub -m port -M address -n domain

For example:

[sh]$  datahub -m 4600 -M 192.168.3.15 -n test

Create a configuration file or use an existing one. Make sure the following lines are in the file:
```
(create_domain domain_M)
(mirror_master address port domain_S domain_M)
(enable_mirror_slave 1)
```
The create_domain command is optional. It is used in this example to show how to make a domain on the slave DataHub that matches a domain on the master DataHub. The mirror_master command then sets up mirroring from domain_M on the master to a different domain, domain_S, on the slave. You can also mirror domains with the same name, say default, by simply specifying the same domain name for master and slave:
```
(mirror_master 192.168.3.15 4600 default default)
```
Once the file is ready, run the DataHub with the -f option:
```
[sh]$  datahub -f /path/to/my/configfile.cfg
```
For example:
```
[sh]$  datahub -f /usr/local/misc/dhconfig.cfg
```

2.5.5. Mirroring (Tunnel) Master Setup - Windows

You can configure your DataHub to act as a master for either plain-text tunnelling, secure tunnelling using SSL, or both. Each mode uses a separate port number or service name.

If you enter a name for the service/port instead of a number, that name must be listed in the Windows services file. Please refer to The Windows Services file Appendix for details.

The DataHub installs an SSL Certificate for you. If you wish to move it or use a different one, you can change the directory path here. The SSL implementation uses the default SSL-3 encryption cipher: DHE-RSA-AES256-SHA. This is a 256-bit encryption. The server and client negotiate the best encryption based on what both can support. The DataHub does not validate the SSL certificate with any outside certificate authority. It uses the SSL connection for encryption only, not authentication.

You can also configure the master to attempt to send "old" data (superseded by more recent data). Check any or all of Boolean, Integer, Float, or String that apply to the kind of superseded data that you wish to have sent.

To optimize throughput using this option, please refer to Section 18.7, “How to Optimize”.

2.5.6. Mirroring (Tunnel) Slave Setup - Windows

Check the Act as a tunnelling/mirror slave to these masters box to have the Cogent DataHub act as a slave.

To add a master for this mode, click the Add Master... button. To edit a master, double-click it, or select it and press the Edit... button. Either button opens the Tunnel/Mirror Master window:

Type in the following information:

Primary/Secondary Host: The name or IP address of the host computer. This slave DataHub will alternate attempts to connect first on the primary host, then on the secondary host, back and forth until a connection is made. The secondary host is optional, and if not entered, all attempts to reconnect will be on the primary host. If the connection is interrupted, the DataHub will again alternate attempts at reconnection on the primary and secondary hosts.
Port: The port number or service name as entered in the Master service/port entry box of the master on the remote computer.
Secure (SSL): You can establish a secure connection using SSL tunnelling as long as the tunnelling master DataHub you are attempting to connect to has been configured for secure connections. (See above.)
Local data domain: The local Cogent DataHub data domain for this slave. It is common, but not necessary, to create or use an existing local data domain that has the same name as the remote data domain.
Remote data domain: The name of the remote Cascade DataHub data domain, which is the tunnelling master. Point names will be mapped from that data domain into the local data domain, and vice versa.
Remote user name: The user name for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.
Remote passwork: The password for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.

There is a DataHub running on Cogent's server that you can connect to for testing. Here are the parameters you will need to enter for it:

Primary Host: developers.cogentrts.com
Port: 4502
Local data domain: test
Remote data domain: test

You now have several options for the mirrored connection.

Data Flow Direction lets you determine which way the data flows. The default is read-only data flow from master to slave, but you can set up a read-write or write-only connection by choosing those options.

To optimize throughput, check the Read-only: Receive data from the Master, but do not send option. Only do this if you actually want a read-only connection. If you do not require read-write access, a read-only tunnel will be faster.

When the connection is initiated determines how the values from the points are assigned when the slave first connects to the master. There three possibilities: the slave gets all values from the master (the default), the slave sends all its values to the master, or the data from master and slave gets synchronized. The availability of these options depends on the data flow direction selected above.

When the connection is lost determines where to display the data quality as "Not Connected", on the master, on the slave, or neither.

If you have configured When the connection is initiated as Synchronize based on time stamp (see above), then this option must be set to Do not modify the data quality here or on the Master to get correct data synchronization.

Connection Properties gives you these options:
- Replace incoming timestamp... lets you use local time on timestamps. This is useful if the source of the data either does not generate time stamps, or you do not trust the clock on the data source.
- Transmit point changes in binary gives users of x86 CPUs a way to speed up the data transfer rate. Selecting this option can improve maximum throughput by up to 50%, depending on the type of data being transmitted. This option uses a more efficient message encoding scheme than the default ASCII encoding, but it will only work if both sides of the tunnel are running on an x86 architecture CPU. This would be typical of Windows communicating with Linux or QNX, or with another Windows computer. Numeric data benefits most from this option.
- Target is a Cogent Embedded Toolkit server allows this slave to connect to an Embedded Toolkit server rather than to another DataHub.
- Heartbeat sends a heartbeat message to the master every number of milliseconds specified here, to verify that the connection is up. Setting this value to 0 stops the heartbeat from being transmitted.
- Timeout specifies the timeout period for the heartbeat. If the slave DataHub doesn't receive a response from the master within this timeout, it drops the connection. You must set the timeout time to at least twice the heartbeat time. Setting this value to 0 will cause the DataHub to rely on the TCP implementation for detecting a broken connetion. This can be useful when your network connection is very slow. Please refer to Section 18.2, “Tunnel/Mirror (TCP) Connections for Slow Networks” for details.
- Retry specifies a number of milliseconds to wait before attempting to reconnect a broken connection.


2.4. Working with Data		2.6. Viewing Data