[Dxspider-support] Controlling upstream spots

[Allen]

Hi Dirk & Martin,

Thanks for the responses.Just to clarify my goals, currently collecting 
and passing WWFF and SOTA into my node. I want the WWFF spots to go out 
into the cluster network but not the SOTA spots. Trying to balance 
between local users (those who are connecting logging software to my 
node) and the wider cluster network. Currently throttling the spots but 
would prefer increase the spots and filter what is leaving my node.

So filters are the key. Read the filters wiki page last night and can 
see that the info option will help. The remarks string will contain a 
key for info to match.

Still not clear on the difference between connected users and upstream 
nodes so I shall setup a filters and test. So back to manual to verify 
the commands then test. So far;

rej/spot node_default info SOTA
or
rcmd rej/spot info SOTA

Another option would be to ask the upstream nodes to place filters 
rejecting the SOTA spots from me, prefer to resolve on my node.

anyway Saturday afternoon, not going out activating today so time to test.

cheers

Allen
VK3HRA

On 9/01/2016 7:55 am, djk wrote:
> On 08/01/16 20:21, Martin Davies G0HDB wrote:
>> Hello Dirk (and Allen), I tinkered with node_default spot filters a little while ago and ended up
>> with a spot input filter on GB7DXC-5 that looked like:
>>
>> rej/spot node_default input on hf and not by_zone 14,15
>>
>> This prevented all spots not originated in zones 14 or 15 from getting into the node and then
>> being sent to its connected users, which was what I wanted at the time.
>>
>> Would it be possible for Allen to subsitute 'output' for 'input' so that he ended up with a reject
>> filter that would look like:
>>
>> rej/spot node_default output <filter-spec>
>>
>> Is 'output' a valid qualifier for node_default in the same way as 'input' is?
>>
>
> No. But 'output' is the normal case. Arguably I should allow 'output'
> and ignore it (it's possible that I already ignore it, I'm just too lazy
> to look right now).
>
> If a filter isn't explicitly marked as 'input', it's 'output'.
>
>  From time to time people ask "why?". I have made an attempt at
> explaining in the various overviews of filtering either in the help
> system or in the filtering manual, but in essence this is the rationale:
>
> If one is connected as a user, then stuff like spots, announces etc are
> being sent _to_  the user _from_ the node. From the node's point of
> view, they are being _output _from the node to the user. Hence the
> default case. The same view applies to spots being sent or distributed
> to connected nodes. So if there is a 'node_default' filter then it
> filters spots (for example) coming in from other nodes when they are
> distributed onward (i.e. 'output') to all the other nodes.
>
> Conversely, an 'input' 'node_default' filter stops unwanted spots (again
> for example) coming into the node in the first place. But, particularly
> if the filter is restrictive, then that can be rather inefficient. At
> this point one can remember that, to the sending node, it is 'output'ing
> spots to you, so one can stop that node sending you stuff you don't want
> by sending that node an 'rcmd rej/spot on hf and not by_zone 14,15' - in
> other words - behaving just like a normal user filter.
>
> Normally one does both because these filters being  sent by rcmd are (by
> definition) node specific and, over time, other nodes may connect and
> the input filter will act as a backstop.
>
> Dirk G1TLH
>
>
>
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>