| To: | Pablo Neira <pablo@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC] string matching based packet classification/filtering |
| From: | Thomas Graf <tgraf@xxxxxxx> |
| Date: | Thu, 17 Feb 2005 14:31:14 +0100 |
| Cc: | netdev@xxxxxxxxxxx, Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>, Harald Welte <laforge@xxxxxxxxxxxx> |
| In-reply-to: | <4213ECC9.30502@eurodev.net> |
| References: | <20050215203211.GL31837@postel.suug.ch> <42126C9B.5060406@eurodev.net> <20050216223038.GQ31837@postel.suug.ch> <4213ECC9.30502@eurodev.net> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
> >The matching algorithm would parse the array as a finite automation > >eating up byte by byte in the text. > > > > Looks good but Boyer-Moore algorithm doesn't need this at all. BM > doesn't support wildcards like '*' because of the shiftings that it uses > to look for matches. This issue together with memory consumption are two > limitations that we have to live with if we want to use BM. Anyway I > think it's worth it because we can perform search in O(n/m). This would be _additional_ to BM/KMP/naive/finite automata/you name it. The benefit of libqsearch is hide various algorithms behind a single interface, isn't it? It's argueable whether it would make sense to try and rule out bad shifts while parsing a chain of non-wildcard regular expression tokens but I guess that would be over the top. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [XFRM]: Always reroute in tunnel mode, Herbert Xu |
|---|---|
| Next by Date: | Re: skb_clone, junk |
| Previous by Thread: | Re: [RFC] string matching based packet classification/filtering, Pablo Neira |
| Next by Thread: | eepro100 broken on ARM by 2.6.11-rc1 changes, Lennert Buytenhek |
| Indexes: | [Date] [Thread] [Top] [All Lists] |