[Dxspider-support] talk messages

Dirk Koopman djk at tobit.co.uk
Sat Jan 20 19:23:59 CET 2007


Steve Murphy wrote:
> Understood.
> 
> So, then, what stops PC16s from propagating?
> 

Sysops, basically.

And they do this because otherwise you would not get a spot (or an 
ann/full) in edgeways. Basically, the problem is that the routing 
sentences are designed for a loop free network. Although various 
heuristics are in place to mitigate the fact that there are some loops, 
the main thing stopping (most) loops is accept and reject/route commands.

This partitions the network to a degree, sufficient to control the 
problem of the uncontrolled loops that would occur without these route 
control commands in place. Even now, when a new node comes on and asks 
for "everything" and then connects to two or three other nodes, we get 
the wall to wall PC16/17/19/21s (as well as PC41s).

I have addressed this problem in the upcoming 1.53 (finally)[and which 
is now in beta testing on 5 nodes] in these ways:

1. And most important, nodes only send out their own configuration, 
together with that of any *directly connected* "old style" nodes. They 
will do this every 30 mins.

2. Nodes are responsible for determining the shape of the network from 
these periodic broadcasts and are expected to "timeout" nodes that they 
have not heard from after 3 30 minute period.

3. Talk/Announce/Chat have been unified so that they are all either 
broadcast (Ann/Chat) or can be (and will) be broadcast (Talk) if no 
obvious route to a user/node exists. Because only absolutely accurate 
lists of routes will exist (from 1.53 PC9x capable nodes and their 
directly connected legacy nodes only) in each node, the edge nodes 
(which have everybody that they "think" is connected using oldstyle 
routing info) are responsible for gatewaying to/from these legacy nodes.

4. Messages (as in bulletins) will also be treated in roughly the same way.

5. PC41s will be aggregated and sent out as one PC95 sentence. It is 
possible that I may start to ignore any non-PC92 user data completely.

All this whilst maintaining full compatibility at the "edges" of the 
DXSpider "network". Incoming Talk messages will be proxied using the new 
protocol, as will chat, announces will simply be passed through.

All this is being done with some carefully designed sentences in the 
PC9x range which all have the general structure:-

PC9x^<origin node>^<timestamp^<rest of sentence>^H99^

No PC9x sentence will be sent to a node unless it advertises that it can 
handle it in the PC18 received on connection and the connecting node 
sends (at least) a PC92 in response.

It is guaranteed that no PC9x sentence will ever be routed back to the 
<origin node> and also no sentence will be passed on unless the 
<timestamp> is greater than the last <timestamp>. It is by these two 
means that loops (at least for PC9x sentences) will be stopped. It also 
means that we can have a "plug-an-play" network topology.

An example of a periodic configuration PC92 is:
 
PC92^WR3D^65299^C^5WR3D:5453^5GB7TLH:5453^7K1XX:5452^1YO5CBX^7SM4ONW-14:5451^1G4HRM^5GB7DJK:5453^7K9USA:5452^7KP4JRS:5452^1W2KV^H99^

This indicates that WR3D has 2 PC9x capable nodes and 4 "legacy" nodes 
connected, as well as 3 users. The <timestamp> is the no of seconds 
since midnight. If (as happens with a periodic broadcast) more than one 
sentence is sent then a decimal part is added (for easy > calculations).

For example:
 
PC92^WR3D^65299.01^C^7K1XX:5452^1K1XX-6^1N1KWF^1NR1R^1N8JX^1IZ0FMA^1VE3EP^1W1NRB^1KG1D^1KE5OG^1WC1M^1W4TVG^H99^

showing the connected node K1XX's current configuration.

Hope this helps.

Dirk




More information about the Dxspider-support mailing list