- 1. Hop control
-
- 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 any other networks you may be connected to
- (or vice versa).
-
-
- 1.1. Basic hop control
-
- In /spider/data you will find a file called hop_table.pl. This is the
- file that controls your hop count settings. It has a set of default
- hops on the various PC frames and also a set for each node you want to
- alter the hops for. You may be happy with the default settings of
- course, but this powerful tool can help to protect and improve the
- network. The file will look something like this ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- #
- # hop table construction
- #
-
- package DXProt;
-
- # default hopcount to use
- $def_hopcount = 5;
-
- # 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 =
-
- GB7ADX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
-
- GB7UDX => { 11 => 8,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- GB7BAA => {
- 11 => 5,
- 12 => 8,
- 16 => 8,
- 17 => 8,
- 19 => 8,
- 21 => 8,
- },
- };
-
-
-
-
-
- Each set of hops is contained within a pair of curly braces and
- contains a series of PC frame types. PC11 for example is a DX spot.
- The figures here are not exhaustive but should give you a good idea of
- how the file works.
-
-
- You can alter this file at any time, including whilst the cluster is
- running. If you alter the file during runtime, the command load/hops
- will bring your changes into effect.
-
-
-
- 1.2. Isolating 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 an 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.
-
-
- If you use isolate on a node connection you will continue to receive
- all information from the isolated partner, however you will not pass
- any information back to the isolated node. There are times when you
- would like to forward only spots across a link (maybe during a contest
- for example). To do this, isolate the node in the normal way and put
- in a filter in the /spider/filter/spots directory to override the
- isolate. This filter can be very simple and consists of just one line
- ....
-