Re: Webbrowser cache implementation.

Gregory Maxwell writes:

| Anyone know if you could do this:
| a webclient's ip is:
| 123.123.123.30
| could it send a udp icp quary to:
| 123.123.123.255
| to see if there is a cache listening to that brodcast address?
| Any ideas on how to do some form of automatic reg?

That might not get you very far, e.g. if the cache server is on a
different subnet and your routers don't have bootp helper type
doobries on them ? You wouldn't typically want to propagate
broadcast packets around a large network ?

If you want to pro-actively search out proxy servers, it might be
better to consider multicasting an ICP request - but there are lots of
caveats to this. For instance, whether you have multicast routing set
up, whether your TCP/IP stack supports multicast, and so on! You're
also relying on cooperation from the cache server operator, who might
not want to honour multicast ICP requests originating from non-peers.

There are also lots of directory type services which could be looked
in for pointers to cache servers. There's even a dedicated thing
called the Service Location Protocol - check out the protocol spec,
draft-ietf-svrloc-protocol-17.txt at your local Internet Drafts mirror
site. Hardly anyone seems to run these sorts of services at the
moment, and to my knowledge nobody has tried to establish a convention
for referring to these types of services in any of their various
schemas (yet!). Anyone know better ?

Alternatively, the cache server could periodically multicast a packet
announcing itself, and browsers could learn about new cache servers
from this - pre-supposing the multicast infrastructure is in place to
support it. I keep meaning to get around to updating send-announce
so that it can send the server announcements to multicast groups as
well as unicast addresses... One of these days :-)

For a practical solution that'll work now, I suspect you're stuck
with :-

  # maybe try localhost first ?
  try connecting to well-known cache server ports, e.g.
    8080 and 3128, on local machine
  maybe drop out here if successful
  # now probe for well-known aliases, "nearest" first
  take this host's current fully qualified domain name,
    if you can figure it out
  while there are domain components left {
    strip a domain component
    try connecting to well-known cache server ports and
      aliases, e.g. cache.<remaining-domain-components>
    maybe drop out here if successful
  }
  # bummer

The commonly used aliases seem to be "cache", "proxy", "wwwcache",
"www-cache" and "www-proxy" - though there are a lot of people
operating caches without any special domain name.

Cheerio,

Martin