[Dxspider-support] Controlling upstream spots

[Allen]

Hi all,

The filter worked as expected. It killed spots with the key for info 
sent to the node. Very straight forward in the end,however this does not 
do what I wanted. I want the spots to be visible to users connected to 
my node but not propagated into the cluster system. So to plan B.

I will be sending email to the sysops of my upstream clusters to add the 
filter as running 'rcmd' against another sites without notification 
seems rude.

Thanks for the responses.

Allen
VK3HRA


On 10/01/2016 3:15 am, Martin Davies G0HDB wrote:
> On 8 Jan 2016 at 20:55, djk wrote:
>
>> 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.
>
> Thanks Dirk, it all makes sense now - if I'd thought about it a bit more then perhaps I would
> have realised that 'output' is the default case for a node sending spots or whatever either to
> another node or to a user so the qualifier isn't necessary for 'node_default'.
>
> As for using 'rcmd' to set up a reject filter on the node that's outputting spots to another node,
> I'll try to remember to do that on GB7BAA and GB7DJK when I want to restrict the flow of
> spots into GB7DXC-5, eg. during the CQWW contests.
>
> Allen - I hope you manage to get your spot filtering sorted out; to me it looks like rcmd'ing
> your suggested 'rej/spot info SOTA' onto your upstream nodes should do the job for you.  I
> suspect if you did 'rej/spot node_default info SOTA' on your node then that would prevent any
> of the SOTA spots originating on your node from being sent to the users connected to your
> node (but I could be wrong!).
>
> --
> 73, Martin G0HDB
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>