[Dxspider-support] multiple logins + real time user info

[Martin Davies G0HDB]

On 2 Jan 2016 at 20:13, djk wrote:

> [Snipped] 

> I am working (very slowly) on a newer version of DXSpider and I would 
> like to discuss the whole area of user "management". I really do wonder 
> whether - in the modern cluster - with 6000+ concurrent users we 
> continue to require "real time" user connectivity information in its 
> present form.
> 
> Please discuss.

Hello Dirk (and all,) thanks for an interesting and thought-provoking message.  Here's my 
current understanding of and thinking on the topic:

1.  Currently, when a user connects to or disconnects from a node, the details of the 
    connection or disconnection event are disseminated in 'near-real-time' to (all?) the 
    other nodes in the cluster so that every node has, in theory, a reasonably accurate 
    view of which users are connected to which nodes in the entire cluster, although as 
    you've pointed out the view might not always be 100% accurate.  As you've also 
    explained, this automatic forwarding of user connection/disconnection event details 
    results in lots of inter-node PC16/17/92 traffic that can consume a fair amount of 
    bandwidth on the inter-node links.

2.  It seems to me that this 'all-informed' view of the cluster only becomes useful when a 
    user on a node does a 'sh/co' command to enable them to see which users are 
    connected to the other nodes in the cluster - for much, or perhaps even most, of the 
    time the status of users' connections to nodes isn't serving any useful purpose.  I'm 
    not aware of the user status information being used for anything other than 'sh/co'.  
    This leads me on to thinking...

3.  The system currently operates on a 'push' basis so that a user connection or 
    disconnection event on a node is automatically passed using PC16/17/92 messages 
    from the node to its adjacent nodes and thence into the wider cluster.  Why not turn 
    things round so that the status of users' connections to a node is done on a 'pull' 
    basis by a node on which a user has done a sh/co' command?

4.  In this 'on-request' model each node would maintain its own list of user connections 
    and disconnections but wouldn't automatically forward the user state information into 
    the rest of the cluster until requested by an adjacent node, ie. when a user on a 
    distant node has done a 'sh/co'.  This would, I believe, get rid of a lot of the 
    'near-real-time' user-related inter-node traffic but would still enable a user anywhere 
    to get an up-to-date picture of which users are connected to which nodes although 
    there might be a slight delay in retrieving the user information from all the nodes in 
    the cluster.

5.  The suggested 'on-request' model might also result in a more accurate picture of the 
    configuration of the cluster being available to users via the 'sh/co' command because 
    each node would only return its current user status when requested by another node - 
    there shouldn't be any out-of-date informatiion floating around the cluster.

As for compatibility with AK1A, as far as I'm aware my GB7DXC node is the last remaining 
AK1A-based node anywhere and we're probably going to switch it off in the not-too-distant 
future - I've persuaded our fairly small user community to use the DXSpider-based 
GB7DXC-5 node instead and the legacy 'DXC node hasn't had anyone connect to it for ages!  
On this basis I don't think you should worry too much about trying to make any new "user 
management" capability backward-compatible with AK1A.

As for users connecting to multiple nodes, I can't personally see any need for anyone to do 
this but if someone wants to do it then, in the suggested 'on-request' model, I don't see it 
causing a problem.  The presence of a user's callsign on multiple nodes would only be 
reported when someone did a 'sh/co' or a 'sh/sta' command.  I've just done a 'sh/sta gw0ogi' 
command on 'DXC-5 and it has reported that GW0OGI is 'at' GB7MBC, ZL2ARN-10 and 
W1DX - I wonder what benefit he's getting from the connections to those distant nodes...  :-)

All comments welcome...  :-)

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus