Cascade DataHub™ :  Version 6.4
Prev Chapter 3. Making Connections Next

3.2. Mirroring Connections

Mirroring is how two or more Cascade DataHubs link over a network or the Internet to maintain identical data sets. For every mirroring connection, you must assign one participant to be the master, and the other to be the slave. This determines which program initiates communication. Once communication is established, the data is identical. Generally it is recommended that the DataHub on the server or the machine least likely to shut down act as the master, while the slave be on the client machine.

[Note]

This kind of mirroring connection can be used to connect to Cascade DataHub running in Linux. Please refer to the Mirroring Data section of the Cascade DataHub for Linux and QNX manual for details.

To connect two Cascade DataHubs, first decide which DataHub is to be the master, and which the slave. Then follow these steps:

3.2.1. Configure the master DataHub

  1. On the machine where the master DataHub will run, start the Cascade DataHub, right click on the DataHub system-tray icon and choose Properties.
  2. In the Properties window, select Tunnel/Mirror .
  3. In the Tunnelling/Mirror Master section, check either Accept plain text connections or Accept secure connections, or both, depending on your needs.
  4. Determine which service or port number you wish to use, and if necessary, change the default entry in ...on service/port from 4600 or 4601 to your choice.
  5. For secure connections, 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.
  6. 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.
    [Note]

    To optimize throughput, un-check the Try to send data even if it is known to be superseded option. This will allow the DataHub to drop stale values for points which have already changed before the client has been notified of the original change. The latest value will always be transmitted.

  7. Click OK to close the Mirror Master window.
  8. Click OK to close the Properties Window.

You are now ready to configure the slave DataHub.

3.2.2. Configure the slave DataHub

  1. With the slave Cascade DataHub running, 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 tunneling/mirror slave to these masters.
  4. Click the Add Master... button. This opens the Tunnel/Mirror Master Configuration window.
  5. Type in the following information:

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

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

      Secondary Host: gives you the option to have an alternate host and service/port number. On startup or after a network break, the DataHub 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.

      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) into the local data domain (on this DataHub), and vice versa.

      [Note]

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

    [Note]

    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: 4600

      Local data domain: test

      Remote data domain: test

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

        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. In most cases you will want to set the timeout time at least double the heartbeat time.

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

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

Open the Data Browser and select the data domain you requested to mirror. If the master Cascade DataHub has been correctly configured, you should now see all the master DataHub data for that data domain.

Prev Up Next
Chapter 3. Making Connections Home 3.3. Configuring Bridges

Copyright © 1995-2010 by Cogent Real-Time Systems, Inc. All rights reserved.