Re: The Future

Hi

> ck@toplink.net said:
> } A separate process would only make matters more complicated and would
> } not do anything to speed up the lookup. A decent algorithm for ip acl
> } lookup would do the job far nicer.
>
> I think that having the acl stuff as a separate process need not
> significantly slow things down. If given a nice API, it does allow you to
> do some very wierd and wonderful things with ACL processing, so a policy
> based setup, or bandwidth based access limitation could be coded by
> someone external to squid and just dropped in - just like the rewriting.

yest it may not slow it down too much but I dont't think it's wort the
effort of putting acl searches to an external process when we could achieve
an order of magnitude faster response by going from a liner search
to a hashed or tree structure.

I have implemented an an ip to net matching algorithm with a hashtable
in a separate project. The bsd4.4 kernel uses a structure they call a
radix tree for the routing table. Both have in common that the search
goes from O(n) to O(log n)

This kind of change would bring lots of speed to acl mathing without any
significant rework.

Greetings
Christian Kratzer
TopLink

-- 
TopLink GbR, Internet Services			info@toplink.net
Christian Kratzer				http://www.toplink.net/
Phone: 	+49 7452 885-0
Fax: 	+49 7452 885-199	FreeBSD spoken here!