3.6. Tunnel/Mirror


3.6. Tunnel/Mirror
Prev	Chapter 3. Properties Window	Next

The Tunnel/Mirror option lets you configure the DataHub program to act as a master or slave for tunnelling/mirroring. Tunnelling/Mirroring allows you to send any data in a DataHub instance across a network robustly and securely. Tunnelling is done using DHTP over TCP, which provides connectivity across a network or over the Internet.

Tunnelling and Mirroring

The DataHub tunnelling connection is sometimes referred to as a mirroring connection. Mirroring means that the data and any updates to that data on one DataHub instance are exactly mirrored across the network onto the other DataHub instance, and vice-versa. For all practical purposes, tunnelling and mirroring are identical.

Direct TCP connections

In addition to tunnelling, the DataHub program can accept direct DHTP connections from any TCP client using the DataHub APIs for C++, Java, and .NET, such as DataSim or other, custom applications.

Master and Slave

We identify the two tunnelling/mirroring DataHub instances as master and slave. The only difference between the master DataHub instance and slave DataHub instance is that the slave initiates the connection. Once the connection is established, they function exactly the same. It is possible for a DataHub instance to be both tunnelling/mirroring slave and master simultaneously—acting as a slave to one or more DataHub instances and a master to one or more others. For slave mode you need to specify each master.

Tunnel/Mirror Slave

Check the Act as a tunnelling/mirror slave to these masters box to have the DataHub instance 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:

Connection Name

A name used by the DataHub instance to identify the tunnel. There should be no spaces in the name. It doesn't matter what name is chosen, but it should be unique to other tunnel names.

Primary/Secondary Host

The name or IP address of the host computer. This slave DataHub instance 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 instance will again alternate attempts at reconnection on the primary and secondary hosts.

This feature is not recommended for redundancy because it only checks for a TCP disconnect. The DataHub Redundancy feature, on the other hand, provides full-time TCP connections to both data sources, for instantaneous switchover when one source fails for any reason. There is no need to start up the OPC server and wait for it to configure its data set. You can also specify a preferred source, and automatically switch back to that data source whenever it becomes available. By contrast, the primary and secondary host in the tunnel can act as a primitive form of redundancy, but will only switch on a connection failure at the TCP level, which is only one sort of failure that a real redundancy pair must consider.

Port

The port number or service name as entered in the Master service/port entry box of the master on the remote computer.

Local data domain

The local 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 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 password

The password for TCP security, established on the tunnelling master, using the DataHub Security option in the Properties window.

Secure (SSL)

You can establish a secure connection using SSL tunnelling as long as the tunnelling master DataHub instance you are attempting to connect to has been configured for secure connections. (See below.)

Selecting Reject invalid certificate causes the DataHub instance to check that the certificate date is valid, and the certificate chain is trusted. Selecting Reject host name mismatch will have the DataHub instance check that the certificate subject matches the host name. If you select neither of these two boxes then any certificate will be accepted. This is not recommended because it is not good security, but it can be useful to test the SSL connection. For more about SSL, please refer to SSL Encryption.

WebSocket

You can connect via WebSocket. This option is applied for both primary and secondary hosts, and allows you to enter a Proxy address, and a Proxy port number, username, and password as needed. When tunnelling through a proxy, HTTP uses normal HTTP proxy, and HTTPS uses HTTP CONNECT proxy. You can select the Always use HTTP CONNECT to use it for HTTP as well as HTTPS.


	The WebSocket protocol requires a web server to act as an intermediary. So, for this option you will need to use the DataHub Web Server on the tunnelling master DataHub instance (as explained below).

There are 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 an Embedded Toolkit server allows this slave to connect to an Embedded Toolkit server rather than to another DataHub instance.
- 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 instance 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 instance to rely on the TCP implementation for detecting a broken connection. This can be useful when your network connection is very slow. Please refer to Tunnel/Mirror (TCP) Heartbeat and Timeout for details.
- Retry specifies a number of milliseconds to wait before attempting to reconnect a broken connection.

Testing the Client Connection

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

Primary Host demo.skkynet.com
Port Will be set automatically by the system, 80 for WebSocket and 443 for Secure (SSL).
Local data domain cloud
Remote data domain DataPid
Remote user name demo/guest
Remote password guest
WebSocket Must be selected.
Secure (SSL) Optional.

License verification timeout

The DataHub program gives a TCP connection 30 seconds to verify a license. If your network is too slow this might cause a licensing error. You can increase the timeout to up to 60 seconds by editing this registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Cogent\Cogent DataHub\TCPLicenseTimeoutSecs

Tunnel/Mirror Master

You can configure your DataHub instance to act as a master for plain-text or secure (SSL) tunnelling, or both. Additionally, the DataHub program offers WebSocket support for tunnelling, as explained below.

Accept plain text connections on service/port

This option enables plain text connections.


	For this and the next option, 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.

Accept secure connections on service/port

The DataHub instance 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 instance does not validate the SSL certificate with any outside certificate authority. It uses the SSL connection for encryption only, not authentication.

Try to send data even if it is known to be superseded

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 Tunnel/Mirror.

WebSocket Connections

The WebSocket protocol supports real-time bi-directonal data transfer over TCP, by maintaining a constant connection over which messages can be passed, in plain text or SSL. The DataHub implementation of WebSocket enables secure connections through network proxies without opening any firewall ports.

The WebSocket protocol requires a web server to act as an intermediary for the connection. So, to support incoming WebSocket connections from DataHub tunnelling clients, you will need to configure the tunnelling master DataHub Web Server. For WebSocket connections, we recommend using SSL, on port 443. A plain text connection is also possible, but is less secure and less likely to pass through a proxy.

Prev	Up	Next
3.5. OPC A&E	Home	3.7. Bridging