Multi-op networking in Win-Test assumes you know at least a little about the TCP/IP protocol (in particular IP addressing and subnetting). This document outlines what you need to do to configure Win-Test for use across an Ethernet network in Win-Test.
Step 1: Configuring your Windows network
The first step is to configure your Windows network on all machines that you intend to run Win-Test on. You will need to set a fixed IP address on each machine and ensure the subnet mask matches on all machines.
You can view your networking configuration by visiting Windows' Control Panel, and double-clicking on the Networking icon. Ensure that the TCP/IP protocol is installed on all machines.
For simplicity, it is recommended you use an IP address in the range
192.168.0.x where 'x' is a number from 1 to 254. The subnet to match should be
255.255.255.0. Of course, the IP address should be different on each machine (increment 'x' by one for simplicity) but the subnet mask should be the same (i.e.
255.255.255.0). This is very important!
A screenshot of what to expect (Windows XP):
For configuring networking on a single computer to connect Win-Test and wtDxTelnet, please see DX_Cluster/Telnet.
Step 2: Configuring Win-Test for multi-op networking
The next step is to configure Win-Test itself to match your network configuration. This is a very easy task, especially if you have chosen to do the wise thing and configure your Windows network as instructed in step 1.
To configure Win-Test, you'll have to open the
Configure Interfaces dialog box, located under the
Options menu in Win-Test. You'll see a section on the right-hand side of this window titled
'Ethernet' and within this section, a checkbox with the text
Enable ethernet network. Ensure this box is ticked.
If you followed step 1, and configured your Windows network to have addresses in the range
192.168.0.x with the subnet mask
255.255.255.0, then simply use the details as given in the following image:
It is recommended you leave the port number as-is (set to 9871).
Settings for Win-Test networking on different IP ranges
If you have opted to use a different IP range than given in step 1, or if you are unable to control the IP addressing on your network, then here are the settings you require to enter in the networking configuration in Win-Test for other common internal IP addresses:
|IP address||Subnet||Win-Test configuration|
If, for whatever reason, you seem unable to get Win-Test networked using your IP address range/subnet, please send an email to the Win-Test support mailing list.
This has already been said, but it shall be said again: It is very important that you have matching broadcast addresses and port numbers on all the Win-Test machines running on the network. Failure to do so may result in partial log data being received by a machine whose broadcast address is incorrectly set - sometimes not always obvious until the contest is underway!
Step 3: Testing the network
By this stage, you have successfully configured both Windows and Win-Test for a multi-op environment. As a result, you should be able to open a test log (as always, ensuring you choose the same contest across the entire network) and try sending some gab messages to/from each machine. Use the Alt+G keyboard shortcut to open the gab window.
You can also enable time distribution across the network to ensure all Win-Test networked machines have times that match. Designate one machine on your network to control the time for the remainder of the network (perhaps you have a standalone machine running Win-Test and wtDxTelnet for monitoring and DX cluster access respectively?) and on this machine, tick the box that says
Enable time distribution across the network when opening a log. Please refer to the Menu:File new:Network_Parameters chapter for more details.
This is all that needs to be done - no settings have to be changed on the rest of the network.
You will probably now want to configure WtDxTelnet, a stand-alone application included in the Win-Test package for telnet DX cluster access. Follow the link below (under the 'See Also' section).
Log Synchronization has been introduced with Release 3.0.0.
It is based on a peer-to-peer model, where WT opened logs can be synchronized between all stations on a network, on-the-fly and without the need of a central server.
If new stations come in the network, or a station become alive after a reboot, during a contest, their logs are automatically updated, in a full transparent way and, of course, you still can run and enter QSOs while the synchronization process is in progress.
Log synchronization is turned on by default. The menu option Disable log synchronization on network will let the user turn off synchronization.
Please note that, in some circumstances, log synchronization can be automatically disabled. See note below:
Note: When a log is being opened in a networked environment, the date of the first QSO must match the others logs date with 20 days tolerance. If not, a warning will come up and the networking and synchronization will be disabled on this machine. You can override this behaviour if you really know what you're doing!
Large networks, spanning 20, 30 or more computers, probably connected via GRPS, Wireless and broadband links develop their own characteristics. Win-Test allows for several optimizations to keep network traffic at a reasonable level to avoid congestion, delays and other unwanted effects. The large network often combines a few computers in a LAN with other LANs via a WAN connection.
A specific program available only on special request that allows to establish a wide area Win-Test network via the Internet. This program is run on a central server and all other stations connect to this server via an application called the WT Tunnel.
Win-Test allows traffic shaping by configuring enabled and disabled protocol types. This allows setting up, for example, a silent backup on the network, or a scenario where two stations only share packet spots on the network, but nothing else.
The Bridgehead Concept
Foreword: This feature only works with the wtTunnel suite. In respect to the multi-ops categories ethics, this package is only available for HQ stations during the IARU HF contest.
In a large network it makes little sense for every computer to synchronize with every other computer. The traffic becomes extremely high, latency increases and data loss is happening. This is where the bridgehead concept comes into play.
In every LAN, one designated station serves as a hub, collects all local QSOs and shares them with other bridgehead stations through the WAN. The other bridgehead stations distribute the information in their LANs so that in the end, every computer will have the complete log.
Every computer in the LAN, except the bridgehead computer, will check the checkbox in the Ethernet Network Protocol Advanced Settings dialog like this:
[x] Restrict the sync QSO inventories to the LAN
The bridgehead computer will leave this box unchecked, so that it will synchronize with all computers.
Starting at 0 QSOs
Before the beginning of a contest like the IARU Radiosport, where many HQ stations are speead out all over the country, everybody needs to have 0 QSOs in the log. However, since some guys started to play around before the contest, the control station of the network will use a command to remotely delete all QSOs.
In the manual
- Subnet calculator (web page that help in defining Subnet Masks and Broadcast Addresses)