ok, pretend you have a smallish cache peering collection eg:
/------ ISP B's domains
Cache B
/ | \
ISP A's domains - Cache A ----|--------- Each Cache's sep parents/internet
\ | /
Cache C
\---------- ISP C's domains
assume all are running 1.2 are are happily exchanging cache-digests around
via GET /squid-internal/cache-digest .
Now, all of the seperate caches have a acl defining their local domains,
which their squid will go direct for. Ideally, these local domain lists
would be spread about amonst the other caches so if B requests a domain on
C, it only asks C for it or goes direct.... etc.
Now I realise that you could play with acls on each cache and the
always/never direct options (if request is for a localdomain, and src is
cache X, hand it over etc...), *but* it is yet-another-option which can be
screwed up if a cache needs an urgent reinstall. (and believe me, this is
a common thing ;) )
Would it be possibly to (in addition to the cache-digests) have hmmm,
caches that are 'authoritive' for certain domains in a peering
relationship, requested by /squid-internal/localdomains . (does anyone
understand what I'm on about? ;) )
And yet another thing that would be nice, would it be possible to have a
'central' server that hands out cache-digests of other caches? This
wouldn't be so much of a help in situations where the caches are all nice
and close and 0cost to one another, but in situations where you have a
common peering point, and various 'expensive' links (whether in terms of
$$$ or latency) to various ISPs which you peer with (but its still cheaper
to use these links if the object is there, than to query your upstream
provider(s) ).
Perhaps /squid-internal/cache-digest.ip.of.another.cache ? (and this
mythical beast is routinely collecting cache-digests of other caches of
course).
--==--
Bruce.
K'nurdic Wrangler
Hub Communications.
Received on Thu May 28 1998 - 22:03:23 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:40:30 MST