[Dxspider-support] Release candidate

[Keith, G6NHU]

The whole idea of having to change variables for contest periods feels a bit awkward to me.  I’d wager that 95% (probably higher) of sysops aren’t going to do that sort of thing.

I don’t know what the alternative is though.

73 Keith.

On 20 Mar 2025 at 19:03 +0000, Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk>, wrote:
> This is an extract from another email…
>
> This an attempt to explain how the code  for flooding protection for spot call, by call, node and ip addresses (call/ip thing below) works:
>
> 1. If a call/ip thing dupe does not exist it will create an entry in the dupe store with the current time+initial timeout ( 10 seconds ) and passed onward.
> 2. If the call/ip thing exists in the dupe file but the time stored is less than the threshold then it is incremented by a tick (was 10 seconds but is now 5 seconds) and then passed onward as though there was no dupe.
> 3. If the call/ip thing exists in the dupe file and the time stored is >= threshold then it is declared to be a DUPE.
>
> While all this is going on the Dupe cleaner is ticking along every 5 secs underneath deleting all Dupe records created here that have expired. This is how the whole system is self regulating. By setting the threshold you have decide how call/ip things you want to allow over that many 5 seconds ticks. After that it is declared a dupe until it cleaned or time has marched so that the dupe entry has dropped below threshold. If more come in and the threshold is crossed, then the whole cycle repeats.
>
> Node calls are treated as above but with their own dupage and threshold (which is higher than for the other three call/ip things. I suspect that this will need to be switched off during CQ WW as threshold will have to be set too high to be useful for the likes of VE7CC etc.
>
> There is a switch for disabling each class of call/ip things.
>
> This is still a work in progress and we will see how well it behaves this weekend.
>
> Dirk
>
>
> By this means I am trying to detect floods of spots that reuse one (or more) of these call/ip things in the made up spots used to annoy users.
>
> > On 20 Mar 2025, at 17:04, Christopher Schlegel <sutehk.cs at gmail.com> wrote:
> >
> > Thanks for the update. Already have those statements set thanks to some of Kin's postings.
> > Question, could you explain a bit about how $Spot::dupecall and $Spot::dupecallthreshold interact in the code. I read through the code, but since I'm not familiar with Perl it's not making sense yet.
> > Chris, WI3W
> >
> > On Thu, Mar 20, 2025, 12:56 Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> > > One of the things that is going to important for the next release is for sysops running (test?) instances behind masquerading firewalls (eg my development node GB7TLH)  is to have these three statements (suitably modified) in your startup script:
> > >
> > > set/var $main::localhost_alias_ipv4 '82.68.205.1'
> > > set/var $main::localhost_alias_ipv6 '2a02:8010:9019::6'
> > > set/var @main::localhost_names qw(127.0.0.1 ::1 192.168.19.20)
> > >
> > > These are the ip addresses that will be used on PC92 sentences (amongst others) when the node is not physically connected directly to the internet.
> > >
> > > With this release PC92 K records will have an ip address and a version string tacked on the end:
> > >
> > >  PC92^GB7TLH^58020.01^K^5GB7TLH:5457:593^4^1^82.68.205.1^test/f9b61990[r]^H99^
> > >
> > > Dirk G1TLH
> > > _______________________________________________
> > > 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/20250320/912f69d9/attachment.htm>