Vancouver Webpages Cache
On an experimental basis, the
Squid Cache here is
available to local users from the following domains:
Access controls were put in place 14 April 1997. It was apparant that
some ICP access had a low hit ratio and did not make sense topologically.
See the cache statistics.
Current network topology in BC is somewhat
tangled, at least until we get the promised POP network hub. It
does not make sense for someone on Infomatch (13 hops, via Seattle) to
use the proxy here to access SFU (11 hops, via Seattle). It's probably
better to go direct.
The first 2 domains listed are local; there is no increase in Net traffic
even for a cache miss. I will entertain requests for ICP and TCP access
where it makes sense; this means that this server must be significantly closer
than most Websites of interest.
To use with Netscape Navigator, go to
Options --> Network Preferences, select
Proxies, select Automatic Proxy Configuration
and enter http://vancouver-webpages.com/proxy.pac
(or http://vancouver-webpages.com/cgi-bin/proxy.pac which is
now the redirected location)
in the Location box, then click OK.
This is currently set to access
objects from the following domains directly:
An experimental proxy algorithm is now in place using the
For clients less than 6 hops away, all non-local requests are
proxied. For distant clients, no requests are proxied, while
for intermediate clients, international objects
(not in the
.ca, .com, .org, .net or .mil domains)
are fetched from the parent cache bo.cache.nlanr.net, 8 hops
away in Boulder, Colorado, and others are fetched directly.
Any objects using secure HTTP,
requiring authentication, etc. are fetched directly.
If the cache is unavailable,
Netscape automatically switches to a direct connection.
will give you an idea how close you are to
Vancouver Webpages (the closer
the better). If you are more than about 8 hops away, it's probably not worth your
while. You might look for a closer cache, from e.g.
the NLANR database.
Errors and Reloads
If you don't use a proxy, and you enter a
bad URL, you get a message from
Netscape. When you are using a proxy, you get a
message from the proxy
or from the hierarchy cache instead.
Common errors include entering a partly qualified host name, then
asking the proxy for it (suppose you are at tt1.some.org, and enter
"www" instead of "www.some.org". Without a proxy, this would
work.) Another error is trying to access a server which restricts client
domains. The server sees the proxy address, not yours.
Sometimes the cache will have a stale copy of a document. If the origin
server is properly configured this should not happen often. However,
using Reload will usually get a fresh copy. In emergency,
Shift-Reload guarantees a clean copy.
If you are on a slow (less than 64kbps) modem, you may not see any
gain using a hierarchy cache to domestic sites. You may, however, see
some improvement in speed to international sites. Instead of getting
all the text, images, applets etc. for a Web page down a transatlantic
cable or across a satellite link, you get a copy from the disk here, if
it exists (which it may well do for a popular page).
If it is, you get it much quicker, plus the transatlantic bandwidth is
available for other things, like getting copies of pages that aren't
in the cache yet.
This cache is now connected to the
NLANR cache mesh, which has some
dedicated bandwidth to Europe and several large cache servers.
See the Cache Now! page for more detail, links
to cache resources, etc.
The cache here may be expanded to a larger service as part of a Canadian
cache mesh. In this case access may be restricted to peer relationships
to other cache servers, which would be set up at ISPs and on Internet
connected LANs. Please contact
me if you are interested in joining such a scheme. A small fee may apply.