[Dxspider-support] Fwd: Max Spot per Minute (how to avoid flooding)
Dirk Koopman
djk at tobit.co.uk
Sun Jan 26 11:58:58 GMT 2025
Keith
Thank you for organising this.
73 Dirk G1TLH
On 25/01/2025 22:19, Keith, G6NHU via Dxspider-support wrote:
> HamClock V4.13 has been modified as per my comments below, I’m running
> a beta build now and can confirm it’s working as I described.
>
> It will send qra or location under two situations:
>
> 1) If the node asks for them
> 2) If the user changes them within the setup
>
> It has slots for up to 12 DXCluster commands so if the user has all
> these filled, the most commands it will ever send on login is 14 at
> approximately half second intervals and then it won’t send any more
> commands at all while it’s connected.
>
> And that’s it. With these little new tweaks and with the changes
> that were made to HamClock to be less ‘chatty’ over a year ago, I hope
> nobody can object to it any more.
>
> 73 Keith.
> On 24 Jan 2025 at 20:02 +0000, Keith, G6NHU via Dxspider-support
> <dxspider-support at tobit.co.uk>, wrote:
>> Because client software is mentioned here, I thought I’d jump in. As
>> is known, I work closely with the HamClock developer and following
>> this email, we’ve discussed what it sends to the node.
>>
>> At the moment, he sends /set/qra/ and /set/location/ each time
>> HamClock connects to the cluster. He’s going to change that so
>> they’re only sent if they’re requested. So if a new user sets up a
>> HamClock, the first time it connects to a DXSpider, it’ll send
>> /set/qra/ and /set/location/ and on all subsequent connections, it
>> won’t send them.
>>
>> The ten minute inactivity ping timer he sends will be removed as well
>> as that’s not needed.
>>
>> This means that the only commands a HamClock will regularly send to
>> the node are the filter commands that the user sets up. They’ll be
>> sent each time a connection is made and with a forced delay between
>> them to avoid hitting any flood timer. The reason they’re sent every
>> time is because a user may change them and they always need to be up
>> to date.
>>
>> I can’t comment on any other client software but the HamClock
>> developer is very happy to work with us and put as little load on the
>> system as possible. I don’t really see how he can reduce it any
>> further.
>>
>> Rudy - You’re quite right, individual nodes may need different
>> settings and that’s why there are two variables you can set which
>> will overwrite the X = 16 and Y = 9 values that are the new proposed
>> defaults. If you need something different then you can adjust your
>> node accordingly by setting /$DXCommandmode::maxcmdcount/ and
>> /$DXCommandmode::cmdinterval/ (X and Y respectively) in
>> //spider/scripts/startup/. This is already documented in
>> //spider/Changes/, see the entries for 24Mar23 and 25Mar23.
>>
>> 73 Keith.
>>
>> On 24 Jan 2025 at 13:38 +0000, Dirk Koopman via Dxspider-support
>> <dxspider-support at tobit.co.uk>, wrote:
>>> We seem to be starting to lose the "battle" between nodes <-> users
>>> on client programs issuing data (for whatever reason).
>>>
>>> The piece of code shown below was introduced in March 2023, together
>>> with the following comment underneath:
>>>
>>> These default values are set generously deliberately to allow
>>> certain user
>>> programs to get with the program and reduce the number of cmds
>>> that they
>>> issue on connection down to something reasonable. For instance, I
>>> cannot
>>> see why things like name, qth, lat/long/QRA (amongst several
>>> other sticky
>>> user attributes that only need to be entered once) are sent on
>>> every login.
>>>
>>> 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?).
>>>
>>> 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.
>>>
>>> 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!
>>>
>>> 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 :-)
>>>
>>> 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.
>>>
>>> Your thoughts and suggestions for default values for these times /
>>> intervals will be gratefully received.
>>>
>>> 73 Dirk G1TLH
>>>
>>> On 21/01/2025 21:31, IZ2LSC via Dxspider-support wrote:
>>>> 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.
>>>>
>>>> Added cmd entry rate limiting. If a user sends X commmands in Y
>>>> secs then
>>>> they are disconnected without notice. The defaults are X
>>>> ($DXCommandmode::maxcmdcount) = 16 and Y
>>>> ($DXCommandmode::cmdinterval) = 9.
>>>>
>>>>
>>>> Andrea, IZ2LSC
>>>>
>>>> -->
>>>>
>>>>
>>>> On Tue, Jan 21, 2025 at 10:07 PM <ea3cv at cronux.net> wrote:
>>>>
>>>> The only thing I can think of is to treat spotter+time as a
>>>> duplicate variant within a 1s window.
>>>> I don't know if Dirk has something implemented.
>>>> I'll look tomorrow, I'm curious.
>>>>
>>>> Kin
>>>>
>>>>
>>>> Enviado desde Outlook para Android <https://aka.ms/AAb9ysg>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *De:* Dxspider-support <dxspider-support-bounces at tobit.co.uk>
>>>> en nombre de IZ2LSC via Dxspider-support
>>>> <dxspider-support at tobit.co.uk>
>>>> *Enviado:* martes, enero 21, 2025 9:30:48 p. m.
>>>> *Para:* The DXSpider Support list <dxspider-support at tobit.co.uk>
>>>> *CC:* IZ2LSC <iz2lsc.andrea at gmail.com>
>>>> *Asunto:* [Dxspider-support] Fwd: Max Spot per Minute (how to
>>>> avoid flooding)
>>>>
>>>> Hi sysops!
>>>> I was reviewing my cluster stats when I noticed this spike in
>>>> spot per minute (see attached image).
>>>>
>>>> <immagine.png>
>>>>
>>>>
>>>> Looking at the logs I can see a flood of 55 spots coming in the
>>>> same second from the same user, an extract below:
>>>>
>>>> 7074.4^DH2YBG^1737474360^FT8^KC9LFD^32^226^DB0ERF-5^28^14^8^4^^^204.93.149.214
>>>> 7074.4^GM6URC^1737474360^FT8^KC9LFD^65^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>>>> 7074.4^N5TLH^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^7^4^8^4^^^204.93.149.214
>>>> 7074.4^LA8ENA^1737474360^FT8^KC9LFD^123^226^DB0ERF-5^18^14^8^4^^^204.93.149.214
>>>> 7074.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>>>> 7074.4^F5SJF^1737474360^FT8^KC9LFD^42^226^DB0ERF-5^27^14^8^4^^^204.93.149.214
>>>> 7074.4^VK2WN^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>>>> 7074.4^N1UL^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>>> 7074.4^KA9SOG^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>>> 7074.4^VK3YW^1737474360^FT8^KC9LFD^198^226^DB0ERF-5^59^30^8^4^^^204.93.149.214
>>>> 7074.4^N9IBM^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>>> 7074.4^W5ORC^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>>> 7074.4^KP2BH^1737474360^FT8^KC9LFD^119^226^DB0ERF-5^11^8^8^4^^^204.93.149.214
>>>> 3573.4^K8CW^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^4^8^4^^^204.93.149.214
>>>> 3573.4^P40AA^1737474360^FT8^KC9LFD^326^226^DB0ERF-5^11^9^8^4^^^204.93.149.214
>>>> 3573.4^K1TAP^1737474360^FT8^KC9LFD^226^226^DB0ERF-5^8^5^8^4^^^204.93.149.214
>>>>
>>>>
>>>> Is there a way to activate a sort of flooding protection?
>>>>
>>>>
>>>> Thanks and 73
>>>>
>>>>
>>>> Andrea, IZ2LSC
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dxspider-support mailing list
>>>> Dxspider-support at tobit.co.uk
>>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>
>>> _______________________________________________
>>> Dxspider-support mailing list
>>> Dxspider-support at tobit.co.uk
>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> 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/20250126/03f2f512/attachment-0001.htm>
More information about the Dxspider-support
mailing list