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

Wed Mar 5 16:31:56 GMT 2025

This ping pong messaging between the two reflectors is quite ridiculous.
Why the 2 developers doesn't take a seat at the same table and try to
figure out a possible solution?
Separating the 2 networks by building walls is a little bit anachronistic
and not a win-win solution for sure.

73

Andrea
iz2lsc
-->

On Wed, Mar 5, 2025 at 5:16 PM Mikel EA2CW via Dxspider-support <
dxspider-support at tobit.co.uk> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250305/fb4766e6/attachment-0001.htm>