Re: hop-count header

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

Hi

> I've thought about this as well. I think it would be very useful.
> I'm thinking of something like
>
> X-Max-Cache-Hops: 3
>
> And each cache would decrement the counter before forwarding. When
> the count reaches zero, the request could only be forwarded to the
> origin server.

A question though:

We have 3 caches - currently they all talk to one another with the 'proxy-only'
flag. If someone chose not to use this flag, though, couldn't you end
up with a forwarding loop? (especially without this flag)

cache1 originally gets the object from the origin server.
cache2 gets it from cache1 5 minutes before it expires and puts it in
        it's own cache with a (say) 3 day expiry time.
5 minutes before it expires from cache2, cache 1 gets it, and marks it with
        a 3 day expiry time.

If this is mentioned in the RFCs sorry, but I don't remember it....
you don't get expiry information in the ICP request, do you?

The header would solve this - there is a problem with it
though...

cache1 has the object. cache2 wants the object. cache2 has a policy that won't
allow it to accept objects that have hopped more than 3 times. It sends
ICP queries and finds out that cache1 has the object, but doesn't know how
many times it's hopped - so it starts the download form cache1, only to find
the object has hopped too many times. It then has to abort the download
and try the other siblings which responded... not nice.

Other way of doing it, you don't respond to ICP queries if you have an object
that's had more than X hops.... another flag to keep in ram though, and
you have to trust your siblings not to feed you ancient objects, and they
have to run software which supports X-Max-Cache-Hops

Oskar

-- 
"Haven't slept at all. I don't see why people insist on sleeping. You feel
so much better if you don't. And how can anyone want to lose a minute -
a single minute of being alive?"				-- Think Twice
--MimeMultipartBoundary--