[Dxspider-support] Protocols

[Martin Davies G0HDB]

On 2 Jan 2004 at 16:17, Dirk Koopman wrote:

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

I'm intrigued to know what you think is inherently broken in the existing 
system.

> 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.

We'll be OK then, as long as GB7DXC continues to connect to GB7BAA.  
There are currently no 'downstream' nodes connected to 'DXC - GB7WDX 
now has its own connections into the network.

> 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.

That's fine with me.

> > 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*. 

I don't recall there being any significant reliability problems with the talk 
function in AK1A.

> 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!

I'm sure that'll be very useful :-)  Seriously though, I don't envisage there 
being a problem with 'DXC seeing what you call an 'expurgated' list of nodes.  
I'm confident that as long as our users can see which UK nodes are in the 
Cluster, and which users are logged in to each of them, then they'll be 
happy.  I'm not aware of anyone locally needing to send talks outside the UK 
very often (if at all).

> > 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?

Hmmm, connections to multiple nodes still seem pretty pointless to me - it's 
not as though users'/nodes' access to the Cluster needs to be ultra-high 
availability.  Just out of interest, how many users/nodes actually connect to 
multiple nodes?

I would have thought that if a user (or another node) is connected into a 
single node and that node gives up the ghost then it would take the user (or 
the node) but a few secs to disconnect and connect to an alternative node, 
especially if the connections are made over the Internet using telnet.  Just 
because multiple connections are technically possible doesn't necessarily 
make it sensible to permit them to be made especially if they cause 
problems with the maintenance of state tables. KISS!!!

> > 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.

As you say, let's see how it all pans out.

73,
--
Martin, G0HDB
Sysop GB7DXC