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

[Ian Maude]

Hi Dirk et al,
Is there any really good reason any more to be using the PC protocol
at all?  It seems to me that this has been holding back the
development of cluster software for many years.  Early on I could
understand the concerns of those who ran AK1A but now?  Really?
Would it be possible for a user to enter their details in their home
cluster once and if anyone on another node requests it, to poll for
the information?
I am sure plenty of bandwidth could be stripped out by getting rid of
cluster mail for example.  Does anyone use that any more?
Another alternative is to perhaps have ‘server’ nodes that hold the
information and share between themselves.  These nodes would have
plenty of bandwidth.  Nodes connected with a server could request that
information from the server if required.  It would not need to be
stored at the ‘client’ node.
Just a few ramblings from me :)

73 Ian

On 2 January 2016 at 20:13, djk <djk at tobit.co.uk> wrote:
> Traditionally, until say five or six years ago, a user would connect once -
> to one node - and the cluster of nodes would make sure that that user could
> not connect to any other node in the same cluster. This is one of the
> functions that PC16/17 traffic was used for, and was the standard method for
> determining who was on which node. This part of the cluster protocol
> (together with PC19/21 for node connections) had many problems and was the
> major reason that I came up with PC92. This sentence removes, once and for
> all, the major problems caused by "looping" when one tried to obtain some
> resilience in the network by nodes trying to cross connect to different
> "branches" of the "tree" that the original AK1A cluster protocol assumes.
> But it does also introduce some other things (features if you will) whose
> utility could be debatable.
>
> One of the side "benefits" that was discussed at the time that PC92 was
> introduced, was that users could now also connect to more than one node at a
> time. I could (and still can) see some merit in this - in some limited
> circumstances - for users in difficult networking situations. But that was
> long time ago and internet connectivity has improved well beyond the point
> where this facility is, I believe, useful - or indeed - desirable.
> Especially as there (now) seem to be several users who connect to many nodes
> as a matter of course. This may even be a function/feature of some client
> software that they use (I don't know, not my department).
>
> I have had a number of private complaints about the amount of bandwidth that
> running a node (especially a well connected and popular one) takes. Having
> "a lot" of users connecting to more than one node simultaneously creates a
> lot of  additional administrative traffic, which is there to allow every
> node to retain a reasonably accurate view of the cluster to, amongst other
> things, control the number of connections that a user has. But even with all
> this traffic, the "view" that any node has is likely to be neither complete
> nor accurate. This is simply because it takes time for an update to traverse
> the network and situations could change during this process. On a node such
> as GB7DJK with good, stable links, it will be pretty close - be still
> probably not accurate. But for all that networks have improved - there still
> seem to be nodes scattered about that can't seem to stay connected stably.
>
> 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.
>
> Happy New Year
>
> Dirk G1TLH
>
> PS: On a DXSpider node the default maximum concurrent connections that a
> user can have to a cluster is three. A sysop can enforce any limit they like
> on their own node and I know that some sysops set this limit to one.
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support