[Dxspider-support] $DXProt::senderverify = '2'

[Dirk Koopman]

On 19/02/2025 14:43, g4piq--- via Dxspider-support wrote:
> The flooding at the weekend clearly caused some nodes real problems. 
>  But I think that's a different behaviour to spots being sourced from 
> nodes that for we haven't got up to date user lists for (many reasons 
> for that in this complex heterogeneous network). The flooding at the 
> weekend feels like it could be prevented with a different mechanism - 
> for example an incoming rate limit on spots with the same call or from 
> the same IP.

The problem is not the backbone traffic. As Kin (I think) observed this 
last weekend, even on his fairly large node(s), and running on 
Linux(like) operating systems, spots only take 20-40mS to distribute 
(after filtering) to all interested connections. Other software seem to 
take significantly longer. I have seen figures of 4 or 5 minute delay 
this last week. I have also had reports that running a large node on 
Windows is significantly slower (hint hint). As well as hosting services 
that use network attached storage and not real disks. When WA9PIE-2 
(usually 700+ daily users -> 1200 on contest weekends) swapped from 
Google services to a DO droplet, it too went from 2 or 3 minute lags to 
a few mS to process and distribute protocol sentences.

I believe that a many of these rogue spots, that seem to be valid, are 
sent by software that "snipes". This means that authenticating them is 
always going to be rather patchy. By default, DXSpider strongly 
discourages this practice and will not pass on spots (or whatever) from 
callsigns/software that does this. It would be nice if we could identify 
all the user software that implements this and try to persuade the 
authors not to allow it. I struggle to understand what "sniping" gives 
the user. Is this some attempt at misdirection? Why? What advantage is 
there?

So, what is going to happen?

There will be rate limiting, temporary and/or permanent black holing of 
repeat offenders. Having looked at the patterns of offending traffic, I 
can see one or two other little heuristical wrinkles I can add. I will 
continue to do this. There are also some protocol enhancements that I am 
toying with that may help.

But the real solution is to unmask offenders and persuade them to stop 
doing this. The alleged perpetrators appear to be known and apparently 
come from Italy.  I therefore ask our Italian sysops whether they can 
bring some more official pressure to bear, perhaps through their 
licencing authority. Not that this is a permanent solution, you don't 
actually have to have a licence to use the cluster or the software than 
runs or connects to it. But it might give someone pause before doing it 
again.

Since this is probably wishful thinking, I propose to carry on adding 
more protections and, in the meantime: let's just ignore it.

73 Dirk G1TLH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250219/85877093/attachment.htm>