[Dxspider-support] Protocols

[Dirk Koopman]

On Fri, 2004-01-02 at 15:00, Martin Davies G0HDB wrote:
> On 29 Dec 2003 at 12:38, Dirk Koopman wrote:

> As the sysop of a non-Spider DXCluster node (we're still using AK1A, to 	the 
> complete satisfaction of our users) that links to a Spider node (GB7BAA), I 
> would be unhappy to see changes introduced into Spider that would 
> significantly affect its compatibility with non-Spider nodes.

The time has come to decide whether to move on or continue to be limited
by something that is inherently broken. 

Whilst I will endeavour to maintain as much compatibility to
*neighbouring* nodes using AK1A protocol, it may well be that that
compatibility may be reduced over time. We shall just have to see what
drops out. 

But it is likely that only directly connected AK1A nodes will be 'seen'
by the rest of the DXSpider nodes. Nodes that are connected 'downstream'
of an AK1A node (ie further away from the DXSpider node) are likely to
be ignored.

I have had it with the lies and calumnies that the PC routing info tries
to convey about the structure and topology of a network (with or without
'loops'). I will, at least in the first instance, only believe that
which the directly connected AK1A 'compatible' node is telling me about
itself and I will ignore the rest of the routing info.

I will continue to supply that node with (hopefully better and more
reliable) routing information about the DXSpider view of its network (if
it wants it). So you should be able to still see a view much as you do
now.

> 
> The users on GB7DXC make regular use of commands such as 'sh/co 
> <node>' to enable them to see (in real time) whether their friends are logged 
> into the DXCluster.  The talk command, not only to users on the local  node 
> but also to users on remote nodes, is also well used so the introduction of 
> anything that affects or removes these functions will not be well received.
> 

Actually, this is precisely why I am making some of the fundamental
changes that I intend: to allow people to chat/talk to each other
*reliably*. 

As for SH/C, well we have made significant allowances for the fact that
AK1A cannot sensibly handle node lists of upwards of 700 nodes and 3000
users (esp. via radio) so what you see there at GB7DXC is already
severely expurgated. My changes to talk et al will allow your users to
talk to people they can't see!

> If the problem with maintaining the node and user state information arises 
> from multiple connections then why not prevent such situations arising?  
> Why should a user need to be connected to more than one node at the same 
> time?

Because people out there like redundant links. Whether they are nodes or
users. Who are we to deny them?

> 
> As for the suggestion of broadcasting all talk messages, this would seem to 
> be a recipe for potentially seriously overloading any non-Internet routes used 
> for inter-node connections.  Believe it or not, there are still sizeable parts of 
> the UK (and no doubt elsewhere) that have to rely on RF paths because 
> 'always-on' Internet connectivity simply isn't available (either economically or 
> physically).
> 

Let us see how it all pans out. My protocol is necessarily going to be
slightly more verbose, but on some messages it may still be smaller than
current PC sentences.

73 and HNY

Dirk G1TLH