[Dxspider-support] Protocols

[scarroll at mchsi.com]

I'm all for enhancing the protocol capabilities of DX Spider. My only concern 
is that in the current configuration, my DX Spider node needs to 'see' (SH/C) a 
specific user 2 or 3 nodes away in order to even attempt delivery of private 
mail. Would this be addressed?

FYI, I don't believe the inabilities of AK1A software should limit advancing DX 
Spider. Reverse-compatability isn't always feasible, especially when changing 
protocols. If there's a more efficient way of doing things, let's do it. 
Besides, that would pretty much force the other clusters in my local RF network 
to upgrade. Most have been running (it seems with no SysOp supervision) for 
years with the most outdated AK1A versions anyway.

I really appreciate all the hardwork & countless hours spent upgrading & 
testing this excellent software package.

73, Steve - K2SC

> 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
> 
> 
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://www.tobit.co.uk/mailman/listinfo/dxspider-support