[Dxspider-support] Thoughts on concerns regarding CC and DXSpider cluster nodes

Wed Mar 5 17:29:48 GMT 2025

Thanks Mikel.

Kin

-----Mensaje original-----
De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Mikel EA2CW via Dxspider-support
Enviado el: miércoles, 5 de marzo de 2025 17:16
Para: Kin via Dxspider-support <dxspider-support at tobit.co.uk>
CC: Mikel EA2CW <ea2cw at gautxori.com>
Asunto: Re: [Dxspider-support] Thoughts on concerns regarding CC and DXSpider cluster nodes

Sorry Kin, but on the web version, I cannot distiguish between the cited texts and your annotations, so with your permission, I will try to rewrite it.
Any differences, my fault.
Note: The annexed files are on Kin's post.

========================================================================
Hi all,

I've received a series of messages that have left me speechless.

 >>> "I believe that disconnecting non CC Cluster nodes will help prevent further flooding of bogus spots, especially during major contests. These bogus spots do not originate on CC Clusters."

I suppose the statement could be true, but it's hard to know because CC Cluster is a black box.

 >>> "Many CC Cluster sysops probably are wondering what I am talking about since they don't see any flood of bogus spots. "

Someone might say that this statement is far from the truth, but it won’t be me.
There are those who claim that not only were there countless false spots on the CC Cluster nodes, but they were also being relayed across the entire network by the CCCs themselves. And, unable to handle that volume of traffic, they began experiencing delays of over 4 minutes.
I find it hard to believe—though I’ve seen the logs.
I manage several DXSpider nodes, and I can confirm that they never went down. In fact, one of them withstood peak loads with maximum delays of just 0.5 seconds.
I suppose it must have been the same for the others, right?

 >>> "Any CC Cluster that does not get spots from a non CC Cluster is probably ok."

Due to the network protocol and the network flooding mechanism, this claim is quite difficult to defend, but what do I know?

 >>> "You do not need more than 3 or 4 connections to other nodes. The only reason you need this many is that occasionally you may lose a connection or two."

This is what I can say. I totally agree.

 >>> "My own cluster runs on a very fast computer. It can see the bogus spots and drops them."

It seems that in this latest attack, that protection mechanism has been shown to be ineffective—or at least not in a high percentage of cases. 
The data is there, or so I’m told.

 >>> "If you have a slow computer you may drop the bad spots but get way behind in processing good ones. During a 6 hour period of the ARRL contest my computer rebooted and in the next 6 hours it dropped almost one million spots because the spot time was more than 4 minutes slow. 
This time delay was not here, it was in the nodes I was connected with. 
Since the contest ended and the bogus spots stopped, my computer has seen zero spots that were more than 4 minutes old. Not a single one."

It's hard to believe that the evidence suggests the impact came from the traffic received through each of the links (too many, some say), but the software didn’t seem to be able to handle that volume, even though the host had high-performance hardware. I don't know—it’s tough if true.

 >>> "The CC Cluster software does not clutter up the backbone data by including a list of all connected users and their IP addresses. There is enough garbage already on the backbone.  None of the CC Clusters send out this data.  However, DX Spider node software wants to immediately see every user connect and disconnect.  Their software keeps track of this data."

Can it really be said that sending connection/disconnection information of users/nodes to the network could saturate the network? Some seem to think so. I think it must be a joke: no one could seriously say that, because it is very easy to calculate such traffic, and it is negligible, they say.

Of course, if this were true, one would suspect that not all node software is capable of handling this information without being affected. 
As far as I know, this is not a problem in DXSpider. It would be interesting to see what the difference is, just out of curiosity.

I wonder why Dirk would want to include IP addresses in the control packets between nodes. Could it be the same as with the badip lists that have helped stop a lot of spam?

 >>> "And why is this important to know?  If you go to the DX Spider Support page you will see lots of posts about the VE7CC-1 node and that many of the sysops are proudly stating that all spots from VE7CC-1 node are dropped and not passed on.  This is being done because my node and all other CC Cluster nodes do not notify DX Spider nodes of users connected and their IP addresses."

I have not read that any sysop boasts of having removed a CC cluster. 
What is publicly known is that some sysops have decided their own security policy for their node and extend it to their partners, no more and no less.

Seems quite reasonable, doesn't it?

 >>> "Although not stated it appears to me that ALL spots originating on ALL CC Clusters are therefore being dropped by some of the DX Spider nodes."

They tell me that this is not true, that Lee should have known before making these claims that this could lead to a conflict. I told them that this should not be true, that it would be too far-fetched.

However, they also told me that VE7CC-1 has features enabled that almost no other CC Cluster had enabled: PC92C, which shows the connected users; PC92A and D; and even PC92K, so that everyone can see the number of users and nodes connected. But for sysops not to have these same features on their node is not possible, because it would have minimized the rejection of spots from those nodes in the CC Cluster.

As I said, it is impossible for this to be true.

 >>> "Looking at the nodes of origin of DX spots during major contests you will see that the majority of spots originate on CC Clusters.  If these spots are all being dropped then users of some of the DX Spider and AR Cluster nodes will not see the majority of the DX spots."

Since none of this seemed to make sense, I thought I might try to turn to the data, data that is available on any node in the network.

If we count the total number of spots from 1 January 2025 until now, we get the following values:

Total spots generated on the network:                 862,245

Total spots generated in the DXSpider nodes:          489,837

Remaining spots not generated by DXSpider:            372,408

If we assume that everything not generated by a DXSpider node was generated by the CC Clusters, these would account for only 43% of the total. However, the actual amount is probably lower due to the presence of other types such as AR Cluster, CLX, DXNet and AK1A.

Thus, more than half of the spots generated in the network seem to come from a DXSpider node.

But as we have suffered several attacks, I considered these figures invalid and analysed the whole year 2024:

Total spots generated in the network:                 3,772,177 
100.00%

Total spots generated in the DXSpider nodes:          2,155,322 
57.14%

Remaining spots not generated by DXSpider:            1,616,855 
42.86%

The total number of nodes in the network (identified) that sent >= 1 spot, was approx. 439 out of 540. See file 002.txt

The number of DXSpider nodes that sent at least 1 spot, was approx. 292 out of 393. See file 001.txt

It seems that I have not made a mistake with the 2025 values.

Although the provided values are for long periods and not exclusively for competitions, anyone could do the calculations, but is it really necessary?

And in case you want to go to the source:

https://groups.io/g/CC-Cluster/message/2152

https://groups.io/g/CC-Cluster/topic/111514058#msg2149

Let's work together, it will make us stronger.

73 de Kin EA3CV

PS.:
Please excuse me if what I’ve written isn’t clear.

By the way, if any sysop would prefer that we stop sharing links, please let me know by email before kicking me out without warning. I still have some civility left in me, I won’t get angry.

======================================================================
(End of cited text)

--
73 de Mikel Berrocal EA2CW-AE2CW
Bilbao, Basque Country
ea2cw at gautxori.com
https://www.ea2cw.eus

_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support