|
|
| Line 1: |
Line 1: |
| ==Types of spot filters used in DXSpider==
| | #[[Authors and Contributors]] |
|
| |
|
| Basic filter types are "accept", "reject", and "clear" where the following applies ...
| | #[[Routing and Filtering]] |
| | | ##[[Routing_and_Filtering#Introduction|Introduction]] |
| *Reject filters - any spots that match will be dumped, all others passed on.
| | ##[[Routing_and_Filtering#Route filters|Route filters]] |
| *Accept filters - any spots that match are passed on, all others are dumped.
| | ##[[Routing_and_Filtering#The node_default filter|The node_default filter]] |
| *Clear filters - the filter slot(s) referenced will be cleared from the filter repository
| | ##[[Routing_and_Filtering#General route filtering|General route filtering]] |
| | | ##[[Routing_and_Filtering#General filter rules|General filter rules]] |
| For the most part we will use only reject and accept filters. These are the main filter types. Basically, reject means dump it and accept means take it and pass it on to the user. By nature, accept filters are more powerful than reject filters. A user can generally do with a one line accept rule what it could take many lines of reject rules to accomplish. However, the flip-side of this statement is that a series of reject filters are usually easier to administer and change.
| | ##[[Routing_and_Filtering#Types of filter|Types of filter]] |
| | | ##[[Routing_and_Filtering#Filter options|Filter options]] |
| ==Numbering lines and slots==
| | ##[[Routing_and_Filtering#Default filters|Default filters]] |
| | | ##[[Routing_and_Filtering#Advanced filtering|Advanced filtering]] |
| There are ten usable filter slots in DXSpider. Each slot holds one reject and one accept rule. Therefore, each type filter can have up to ten lines of rules contained in these ten slots. The filter rules must be numbered sequentially, that is, 0-9 lines of reject filter rules and 0-9 lines of accept filter rules to correspond to their respective slot position. If no number is used, every line is assumed to be in slot 1 and the addition of a second filter line of the same type without a number will just over-write the first that was previously written to slot 1. (Why not slot 0? I don't know. This is the way it works.)
| | ##[[Routing_and_Filtering#Basic hop control|Basic hop control]] |
| | | ##[[Routing_and_Filtering#Hop Control on Specific Nodes|Hop control on specific nodes]] |
| | | ##[[Routing_and_Filtering#Isolating networks|Isolating networks]] |
| '''Important:'''
| | ##[[Routing_and_Filtering#A DXSpider filtering tutorial|A DXSpider filtering tutorial]] |
| The filter rules are applied in sequence, i.e., 0-9. If a line matches, action is taken on that line. The filter sequence acts on rules in the order listed. It acts on the reject filter in each slot before acting on the accept filter contained in that slot. If the slot is completely blank or if a reject or accept filter line is missing in that slot it skips right over to the next filter rule in the sequence. A picture of a filter set might look like this ...
| | #[[Other filters]] |
| | | ##[[Other_filters#Filtering Mail|Filtering mail]] |
| Execution Sequence Slot Number Filter Rule
| | ##[[Other_filters#Filtering words from text fields in Announce, Talk and DX spots|Filtering words from text fields in Announce, Talk and DX spots]] |
| 1 Slot0 reject/spot 0 <pattern>
| | ##[[Other_filters#Stopping (possibly bad) DX Spots from Nodes or Spotters|Stopping (possibly bad) DX Spots from Nodes or Spotters |
| 2 accept/spot 0 <pattern>
| | ]] |
| 3 Slot1 reject/spot 1 <pattern>
| | #[[Mail]] |
| 4 accept/spot 1 <pattern>
| | ##[[Mail#Personal mail|Personal Mail]] |
| 5 Slot2 reject/spot 2 <pattern>
| | ##[[Mail#Bulletin mail|Bulletin mail]] |
| 6 accept/spot 2 <pattern>
| | ##[[Mail#forward.pl|forward.pl]] |
| . .
| | ##[[Mail#The msg command|The msg command]] |
| 19 Slot9 reject/spot 9 <pattern>
| | ##[[Mail#Message status|Message status]] |
| 20 accept/spot 9 <pattern>
| | ##[[Mail#Filtering mail|Filtering mail]] |
| | | ##[[Mail#Distribution lists|Distribution lists]] |
| | | ##[[Mail#BBS interface|BBS interface]] |
| ==Reject before accept==
| | #[[Scripts]] |
| | | #[[Databases]] |
| This is not a good rule for life, but it makes sense for DXSpider filters. As a general rule, reject filter rules within a slot are always executed before accept filter rules. There is a very good reason for this. If a spot doesn't match a reject filter, the spot is passed to the next filter line in the set. However, if a spot matches an accept filter, it is sent immediately to the user.
| | ##[[Databases#Creating databases|Creating databases]] |
| | | ##[[Databases#Importing databases|Importing databases]] |
| ==Using Multiple Reject Filter Rules==
| | ##[[Databases#Checking available databases|Checking available databases]] |
| | | ##[[Databases#Looking up databases|Looking up databases]] |
| Another important concept to know is that you can do everything you want to do with multiple reject filters AND NO ACCEPT FILTERS. By default, if a spot doesn't match any of the reject filter definitions, then the system considers you want the spot and sends it to you. For example, the following two filters perform exactly the same thing ...
| | ##[[Databases#Removing databases|Removing databases]] |
| | | #[[Information, files and useful programs]] |
| accept/spots on contesthf
| | ##[[Information,_files_and_useful_programs#motd|motd]] |
| reject/spots not on contesthf
| | ##[[Information,_files_and_useful_programs#motd_nor|motd_nor]] |
| | | ##[[Information,_files_and_useful_programs#Downtime message|Downtime message]] |
| So, why would we choose one rather than the other? Using reject syntax allows you to add another filter line easily, without disturbing the first line. A real example will show us how this works. Let's say that there is a RTTY contest coming up and you don't wish to see the RTTY spots. Simply add another reject filter like this ...
| | ##[[Information,_files_and_useful_programs#Other text messages|Other text messages]] |
| | | ##[[Information,_files_and_useful_programs#The Aliases file|The Aliases file]] |
| reject/spots 2 on hf/rtty
| | ##[[Information,_files_and_useful_programs#console.pl|console.pl]] |
| | | ##[[Information,_files_and_useful_programs#Updating kepler data|Updating kepler data]] |
| Note that we need to specify that this is the second line of reject filter definitions. Also, the "RTTY" sub-band specification has to be associated with a range of bands; it can't be specified all by itself. So, we just add it behind the range of bands defined by "HF". So in our example, if the user does a show/filter, he will be told by the Spider that his current filters are ...
| | ##[[Information,_files_and_useful_programs#The QRZ callbook|The QRZ callbook]] |
| | | ##[[Information,_files_and_useful_programs#Connecting logging programs|Connecting logging programs]] |
| filter 1 reject not on contesthf
| | #[[Java Web applet]] |
| filter 2 reject on hf/rtty
| | #[[Web based statistics]] |
| | | #[[Security]] |
| With these filters set up, if a spot comes through on 14085 kHz, the filter works like this ...
| | ##[[Security#Registration|Registration]] |
| | | ##[[Security#Passwords|Passwords]] |
| | | #[[CVS]] |
| *filter1: Is spot NOT on the HF contest bands? '''''No'''''
| | ##[[CVS#CVS from a Linux platform|CVS from a Linux platform]] |
| ** The spot doesn't match the filter definition, so pass it to next filter.
| | ##[[CVS#CVS from a Windows platform|CVS from a Windows platform]] |
| | |
| *filter2: Is spot within the frequency range defined for RTTY? '''''Yes'''''
| |
| ** Since the spot matches the filter definition, the spot is rejected and the user never sees it.
| |
| | |
| | |
| Had the frequency of the spot been 14025, then the spot would have not matched the filter2 definition either, would have passed through all the filters, and would have been sent to the user at the end of the filter set. Similarly, had the spot been on 10 MHz, it would have met the definition of filter1, been rejected immediately, and the filtering process would have stopped before processing filter2.
| |
| | |
| In addition, the filtering system has a rough time handling accept filters followed by reject filters and adds inefficiency to the processing. (Note: a reject as a "qualifier" to an accept rule in an accept filter line is okay as we will see below)
| |
| | |
| ==A very useful command==
| |
| | |
| To see all active filters in use at any time, just type the following command ...
| |
| | |
| show/filter
| |
| | |
| ==Case does not matter==
| |
| | |
| In entering any filter - case does not matter. Upper, lower, or mixed case will not effect how filters work or perform.
| |
| | |
| ==Qualifiers==
| |
| | |
| Logical operands can be used in rule sets to combine multiple actions or qualify others. These are ...
| |
| | |
| and a and b= action
| |
| not a not b= action
| |
| or a and not (c or b)= action
| |
| | |
| '''Note:''' as a general rule when or is used you must also use parentheses(). We will see how these can be used in examples later.
| |
| | |
| ==Comma Separation==
| |
| | |
| Any command can have multiple pattern variables if commas separate them. For example ...
| |
| | |
| reject/spot call_state nj,ny,pa,de,md
| |