In fact DXSpider has had a simple system for some time which is called -isolation. This is similar to what, in other systems such as +isolation. This is similar to what in other systems such as clx, is called passive mode. A more detailed explanation of isolation is given further below. This system is still available and, for simple networks, is probably all that you need.
-
The new functionality introduced in version 1.48 is filtering the node +
The new functionality introduced in version 1.48 allows filtering the node and user protocol frames on a "per interface" basis. We call this route filtering. This is used instead of isolation.
What this really means is that you can control more or less completely -which PC protocol frames, to do with user and node management, pass to -each of your partner nodes. You can also limit what comes into your -node from your partners. You can even control the settings that your -partner node has for the routing information that it sends to you +which user and node management PC protocol frames pass to each of your +partner nodes. You can also limit what comes into your node from your +partners. It is even possible to control the settings that your partner +node has for the routing information that it sends to you (using the rcmd command).
-
The first thing that you must do is determine whether you need to do route filtering at all. If you are a "normal" node with two or three partners -and you arranged in an "official" non-looping tree type network, then you do -not need to do route filtering and you will feel a lot better for not -getting involved. If you are successfully using isolation then you -also probably don't need to use route filtering. -
-
You will only require this functionality if you are -"well-connected". What that means is that you are connected to several -different parts of (say) the EU cluster and, at the same time, also -connected to two or three places in the US which, in turn are -connected back to the EU. This is called a "loop" and if you are -seriously looped then you need filtering. +
The first thing that you must do is determine whether you need to use +route filtering at all. If you are a "normal" node with two or +three partners and you arranged in an "official" non-looping tree type +network, then you do not need to do route filtering and you will +feel a lot better for not getting involved. If you are successfully using +isolation then you also probably don't need to use route filtering. +
+
To put it simply, you should not mix Isolation and Route Filtering. It +will work, of sorts, but you will not get the expected results. If you +are using Isolation sucessfully at the moment, do not get involved in +Route Filtering unless you have a good supply of aspirin! Once you have +started down the road of Route Filtering, do not use Isolation either. +Use one or the other, not both. +
+
You will only require this functionality if you are "well-connected". What +that means is that you are connected to several different parts of (say) +the EU cluster and, at the same time, also connected to two or three places +in the US which, in turn are connected back to the EU. This is called a +"loop" and if you are seriously looped then you need filtering.
I should at this stage give a little bit of background on filters. All the filters in Spider work in basically the same way. You can either @@ -117,7 +124,8 @@ channel_zone <numbers>
Please be careful if you alter this setting, it will affect -ALL your links! +ALL your links! Remember, this is a default +filter for node connections, not a per link default.
For the default routing filter then you have two real choices: either a "national" view or the "safe" option of only your own @@ -154,9 +162,9 @@ information from anyone else. Although it doesn't explicitly say so, by implication, any other node information (not from the UK and Eire) is accepted.
-
As I imagine it will take a little while to get one's head around all of this you -can study the effect of any rules that you try by watching the debug output -after having done:- +
As I imagine it will take a little while to get one's head around all of +this you can study the effect of any rules that you try by watching the +debug output after having done:-
@@ -191,8 +199,8 @@ accept/route <node_call> <filter_option>
-rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
-rej/route all (equiv to [very] restricted mode)
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
+rej/route all (equiv to [very] restricted mode)
acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
@@ -206,7 +214,8 @@ acc/route gb7baa all
acc/route gb7baa input all
or restricting it quite a lot, in fact making it very nearly like an isolated node, like this:- +
or restricting it quite a lot, in fact making it very nearly like an +isolated node, like this:-
@@ -218,9 +227,9 @@ rej/route pi4ehv-8 input call_dxcc 61,38
but only sends him my local configuration (just a PC19 for GB7DJK and
PC16s for my local users).
-
It is possible to do much more complex rules, there are up to 10
-accept/reject pairs per callsign per filter. For more information see the
-next section.
+
It is possible to write much more complex rules, there are up
+to 10 accept/reject pairs per callsign per filter. For more information
+see the next section.
1.5 General filter rules
@@ -506,11 +515,48 @@ $def_hopcount = 5;
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.
+
SHould any of the nodecalls include an ssid, it is important to wrap the
+whole call in single quotes, like this ...
+
+
+
+ 'DB0FHF-15' => {
+ 11 => 5,
+ 12 => 8,
+ 16 => 8,
+ 17 => 8,
+ 19 => 8,
+ 21 => 8,
+ },
+
+
+If you do not do this, you will get errors and the file will not work as
+expected.
+
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.11 Isolating networks
+1.11 Hop Control on Specific Nodes
+
+
+
You can set a callsign specific hop count for any of the standard filter
+options so:-
+
+
+
+set/hops gb7djk spot 4
+set/hops node_default route 10
+set/hops gb7baa wcy 5
+
+
+all work on their specific area of the protocol.
+
+
The set/hops command overrides any hops that you have set otherwise.
+
+
You can set what hops have been set using the show/hops command.
+
+
1.12 Isolating networks
It is possible to isolate networks from each other on a "gateway" node using the
@@ -528,25 +574,12 @@ 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
-];
-
-
+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 use
+an acc/spot >call< all filter to override the isolate.
Next