5.3. Configuring the DataHub instance for the client
Prev Chapter 5. Tunnelling OPC DA Next

5.3. Configuring the DataHub instance for the client

Configuring tunnelling on the client side also comprises two tasks: configuring the tunnel/mirror connection and making the OPC client connection.

Now you need to set up the DataHub instance on this machine to tunnel across to the DataHub instance on the OPC DA server machine.

Configure a DataHub instance as tunnelling slave

The tunnelling slave DataHub instance behaves exactly like the tunnelling master DataHub instance except that the slave establishes the tunnelling connection initially, and reestablishes it after a network break. If there are no firewalls between the server and master sides, we recommend that the DataHub instance on the client side act as the tunnelling slave, while the DataHub instance on the server side act as the tunnelling master. If, however, you need to connect across a firewall, we recommend this scenario. For now we assume the simplest, no-firewall scenario.

  1. Right click on the DataHub system-tray icon and choose Properties.

  2. In the Properties window, select Tunnel/Mirror.

  3. Check the box Act as a tunnelling/mirror slave to these masters.

  4. Click the Add Master... button to assign a master to this slave. The Tunnel/Mirror Master Configuration window will open:

  5. Type in the following information:

    • Connection Name  a name to identify the tunnel. There should be no spaces in the name, and it doesn't matter what name is chosen, but it should be unique to other tunnel names.

    • Primary Host  the name or IP address of the computer running the tunnelling master DataHub instance.

    • Port  the port number or service name for this host. You should use default port number (4502) unless you have changed the entry in the master DataHub instance.

    • Secondary Host  gives you the option to have an alternate host and service/port number. On startup or after a network break, the DataHub instance will search first for the primary host, then for the secondary host, alternating between primary and secondary until a connection is made. If no secondary host is specified, the connection will be attempted on the primary host only.

      [Note]

      This feature is not recommended for implementing 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 DA 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.

    • Local data domain  The data domain in which you plan to receive data.

    • Remote data domain  the master DataHub data domain from which you plan to receive data. Point names will be mapped from the remote data domain (on the master DataHub instance) into the local data domain (on this DataHub instance), and vice versa.

      [Note]

      Unless you have a good reason for making these different, we recommend using the same data domain name on both DataHub instances for the sake of simplicity.

    • 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)  lets you 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. The additional options allow for a connection to be made even if the security certificate is invalid, or the host name does not match. We don't recommend using these options unless absolutely necessary. For more about SSL, please refer to SSL Encryption.

    • WebSocket  lets you 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.

      [Important]

      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 here).

    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)  Must be selected.

  6. You now have several options for the mirrored connection.

    1. Data Flow Direction  lets you determine which way the data flows. The default is bi-directional data flow between slave and master, but you can effectively set up a read-only or write-only connection by choosing that respective option.

      [Note]

      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.

    2. 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 slave sends all its values to the master, or the master and slave synchronize their data sets, point by point, according to the most recent value of each point (the default).

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

      [Note]

      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.

    4. 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%.

        [Note]

        For more information, please refer to Binary Mode Tunnel/Mirror (TCP) Connections in Optimizing Data Throughput.

      • 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.

      • 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 at least twice the heartbeat time.

        [Note]

        To optimize this setting, please refer to Tunnel/Mirror (TCP) Heartbeat and Timeout in Security.

      • Retry  specifies a number of milliseconds to wait before attempting to reconnect a broken connection.

  7. Click OK to close the Tunnel/Mirror Master window. The fields in the Tunnelling Slave table of the Properties Window should now be filled in.

  8. Click the Apply button in the Properties Window. If the master DataHub instance is running, this DataHub instance should establish the tunnelling connection, and the Status should display Connected. You can view the data with the Data Browser, or view the connection with the Connection Viewer.

See also Tunnelling Security - Best Practices.

Configure the DataHub instance for OPC DA

[Note]

If you are tunnelling OPC A&E, please see OPC A&E Server for this part.

Finally, we suggest that you ensure that DataHub instance on the OPC DA client machine is configured to act as an OPC server. The DataHub program comes preconfigured that way, but it doesn't hurt to check.

  1. Right click on the DataHub system-tray icon and choose Properties.

  2. In the Properties window, select OPC DA.

  3. Ensure that the Act as an OPC Server box is checked.

    [Note]

    If your OPC client requires that you hand-enter the OPC server name, use either Cogent.CogentDataHub or Cogent.CogentDataHub.1 .

  4. For information on any of the other options, please refer to the OPC DA Server section in Properties.

  5. Click Apply button at the bottom of the Properties window to apply the change. You can view connections with the Connection Viewer.

Now you can start your OPC DA client, connect to the DataHub instance, and access your data.

Prev Up Next
5.2. Configuring the DataHub instance for the server Home 5.4. Testing the connection