--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Duane Wessels wrote:
> I've thought about this as well. I think it would be very useful.
> I'm thinking of something like
>=20
> X-Max-Cache-Hops: 3
>=20
> And each cache would decrement the counter before forwarding. When
> the count reaches zero, the request could only be forwarded to the
> origin server.
This is the other way around. I think it is more useful to have a
increasing counter as Markus proposed... but much harder...
X-Cache-Hops: N
By having this we can archeive the same result, with delegated control
of how far the object is allowed to travel.
But in both cases it requires careful thougths no not waste bandwidth.
If one of your siblings or parents has a object that has travelled
throught to many caches, then we will probably fetch it from them on
every request since we won't cache it (and they don't discard it)...
The obvious way to solve this is to have ICP and cache-able off by one..
if one more hop makes the object "uncacheable" then we should not
respond with ICP hit.. (only HTTP hit).
With a decreasing counter this is simple. Only answer ICP requests on
objects with more than one hop left. With a increasing counter it gets
much much harder (but not impossible).
--- Henrik Nordstr=F6m --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