Re: [Dproxy-devel] dproxy 1.x

[<qu...@ba...>]

On Wed, 9 Feb 2000, Andreas Hofmeister wrote:

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

I suggest a reference count in the dproxy file ie:

name ip timeout refcount anyotherstuff

(Setting the file up this way means we can work with older dproxy
cache files - support backward compatability I say :)

When each site is accessed we increment the reference count. Thus when we
come to purge we purge the entries using ttl as the primary and refcount
as the secondary check. If we just use refcount then we may have a site
just entered (so refcount =1 ) and it will be purges straight away - not
what we want.

> 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 ...

How about basing the cache purge time on how long the person was online?
Ie in last/first line of proxy.cache keep an indicator. This indicator
could be used for the time and so ttl entries would be purged as they
expire based on the online time. This would however mean that the ttl
entrie wasn't used how it was initailly intended.
 
> 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 ...

I think it is possible on disk and in human readable format. I do think
that dproxy should have a limited memory cache for the most used entries.
A purge could write the memory cache to disk, purge it then reread the new
most used entries. If a server relies heavily on the dns for local machine
names, why should we have to go to disk each time? 

Cheers,
	Benjamin