Hops, Network Isolation and other matters...

X-Git-Url: http://gb7djk.dxcluster.net/gitweb/gitweb.cgi?a=blobdiff_plain;f=html%2Fhops.html;fp=html%2Fhops.html;h=5ffa84c38ab11323ce2842debc6a8e7be20099ad;hb=cce161221036760959ff1d0b7628a55942bf558a;hp=0000000000000000000000000000000000000000;hpb=69c8aeb338cc485103e289fbab7ec4e7e056ed20;p=spider.git diff --git a/html/hops.html b/html/hops.html new file mode 100644 index 00000000..5ffa84c3 --- /dev/null +++ b/html/hops.html @@ -0,0 +1,159 @@ + + + + Hops, Network Isolation and other matters... + + + + + + + +

Hops, Network Isolation and other matters...

+ + + +

Dirk Koopman G1TLH

+ + +Last modified: Sun Dec 20 18:15:15 GMT 1998 + + +

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_count.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_count.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_count.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_count.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. + + +