Re: conflict of interest

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Tue, 4 Nov 1997 14:39:02 +0200 (EETDST)

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