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). +
+
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. +
+
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 .... +
+
+
+$in = [
+ [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
+];
+
++
There is a lot more on filtering in the next section. +
+