Re: another new paradigm

-----BEGIN PGP SIGNED MESSAGE-----

Henrik Nordstrom writes:

| What about the new cache-digests? sounds like the perfect way to inform
| the grand central about cached objects...

I've been talking with Duane and Alex a little about this - had the
idea that we could pull the cache digests from servers into an "index
server" running some Nth generation descendant of the grand-central
thing, and then issue a referral (this hypothetical new ICP opcode) to
the relevant server or servers based on the cache digest forward
knowledge, when queried for a given URL.

This is the same principle we're using in a rather different arena -
see RFCs 1913, 1914, 1835 and draft-ietf-find-cip-arch-01. Whether
it's scaleable is another matter! The search and retrieval thing
isn't a good comparison because you're often searching for complex
Boolean expressions with attribute/value constraints, whereas the
cache thing isn't much more than a lookup when all's told ? I suspect
there'll still be a place for ICP (or an ICP/HTCP-like thing) for
quite some time to come, though cache digests are looking "fab" :-))

| What should the requesting cache do if it fails to request it from the
| returned cache? Should the grand central be notified?

I'm thinking that it should be up to the admin of the requesting cache
who they want to honour referrals for - perhaps by piggybacking off
the multicast-responder code. The bottom line is that if you get
redirected to a server you don't have configured as a peer already,
you probably don't want to trust the redirection ? Trust is indicated
by the presence of a cache_peer entry of some sort in squid.conf

Ciao!

Martin

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNT80rNZdpXZXTSjhAQEuygQApE6VYtg3qFct+w5PbwioPdunB/uU41vl
j3WgJg+QtPg1nmXXpVR7ePIaM3cj49qwnUlOrF2JlNUIQyC+7xgSpsCm9+cgC8GN
+1JKBYBrzDt46Qe1qJGP9DIi5aPDx5Pcs3nexDmO3VCl1urEL9Ma1QkQjOUgALvK
YxOZ6ASuQDY=
=XdbE
-----END PGP SIGNATURE-----
Received on Tue Jul 29 2003 - 13:15:47 MDT