--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
> The past couple of days I have been munging squid 1.2 to support using
> SHA digests as cache keys. This is of course a result of the
> discussion some months ago about compressing URLs which then became
> 'why not just use MD5 hashes?' FWIW, I started with SHA instead of MD5
> because some people hinted it might be better and has no use
> restrictions. However, it will be easy to plug MD5 in (or any other
> scheme) should any desire to do so.
I'd even go with MD4 for speed, I don't believe there will be any
problems with collisions.
> Anyway, Kostas is working on adding hit metering into Squid and today
> we realized that hit metering will become very difficult when the
> cache key is one-way hash of the URL. When we need to purge
> an object, we're supposed to make a HEAD request for the URL to
> report the hits. But we won't have the URL any more.
Why not do that when verifying object and do purge silently?
We also can keep hash->url translations in a dbm file.
> In fact, hit metering will require quite a bit of additional overhead
> for every object. In addition to some four integer counters, the draft
> requires that hits be reported back to the source of the object, and
> not necessarily the origin server. So we'd have to remember which
> neighbor gave us each object. ick.
>
> Thoughts?
remembering neighbors is bad. By the time we want to report, neighbor
might be well dead for a while.
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Network Manager
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:44 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:28 MST