Hops, Network Isolation and other matters...

Last modified: Fri Jan 19 14:25:13 GMT 2001

Introduction

Starting with version 1.13 there is simple hop control available on a per node basis. Also it is possible to isolate a network completely so that you get all the benefits of being on that network, but can't pass on information from it to to any other networks you may be connected to (or vice versa).

Basic Hop Control

The number of hops that are set for all PC protocol messages (that require them) are specified in /spider/perl/DXProtVars.pm.

In versions prior to 1.13 you would move this file to /spider/local/ and modify the perl variables: $def_hopcount and %hopcount to some reasonable values.

From version 1.13 onwards a new mechanism has been introduced which uses a file called /spider/data/hop_table.pl. The prefered way of doing basic hop control is now to create this file and modify it as you wish. Eventually this file will contain all the hop control and related information. An example of the hop_table.pl file can be found in the /spider/examples directory.

You can change this file at any time, including when the cluster is running. If you do this then the changes only take effect after you have run the load/hops command on a client console with full sysop privileges.

Per Node Hop Control

From version 1.13 it is possible to control the number of hops to each node. This is done by adding information to the %nodehops perl variable in the hop_table.pl file (as described above). This variable is a perl "hash of hashes", which means that you create an entry for every callsign you wish to control and then one line for every PC protocol message that you wish to alter.

You can also have a entry called default for every callsign so you can set the hops as a whole for all PC messages to just that callsign. This is overridden by any specific hop counts you may have.

Example `hop_table.pl` File

An example for you:-

#
# hop table construction
#

package DXProt;

# default hopcount to use
$def_hopcount = 15;

# some variable hop counts based on message type
%hopcount =
(
    11 => 10,
    16 => 10,
    17 => 10,
    19 => 10,
    21 => 10,
);

#
# the per node hop control thingy
#
 
%nodehops =
(
    GB7DJK-1 => 
    {
         11 => 5,
         16 => 23,
         17 => 23,
         default => 50,
    },

    GB7TLH => 
    {
         19 => 45,
         21 => 45,
         16 => 45,
         17 => 45,
         default => 15, 
    },
);

The figures chosen are not necessarily what I use. What I would say is that until you are certain that you know what you are doing (and that the software is working at least as well as advertised) you should keep the default hop counts down to the sort of levels shown above.

Isolated Networks

It is possible to isolate networks from each other on a "gateway" node using the set/isolate <node call> command.

The effect of this is to partition an isolated network completely from another nodes connected to your node. Your node will appear on and otherwise behave normally on every network to which you are connected, but data from isolated network will not cross onto any other network or vice versa.

However all the spot, announce and WWV traffic and personal messages will still be handled locally (because you are a real node on all connected networks), that is locally connected users will appear on all networks and will be able to access and receive information from all networks transparently.

All routed messages will be sent as normal, so if a user on one network knows that you are a gateway for another network, he can still still send a talk/announce etc message via your node and it will be routed across.

The only limitation currently is that non-private messages cannot be passed down isolated links regardless of whether they are generated locally. This will change when the bulletin routing facility is added.