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

Wed Mar 5 16:15:59 GMT 2025

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