This option in the Properties Window lets you set up the Cascade DataHub to act as a master or slave for mirroring. 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 Cascade DataHub mirroring connection is sometimes referred to as a tunnelling connection. Tunnelling refers to the ability of the network connection to tunnel through a firewall. For all practical purposes, tunnelling and mirroring are identical. People working with the Windows OPC protocol tend to use the term "tunnelling" while people from other backgrounds often say "mirroring". So Cogent uses "mirroring" for the Cascade DataHub, and "tunnelling" for the OPC DataHub.
In addition to tunnelling, the Cascade DataHub can accept direct connections from any TCP client using the DataHub APIs for C++, Java, and .NET, such as DataSim or other, custom applications.
We identify the two mirroring DataHubs as master and slave. The only difference between the master DataHub and slave DataHub is that the slave initiates the connection. Once the connection is established, they function exactly the same. It is possible for a DataHub to be both mirroring slave and master simultaneously—acting as a slave to one or more DataHubs and a master to one or more others. For slave mode you need to specify each master.
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 11.7, “How to Optimize”.
Check thebox to have the Cascade DataHub act as a slave.
To add a master for this mode, click the Tunnel/Mirror Master window:button. To edit a master, double-click it, or select it and press the button. Either button opens the
Type in the following information:
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.
The port number or service name as entered in the Master service/port entry box of the master on the remote computer.
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.)
The local Cascade 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.
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.
The user name for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.
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
Local data domain: test
Remote data domain: test
You now have several options for the mirrored connection.
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.
If you have configured When the connection is initiated as (see above), then this option must be set to to get correct data synchronization.
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 11.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.
Copyright © 1995-2010 by Cogent Real-Time Systems, Inc. All rights reserved.