<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 19/02/2025 14:43, g4piq--- via
Dxspider-support wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07dd01db82dc$9debbd90$d9c338b0$@btinternet.com">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.</blockquote>
<br>
<font size="4">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. <br>
<br>
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?<br>
<br>
So, what is going to happen?<br>
<br>
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.<br>
<br>
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. <br>
<br>
Since this is probably wishful thinking, I propose to carry on
adding more protections and, in the meantime: let's just ignore
it.<br>
<br>
73 Dirk G1TLH<br>
</font>
</body>
</html>