<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>The DXSpider Installation and Administration Manual : Hop control</TITLE>
+ <TITLE>The DXSpider Administration Manual v1.48: Scripts</TITLE>
<LINK HREF="adminmanual-5.html" REL=next>
<LINK HREF="adminmanual-3.html" REL=previous>
<LINK HREF="adminmanual.html#toc4" REL=contents>
+<link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
</HEAD>
<BODY>
<A HREF="adminmanual-5.html">Next</A>
<A HREF="adminmanual-3.html">Previous</A>
<A HREF="adminmanual.html#toc4">Contents</A>
<HR>
-<H2><A NAME="s4">4. Hop control</A></H2>
+<H2><A NAME="s4">4. Scripts</A></H2>
-<P>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).
+<P>From 1.48 onwards it will become increasingly possible to control DXSpider's
+operation with scripts of various kinds.
<P>
-<H2><A NAME="ss4.1">4.1 Basic hop control</A>
-</H2>
-
-<P>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 ...
-<P>
-<BLOCKQUOTE><CODE>
-<PRE>
-#
-# 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,
- },
-};
-</PRE>
-</CODE></BLOCKQUOTE>
-<P>
-<P>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.
+<P>In the first instance, in 1.48, the sysop can create, with their favorite
+text editor, files in the directory <EM>/spider/scripts</EM> which contain
+any legal command for a callsign or class of connection which will be executed
+at logon.
<P>
-<P>You can alter this file at any time, including whilst the cluster is running. If you alter the file during runtime,
-the command <EM>load/hops</EM> will bring your changes into effect.
+<P>
+The filename are the callsign of the connection that you want the script to
+operate on, eg: <EM>/spider/scripts/g1tlh</EM>. The filenames are always in
+lower case on those architectures where this makes a difference.
<P>
-<H2><A NAME="ss4.2">4.2 Isolating networks</A>
-</H2>
-
-<P>It is possible to isolate networks from each other on a "gateway" node using the
-<EM>set/isolate <node_call></EM> command.
-<P>
-<P>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.
-<P>
-<P>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.
-<P>
-<P>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 ....
+<P>In addition to the callsign specific scripts there are three others:-
<P>
<BLOCKQUOTE><CODE>
<PRE>
-$in = [
- [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
-];
+startup
+user_default
+node_default
</PRE>
</CODE></BLOCKQUOTE>
+<P>The <EM>startup</EM> script is executed immediately after all
+initialisation of the node is done, but before any connections are
+possible.
+<P>
+<P>The <EM>user_default</EM> script is executed for every user that does
+<B>NOT</B> already have a specific script.
+<P>
+<P>The <EM>node_default</EM> script is executed for every node that doesn't
+have a specific script.
<P>
-<P>There is a lot more on filtering in the next section.
+<P>There are a couple of examples in the <EM>/spider/scripts</EM> directory.
<P>
<HR>
<A HREF="adminmanual-5.html">Next</A>
projects / spider.git / blobdiff