<div dir="ltr"><div>This ping pong messaging between the two reflectors is quite ridiculous.<br>Why the 2 developers doesn't take a seat at the same table and try to figure out a possible solution?<br>Separating the 2 networks by building walls is a little bit anachronistic and not a win-win solution for sure.<br><br>73<br><br>Andrea<br>iz2lsc</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 5, 2025 at 5:16 PM Mikel EA2CW via Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk">dxspider-support@tobit.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry Kin, but on the web version, I cannot distiguish between the cited <br>
texts and your annotations, so with your permission, I will try to <br>
rewrite it.<br>
Any differences, my fault.<br>
Note: The annexed files are on Kin's post.<br>
<br>
========================================================================<br>
Hi all,<br>
<br>
I've received a series of messages that have left me speechless.<br>
<br>
>>> "I believe that disconnecting non CC Cluster nodes will help <br>
prevent further flooding of bogus spots, especially during major <br>
contests. These bogus spots do not originate on CC Clusters."<br>
<br>
I suppose the statement could be true, but it's hard to know because CC <br>
Cluster is a black box.<br>
<br>
>>> "Many CC Cluster sysops probably are wondering what I am talking <br>
about since they don't see any flood of bogus spots. "<br>
<br>
Someone might say that this statement is far from the truth, but it <br>
won’t be me.<br>
There are those who claim that not only were there countless false spots <br>
on the CC Cluster nodes, but they were also being relayed across the <br>
entire network by the CCCs themselves. And, unable to handle that volume <br>
of traffic, they began experiencing delays of over 4 minutes.<br>
I find it hard to believe—though I’ve seen the logs.<br>
I manage several DXSpider nodes, and I can confirm that they never went <br>
down. In fact, one of them withstood peak loads with maximum delays of <br>
just 0.5 seconds.<br>
I suppose it must have been the same for the others, right?<br>
<br>
>>> "Any CC Cluster that does not get spots from a non CC Cluster is <br>
probably ok."<br>
<br>
Due to the network protocol and the network flooding mechanism, this <br>
claim is quite difficult to defend, but what do I know?<br>
<br>
>>> "You do not need more than 3 or 4 connections to other nodes. The <br>
only reason you need this many is that occasionally you may lose a <br>
connection or two."<br>
<br>
This is what I can say. I totally agree.<br>
<br>
>>> "My own cluster runs on a very fast computer. It can see the bogus <br>
spots and drops them."<br>
<br>
It seems that in this latest attack, that protection mechanism has been <br>
shown to be ineffective—or at least not in a high percentage of cases. <br>
The data is there, or so I’m told.<br>
<br>
>>> "If you have a slow computer you may drop the bad spots but get way <br>
behind in processing good ones. During a 6 hour period of the ARRL <br>
contest my computer rebooted and in the next 6 hours it dropped almost <br>
one million spots because the spot time was more than 4 minutes slow. <br>
This time delay was not here, it was in the nodes I was connected with. <br>
Since the contest ended and the bogus spots stopped, my computer has <br>
seen zero spots that were more than 4 minutes old. Not a single one."<br>
<br>
It's hard to believe that the evidence suggests the impact came from the <br>
traffic received through each of the links (too many, some say), but the <br>
software didn’t seem to be able to handle that volume, even though the <br>
host had high-performance hardware. I don't know—it’s tough if true.<br>
<br>
>>> "The CC Cluster software does not clutter up the backbone data by <br>
including a list of all connected users and their IP addresses. There is <br>
enough garbage already on the backbone. None of the CC Clusters send <br>
out this data. However, DX Spider node software wants to immediately <br>
see every user connect and disconnect. Their software keeps track of <br>
this data."<br>
<br>
Can it really be said that sending connection/disconnection information <br>
of users/nodes to the network could saturate the network? Some seem to <br>
think so. I think it must be a joke: no one could seriously say that, <br>
because it is very easy to calculate such traffic, and it is negligible, <br>
they say.<br>
<br>
Of course, if this were true, one would suspect that not all node <br>
software is capable of handling this information without being affected. <br>
As far as I know, this is not a problem in DXSpider. It would be <br>
interesting to see what the difference is, just out of curiosity.<br>
<br>
I wonder why Dirk would want to include IP addresses in the control <br>
packets between nodes. Could it be the same as with the badip lists that <br>
have helped stop a lot of spam?<br>
<br>
>>> "And why is this important to know? If you go to the DX Spider <br>
Support page you will see lots of posts about the VE7CC-1 node and that <br>
many of the sysops are proudly stating that all spots from VE7CC-1 node <br>
are dropped and not passed on. This is being done because my node and <br>
all other CC Cluster nodes do not notify DX Spider nodes of users <br>
connected and their IP addresses."<br>
<br>
I have not read that any sysop boasts of having removed a CC cluster. <br>
What is publicly known is that some sysops have decided their own <br>
security policy for their node and extend it to their partners, no more <br>
and no less.<br>
<br>
Seems quite reasonable, doesn't it?<br>
<br>
>>> "Although not stated it appears to me that ALL spots originating on <br>
ALL CC Clusters are therefore being dropped by some of the DX Spider nodes."<br>
<br>
They tell me that this is not true, that Lee should have known before <br>
making these claims that this could lead to a conflict. I told them that <br>
this should not be true, that it would be too far-fetched.<br>
<br>
However, they also told me that VE7CC-1 has features enabled that almost <br>
no other CC Cluster had enabled: PC92C, which shows the connected users; <br>
PC92A and D; and even PC92K, so that everyone can see the number of <br>
users and nodes connected. But for sysops not to have these same <br>
features on their node is not possible, because it would have minimized <br>
the rejection of spots from those nodes in the CC Cluster.<br>
<br>
As I said, it is impossible for this to be true.<br>
<br>
>>> "Looking at the nodes of origin of DX spots during major contests <br>
you will see that the majority of spots originate on CC Clusters. If <br>
these spots are all being dropped then users of some of the DX Spider <br>
and AR Cluster nodes will not see the majority of the DX spots."<br>
<br>
Since none of this seemed to make sense, I thought I might try to turn <br>
to the data, data that is available on any node in the network.<br>
<br>
If we count the total number of spots from 1 January 2025 until now, we <br>
get the following values:<br>
<br>
Total spots generated on the network: 862,245<br>
<br>
Total spots generated in the DXSpider nodes: 489,837<br>
<br>
Remaining spots not generated by DXSpider: 372,408<br>
<br>
If we assume that everything not generated by a DXSpider node was <br>
generated by the CC Clusters, these would account for only 43% of the <br>
total. However, the actual amount is probably lower due to the presence <br>
of other types such as AR Cluster, CLX, DXNet and AK1A.<br>
<br>
Thus, more than half of the spots generated in the network seem to come <br>
from a DXSpider node.<br>
<br>
But as we have suffered several attacks, I considered these figures <br>
invalid and analysed the whole year 2024:<br>
<br>
Total spots generated in the network: 3,772,177 <br>
100.00%<br>
<br>
Total spots generated in the DXSpider nodes: 2,155,322 <br>
57.14%<br>
<br>
Remaining spots not generated by DXSpider: 1,616,855 <br>
42.86%<br>
<br>
The total number of nodes in the network (identified) that sent >= 1 <br>
spot, was approx. 439 out of 540. See file 002.txt<br>
<br>
The number of DXSpider nodes that sent at least 1 spot, was approx. 292 <br>
out of 393. See file 001.txt<br>
<br>
It seems that I have not made a mistake with the 2025 values.<br>
<br>
Although the provided values are for long periods and not exclusively <br>
for competitions, anyone could do the calculations, but is it really <br>
necessary?<br>
<br>
And in case you want to go to the source:<br>
<br>
<a href="https://groups.io/g/CC-Cluster/message/2152" rel="noreferrer" target="_blank">https://groups.io/g/CC-Cluster/message/2152</a><br>
<br>
<a href="https://groups.io/g/CC-Cluster/topic/111514058#msg2149" rel="noreferrer" target="_blank">https://groups.io/g/CC-Cluster/topic/111514058#msg2149</a><br>
<br>
<br>
Let's work together, it will make us stronger.<br>
<br>
73 de Kin EA3CV<br>
<br>
PS.:<br>
Please excuse me if what I’ve written isn’t clear.<br>
<br>
By the way, if any sysop would prefer that we stop sharing links, please <br>
let me know by email before kicking me out without warning. I still have <br>
some civility left in me, I won’t get angry.<br>
<br>
======================================================================<br>
(End of cited text)<br>
<br>
-- <br>
73 de Mikel Berrocal EA2CW-AE2CW<br>
Bilbao, Basque Country<br>
<a href="mailto:ea2cw@gautxori.com" target="_blank">ea2cw@gautxori.com</a><br>
<a href="https://www.ea2cw.eus" rel="noreferrer" target="_blank">https://www.ea2cw.eus</a><br>
<br>
<br>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote></div>