Re: [Dproxy-devel] dproxy 1.x

[Andreas H. <hof...@in...>]

Hi,

jeroen wrote:
> 
> Andi,
> 
> I just downloaded the 1.x source tree, looks nice. (although I did saw a
> few goto's in dproxy.c....not a real problem but dangerous.....) I
> haven't yet looked at it really close, but I saw a few things about
> ipv6, is that working already???

Nope, I need to read the RFC's first. Those points where you saw
something about ipv6 are some sort of 'fixme' markers for the future.

> 
> I have been thinking about the problems you mentioned about refreshing,
> but I think they are solved if a config option 'max_entries' is added,
> this would cause the oldest to be deleted if the cache gets to big, if
> it is frequently used it will appear at the end of the cache the next
> time it gets looked up.

FIFO is not the best cache strategy one can think of, but it would work. 

There is another problem with that 'refresh' thing: Consider you conatct
a large number of sites one day, your 'CACHE_PURGE_TIME' is set to n
days. On the n'th day, you do not connect to the net. If you now connect
the net on the n+1 day, all entries are refreshed in one run. The
situation will get even worse if you do not connect to the net for a
longer periode (say hollidays).
Once all the hosts looked up in that single run, they will have the same
creation time, so they will always refreshed together ...

IMO those problems can not be solved with an on disk cache, as long as
this has no fixed record structure, but this would mean that the cache
wasted much space on disk and was not human readable anymore. We could
solve the refresh problems with an memory cache ...

> 
> Everybody:
> 
> About the memory cache and other things I saw in the last few mails, I
> agree with Matty that we should be carefull not to bloat it to much. I
> started using dproxy because it was nice and small and didn't need much
> config (I know.... I started the config thing.......) I think we should
> leave all the little extra's to our 'big brothers' like bind or dent,
> and concentrate on what dproxy was originally made for: small LAN's.

Sure, but some features are usefull even for smaller networks, e.g.
there is a small network monitor 'tkined' that could use HINFO records,
or if you want to have a central mail server for your net, MX records
are very usefull.

Also small depends on your point of view, if you have 3-4 hosts, you may
think 100 hosts make a big network, if you are admin for a net with some
1000 hosts, 100 are a small network.

IMO 100 hosts is a number that fits most of the applications for dproxy
- home networks, department of an university, a workstation pool and
small companies.


> I don't think we should change the deny file to dbase format, it would
> also bloat dproxy.

Do you talk about the 'hosts' file, the cache or about dproxy.deny ?

> Maybe it is an idea to add a keyword search to it??? e.g. *xxx in the
> deny file would cause all domains with 'xxx' to get rejected?

Thats already in, dproxy tries to match the strings from 'dproxy.deny'
with the
end of a hostname, so a query for 'a.b.c' will be blocked by a
'dproxy.deny' line like 'b.c'  - btw. this would also block x.yb.c' ->
all domain names in the deny file should have a dot as first char.


Ciao
  Andreas

-- 
Andreas Hofmeister (see http://www.informatik.uni-freiburg.de/~hofmeist)

"I can do it in Quake, why not in real life ?"
				(Lan Solaris (Illiad))

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/IT d-- s--:>++: a C++ ULSC+++$ P+++ L+++ E+ W++ N+ o? !w--- !O !M--
V-- 
PS++ PE-- Y+ PGP- t+ 5? X+ !R !tv b+ DI? D++ G e>+++ h(++) r% y+
-----END GEEK CODE BLOCK-----