Re: conflict of interest

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

On Mon, Nov 03, 1997 at 04:27:49PM -0800, Duane Wessels wrote:
> 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?

This would in a worst case have to be recursively handled by caches,
right? Maybe this is the point where we should think of using
a lightweighted database instead of the log file.

If you work on a solution (wasn't there a kind of a "Received" header
to be added by caches) I'd have a slightly off topic proposal that
I am thinking of for quite some time:
Could we have a kind of a hop-count in the objects? This would be
set to one 1, if the object is fetched directly from the origin server
and would be incremented by one if already present (i.e. fetched from
a parent or neighbor).
This would allow cache admins to add a "radius" value to the cache_host
directive.
The benefit would IMHO be a bit more security: I trust my neighbor that
it doesn't feed in "false" objects, so I trust the objects this neighbor
got directly. But I don't know about its neighbors, so I don't want
to accept objects that this cache got from one of its neighbors. So I
would set the radius value for this neighbor to 1.
On the other hand I trust my parent in the choice of neighbors, so I
set the radius to 2 and would accept objects that my parent got directly
or with radius 1 from its neighbors.

        \Maex

-- 
SpaceNet GmbH          |   http://www.Space.Net/   | If you don't think women
Research & Development | mailto:research@Space.Net | are explosive, drop one!
Frankfurter Ring 193a  |  Tel: +49 (89) 32356-0    |
D-80807 Muenchen       |  Fax: +49 (89) 32356-299  |
--MimeMultipartBoundary--