[Dxspider-support] More about routing.

[Dirk Koopman]

On Sat, 2003-01-18 at 09:22, Rene Olsen wrote:
> If you have more than one link in your spider, make sure that you don't accept the same 
> node info from more than one link. Lets say that you have two or more links to some 
> country, then you need to make sure that you only trust the node/user info from that 
> country from one of these nodes.

This is very prudent advice. 

> 
> Spider seems to be able to handle routing loops, but how do we expect it to keep track 
> of what is correct and what is not ?

Well, that's a good question. Let me try to explain how it is supposed
to work. 

What happens is this: A PC19,21 comes in. It has some nodes in it. There
is no indication of which node produced this PC19,21, the ONLY
information you have is that it come in down your neighbour's
connection. So you know that someone claims that that node is connected
somewhere down that 'leg' and has either connected (PC19) or
disconnected (PC21).

What I do is study my routing table and if it is a new node (PC19) or
the last connection to a node (PC21), I will emit the appropriate PC
sentence to all the other nodes. If it is a another route, I add it to
the routing table or if it takes one of many routes away (but still
leaves at least one) but don't emit a PC sentence. Obviously if it is a
duplicate I just ignore it.

The same sort of thing happens for PC16/17 but is simpler because at
least you can be reasonably certain that a user has logged in/out of a
specific node because the information is there in the PC sentence.

Unfortunately, this isn't foolproof. Especially if there are stale nodes
floating about. Currently the first interface that presents a PC19
probably gains the route to that node (unless that node connects
directly). There is no way of telling who has the 'best' route to a
node. 

It is probably true that, unless sysops shutdown down reasonably often,
DXSpider nodes may even be compounding the problem! It doesn't help when
certain sysops go for uptime records and stay running continuously for
150+ days (you know who you are :-). 

Actually, the chances of one of these sysops being part of the problem
is quite small because if you heavily looped, eventually, the node will
break - therefore they are not looped - therefore they aren't a problem.

However, if you ARE heavily looped, it may take weeks for it to finally
get so confused that it breaks. In the meantime it is helping everyone
else to get more confused.

Now this is the important bit:

Just because DXSpider is reasonably resistant to looping, does NOT mean
that you can connect everywhere and expect it just to work. You have
still to treat each connection as the source of a loop. In general terms
what you should do is establish a filtered full protocol connection to a
node that 'sees' a section of the network (eg EA7ZAB = EA,CT for me),
filter it down on input so that I only accept EA,CT nodes from him. Do
this for each of your connections. If you need really a duplicate,
ISOLATE it!  As an example, this is what I do:-

ED7ZAB-5 : route input
  filter1 accept call_dxcc ea,ct
GB7BAA : route input
 filter1 accept call_dxcc g,ei
DB0SUE-7 : route input
 filter1 accept call_dxcc dl,oe,hb9,hb0
PI4TUE-8 : route input
 filter1 reject call_dxcc g,ei
 filter2 accept call_zone 14
WR3D : route input
 filter1 reject call_zone 14,15,16
SK2DR-6 : route input
 filter1 accept call_itu 18

I have set the OUTPUT routes to the same thing on each of these DXSpider
nodes (by doing a rcmd <node> acc/route call_dxcc ... [note: NOT input])
which prevents them sending me nodes that I won't accept in the first
place. This aids efficiency!
 
My node default is:

node_default : route input
 filter1 accept call_dxcc 61,38
node_default : route
 filter1 accept call_dxcc 61,38

This isn't completely loop proof, but it isn't too bad and my node seems
to stay up for as long as I want it to.

Hope this helps.

Dirk
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Product, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.