<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">We seem to be starting to lose the
"battle" between nodes <-> users on client programs issuing
data (for whatever reason).<br>
<br>
The piece of code shown below was introduced in March 2023,
together with the following comment underneath:<br>
<font face="monospace"><br>
These default values are set generously deliberately to allow
certain user<br>
programs to get with the program and reduce the number of
cmds that they<br>
issue on connection down to something reasonable. For
instance, I cannot<br>
see why things like name, qth, lat/long/QRA (amongst several
other sticky<br>
user attributes that only need to be entered once) are sent
on every login.<br>
<br>
</font>It is clear to me that the situation has got worse and the
time to tighten the defaults has arrived. In addition, I will add
a general re-login delay so that programs cannot instantly
reconnect and just carry on. Maybe with a second/other safeguard
of recording the IP address rather than the callsign with an
backoff timer after Z number of "fast" attempts to re-login. Or
something like that (maybe a timed local IP address ban?).<br>
<br>
I will happily accept suggestions for "better" values for X = 16
and Y = 9 below. As well as other ways of discouraging this sort
of behaviour. <br>
<br>
I fail to understand the point of spotting an entire FTx channel's
decoded callsigns. You haven't worked them, your program just
heard them, but you're probably drinking tea and working someone
else OR you've simply left the computer on whilst going out for
the day. This, incidentally, is why I won't, ever, gate out raw
skimmer spots to users. Speaking of which: the FTx skimmer network
will likely do a better job than your random user "skimmer" so why
not just connect to that instead!<br>
<br>
This person appears to have taken it upon himself (gender
deliberately chosen) to become an FTx skimmer that gates his data
out into the general spot pool. But he could not do this unless
the CLIENT SOFTWARE he is using provides that facility. So the
obvious solution to this is to try to identify the author(s) of
the client software and persuade them to not allow this sort of
thing to occur. Experience shows that authors are reluctant to
change the behaviour of their creations (I can understand that)
and simply ignore requests for changes from "outside" their user
communities. It probably takes at least 15 years of full time
professional programming before one truly believes that all
software has bugs, or undesirable behaviours that have been
discovered by users that require changes. Unfortunately many
authors are hobby programmers and resistant to external pressure
for change. Probably, because their software is written in a way
that makes it too difficult to change. I remember that :-)<br>
<br>
As I have been writing this, I am starting to get a bit annoyed by
the thoughtlessness of some authors and users. So I will implement
an linearly increasing IP address ban time, together with message
on login (with a fixed delay of say 10 secs before forced
disconnect) saying something like "You are sending too many
commands too quickly, you are banned from reconnecting until
<date/time>". Obviously if they reconnect and do it again
(within some interval) they will be have more time added - and -
"good behaviour" over a period of time will reduce their penalty
ban time. <br>
<br>
Your thoughts and suggestions for default values for these times /
intervals will be gratefully received.<br>
<br>
73 Dirk G1TLH<br>
<br>
On 21/01/2025 21:31, IZ2LSC via Dxspider-support wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJowXJDnX+pSPpb72vyfu5kATE+ttednjO_RO=1C8p-ktjDitg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>I know there is the following knob, but if the originating
node is not up to date (or is not a spider), then the flood is
sent into the network.</div>
<div><br>
</div>
<div> Added cmd entry rate limiting. If a user sends X
commmands in Y secs then<br>
they are disconnected without notice. The defaults are X<br>
($<a class="moz-txt-link-freetext" href="DXCommandmode::maxcmdcount">DXCommandmode::maxcmdcount</a>) = 16 and Y
($<a class="moz-txt-link-freetext" href="DXCommandmode::cmdinterval">DXCommandmode::cmdinterval</a>) = 9.</div>
<div><br>
</div>
<div><br>
</div>
<div>Andrea, IZ2LSC</div>
<div><br>
</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 Tue, Jan 21, 2025 at
10:07 PM <<a href="mailto:ea3cv@cronux.net"
moz-do-not-send="true" class="moz-txt-link-freetext">ea3cv@cronux.net</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">
<div>
<div dir="auto">The only thing I can think of is to treat
spotter+time as a duplicate variant within a 1s window.
<div dir="auto">I don't know if Dirk has something
implemented.</div>
</div>
<div dir="auto">I'll look tomorrow, I'm curious.<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Kin</div>
<div dir="auto"><br>
</div>
<div id="m_-492333046762524246ms-outlook-mobile-signature"
dir="auto">
<div><br>
</div>
Enviado desde <a href="https://aka.ms/AAb9ysg"
target="_blank" moz-do-not-send="true">Outlook para
Android</a></div>
<div dir="auto"
id="m_-492333046762524246mail-editor-reference-message-container"><br>
<hr style="display:inline-block;width:98%">
<div id="m_-492333046762524246divRplyFwdMsg"
style="font-size:11pt"><strong>De:</strong>
Dxspider-support <<a
href="mailto:dxspider-support-bounces@tobit.co.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dxspider-support-bounces@tobit.co.uk</a>>
en nombre de IZ2LSC via Dxspider-support <<a
href="mailto:dxspider-support@tobit.co.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>><br>
<strong>Enviado:</strong> martes, enero 21, 2025 9:30:48
p. m.<br>
<strong>Para:</strong> The DXSpider Support list <<a
href="mailto:dxspider-support@tobit.co.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dxspider-support@tobit.co.uk</a>><br>
<strong>CC:</strong> IZ2LSC <<a
href="mailto:iz2lsc.andrea@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">iz2lsc.andrea@gmail.com</a>><br>
<strong>Asunto:</strong> [Dxspider-support] Fwd: Max
Spot per Minute (how to avoid flooding)<br>
</div>
<br>
<div dir="ltr">
<div>Hi sysops! <br>
</div>
<div class="gmail_quote">
<div dir="ltr">
<div>I was reviewing my cluster stats when I noticed
this spike in spot per minute (see attached
image).<br>
</div>
<div><br>
</div>
<div><img
src="cid:part1.5CMMg46V.r8PSa0ET@tobit.co.uk"
alt="immagine.png" width="558" height="244"
id="m_-492333046762524246ii_m66x689e0"
style="max-width: 100%;" class=""><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Looking at the logs I can see a flood of 55
spots coming in the same second from the same
user, an extract below:</div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace">7074.4^DH2YBG^1737474360^FT8^KC9LFD^32^226^DB0ERF-5^28^14^8^4^^^204.93.149.214<br>
7074.4^GM6URC^1737474360^FT8^KC9LFD^65^226^DB0ERF-5^27^14^8^4^^^204.93.149.214<br>
7074.4^N5TLH^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^7^4^8^4^^^204.93.149.214<br>
7074.4^LA8ENA^1737474360^FT8^KC9LFD^123^226^DB0ERF-5^18^14^8^4^^^204.93.149.214<br>
7074.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214<br>
7074.4^F5SJF^1737474360^FT8^KC9LFD^42^226^DB0ERF-5^27^14^8^4^^^204.93.149.214<br>
7074.4^VK2WN^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214<br>
7074.4^N1UL^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214<br>
7074.4^KA9SOG^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214<br>
7074.4^VK3YW^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214<br>
7074.4^N9IBM^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214<br>
7074.4^W5ORC^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214<br>
7074.4^KP2BH^1737474360^FT8^KC9LFD^119^226^DB0ERF-5^11^8^8^4^^^204.93.149.214<br>
3573.4^K8CW^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214<br>
3573.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214<br>
3573.4^K1TAP^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214</span></div>
<div><br>
</div>
<div><br>
</div>
<div>Is there a way to activate a sort of flooding
protection?</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks and 73</div>
<div><br>
</div>
<div><br>
</div>
<div>Andrea, IZ2LSC<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
</body>
</html>