Cache Now!

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.

HOWTO

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 PAC file. 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.

This tool 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.

Why Bother?

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.

Future Plans

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.

Cache Statistics

Current Report
Previous Reports
Webpages Admin