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). -
-
From 1.48 onwards it will become increasingly possible to control DXSpider's +operation with scripts of various kinds.
-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 ... +
The directory /spider/scripts is where it all happens and is used for several +things. Firstly it contains a file called startup that can be used to call +in any changes to the cluster from the default settings on startup. This +script is executed immediately after all initialisation of the node is done +but before any connections are possible. Examples of this include how many +spots it is possible to get with the sh/dx command, whether you want +registration/passwords to be permanently on etc. An example file is shown +below and is included in the distribution as startup.issue.
-#
-# 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,
- },
-};
+#
+# startup script example
+#
+# set maximum no of spots allowed to 100
+# set/var $Spot::maxspots = 100
+#
+# Set registration on
+# set/var $main::reqreg = 1
+#
+# Set passwords on
+# set/var $main::passwdreq = 1
+#
-
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 .... +
As usual, any text behind a # is treated as a comment and not read. To use +this file, simply rename it from startup.issue to startup. In our example +above there are three options. The first option is the amount of spots that +a user can request with the sh/dx command. Normally the default is +to give 10 spots unless the user specifies more. Without this line enabled, +the maximum a user can request is 100 spots. Depending on your link quality +you may wish to enable more or less by specifying the number.
+ +The other 2 options are dealt with more fully in the security section.
+ +Secondly, it is used to store the login scripts for users and nodes. Currently +this can only be done by the sysop but it is envisaged that eventually users will +be able to set their own. An example is included in the distibution but here is +a further example.
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+#
+# G0FYD
+#
+blank +
+sh/wwv 3
+blank +
+sh/dx
+blank +
+t g0jhc You abt?
+blank +
-
There is a lot more on filtering in the next section. -
+
+The lines in between commands can simply insert a blank line or a character +such as a + sign to make the output easier to read. Simply create this script +with your favourite editor and save it with the callsign of the user as the +filename. Filenames should always be in lower case.
+ +Commands can be inserted in the same way for nodes. A node may wish a series +of commands to be issued on login, such as a merge command for example.
+ +Thirdly, there are 2 default scripts for users and nodes who do not have a +specifically defined script. These are user_default and +node_default
+