[Dxspider-support] You are killing all Webclusters!
Erwin Fiten
erwin.fiten at gmail.com
Fri Mar 7 13:11:20 GMT 2025
Hi Devil's lawyer ;)
Partly you are correct. for sure.
1. Load, I'm not sure it will be that much. In my case, I have a 1 core VM
with 2Gb of memory, and even during a contest, the load doesn't get above
10%, and this is a low end machine. I must say, with only 20-30 users and 8
connected clusters.
2. The balacklisting is already there, going the same checks for each spot
(I think), it would just need an extra test.
The extra code and update of DXspider: The ones that have active sysops
will update; those are the same ones that do it now. The others have old
code, some of which is too old to run a decent cluster, but we can't change
that. We can only hope that more clusters will update.
So there isn't a good or a bad solution. The only one we can solve
ourselves, without the goodwill of others, is DXspider (so in the end it's
Dirk), to make this as good as possible, with less false positives.
This whitelist can even be a variable, so low-end clusters can disable it,
if the system slows down too much. I'm still in favor of this.
Erwin
Op vr 7 mrt 2025 om 12:32 schreef Mikel EA2CW via Dxspider-support <
dxspider-support at tobit.co.uk>:
> Hello "listers",
>
> After reading these last interesting posts sent to the list this
> morning, I would want to play the "devil's defense attorney" role
> (spanish expression), mainly about the mentioned "whitelist" proposal.
>
> Every time a post arrives to a node, it must be checked against several
> conditions -even before starting the answer to each of the connected
> users, based on their own filters.
>
> This is node time consuming, even before giving permission to EVERY SPOT
> to pass. And we should add another condition checker more.
>
> To have this "whitelist" protocol running, Dirk will have to write the
> code, and then the about 400 existing nodes running dxspider install the
> new version.
>
> First problem. Kin, f.i. has been trying for years to give us
> information about nodes running obsolete versions, trying to compell the
> sysops to update with few success. Why would we think that now will be
> better?
>
> Or from another point of view, to solve the problem presented by no more
> than ten nodes (webclusters), which do not follow the comms protocol,
> protocol which has been already written and running, will we have to
> rewrite the code and modify almost 400 nodes? Doesn't seem very logical,
> does it?
>
> So, to resume all it:
>
> 1. About Time: The "user connected to node" protocol should be be
> executed ONCE per node (remember, no more than 10) per user. Then all
> the spots from him/her can be sent.
> The "whitelist" should be run at EACH spot arrival at EVERY receiving
> node (around 400).
>
> 2. About work to do: The "user connected to node" is already written and
> every node -except the webcluster nodes- follows it. The "whitelist"
> should be written and installed.
>
> Even more, as far as I know, almost all these webclusters are running
> DXSPIDER!!! -sometimes not the last version. What should be, so, the
> problem to make the same things that we all the rest are doing?
>
> By the way, seems evident from the numbers that the amount of connected
> users is not related to the number of spots sent. That's logic, in the
> middle of a contest, I will not stop operating to access a web page to
> send a spot if my soft can do it times faster.
>
> 73 de Mikel, playing Devil's lawyer
>
> From Bilbao, Basque Country
>
> cluster.gautxori.com 7300 cc-cluster
> cluster.gautxori.com 7373 dxspider
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250307/55ddfb8a/attachment.htm>
More information about the Dxspider-support
mailing list