[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