Difference between revisions of "FEATURE Multithreading"
Lostcontrol (talk | contribs) |
(typo) |
||
| Line 1: | Line 1: | ||
== Multithreaded application == | == Multithreaded application == | ||
| − | Until version 0.6, {{Fail2ban}} is a single threaded application. When several sections are defined, each log file is parsed one after the other. This is not a problem when watching a single service. Moreover, when executing a command, {{Fail2ban}} waits for the end of it. This | + | Until version 0.6, {{Fail2ban}} is a single threaded application. When several sections are defined, each log file is parsed one after the other. This is not a problem when watching a single service. Moreover, when executing a command, {{Fail2ban}} waits for the end of it. This does not allow parsing of the log file at the same time. |
Version >=0.7 will be '''multithreaded'''. Three concepts need to be defined: | Version >=0.7 will be '''multithreaded'''. Three concepts need to be defined: | ||
| Line 9: | Line 9: | ||
** Action | ** Action | ||
| − | A ''Jail'' contains a ''Filter'' and an ''Action'' object. The ''Filter'' corresponds to the ''LogReader'' class of the previous versions. It take care of watching the log file(s) and notify ''Jail'' of any login failure. The ''Action'' corresponds to the ''Firewall'' class of the previous versions. It | + | A ''Jail'' contains a ''Filter'' and an ''Action'' object. The ''Filter'' corresponds to the ''LogReader'' class of the previous versions. It take care of watching the log file(s) and notify ''Jail'' of any login failure. The ''Action'' corresponds to the ''Firewall'' class of the previous versions. It takes the decision of banning or unbanning a host and executes the corresponding commands. |
''Filter'' and ''Action'' run in two threads. Thus, when starting a new ''Jail'', two new threads will be created. ''Filter'' and ''Action'' are independant and communicate with ''FailTicket'' through ''Jail''. ''FailTicket''s, generated by ''Filter'', are stored into a queue, waiting to be processed by ''Action''. | ''Filter'' and ''Action'' run in two threads. Thus, when starting a new ''Jail'', two new threads will be created. ''Filter'' and ''Action'' are independant and communicate with ''FailTicket'' through ''Jail''. ''FailTicket''s, generated by ''Filter'', are stored into a queue, waiting to be processed by ''Action''. | ||
[[Category:Feature]] | [[Category:Feature]] | ||
Latest revision as of 22:12, 18 May 2006
Multithreaded application
Until version 0.6, Fail2ban is a single threaded application. When several sections are defined, each log file is parsed one after the other. This is not a problem when watching a single service. Moreover, when executing a command, Fail2ban waits for the end of it. This does not allow parsing of the log file at the same time.
Version >=0.7 will be multithreaded. Three concepts need to be defined:
- Jail
- Filter
- Action
A Jail contains a Filter and an Action object. The Filter corresponds to the LogReader class of the previous versions. It take care of watching the log file(s) and notify Jail of any login failure. The Action corresponds to the Firewall class of the previous versions. It takes the decision of banning or unbanning a host and executes the corresponding commands.
Filter and Action run in two threads. Thus, when starting a new Jail, two new threads will be created. Filter and Action are independant and communicate with FailTicket through Jail. FailTickets, generated by Filter, are stored into a queue, waiting to be processed by Action.
