> From fberzau@novell.com Mon Sep 6 06:52 EDT 1999
>
> A reverse cache is not by definition "controlled by a content provider".
>
> In most cases this will be the case. But it does not need to be. Everyone can set up an accelerator everywhere. Just as an example, we usually set up an accelerator (reverse cache) for www.novell.com in technical trainings. Or, yet another example, internally I've setup accelerators for various popular sites on a test server. By using a reverse cache internally Ican improve performance dramatically. All I need to do is "hack" the dns entry, so with my browser I access the reverse cache instead of the origin server on the internet (or I simply access the reverse cache by ip address). I'm doing it for example with my own website, which is hosted at an outside internet service provider, who doesn't even know that the site is reverse cached.
>
> The point is, a reverse cache MAY (and will most likely be), but definitely MUST NOT be under the same administrative control than the origin server that it accelerates. I would define a "reverse cache" as a device that acts on behalf of the origin server. The dns record for the server is modified so that it points to the reverse cache instead of the origin server. The reverse cache will fill the cache from the origin server for any requests coming in. It is using the same algorithms than the forward cache to control object freshness.
>
> Frank
>
I think we are talking about the same thing, and the misunderstanding
confirms that my wording was sloppy. I did not mean necessarily
administrative control in a narrow sense that the origin server and
the reverse proxy share the same ISP or corporate network. The main
thing is that
clients or client ISPs are oblivious to the reverses proxy: it is the
responsilibity of the content provider to deliver requests to it.
Also, since content provider MUST
be aware of the reverse proxy, it can implement all sorts of things
like strong cache consistency, usage reporting, etc. In other words,
it can have as much *control* over the reverse proxy as it chooses.
The fact that
the reverse proxy may reside in a different ISP does not change the
fact that the content provider has control over it.
Your examples fall right into this. If you agree with the meat of it,
we can work together on the exact wording.
Your wording suggestion that a reverse proxy acts "on behalf of the
content server" looks too vague to me. I'd say that the forward
proxy (esp. the transparent one) acts on behalf of the end-server as
well when sergving the object for the cache (and impersonating the
end-server).
Also, putting into the definition a particular mechanism (DNS-based)
for delivering requests to the reverse proxy is too narrow.
For example, we here at AT&T were seriously considering using WCCP at
the access routers to transparently divert requests from our users to
reverse proxies. (We currently decided in favor of DNS solution,
but it does not change my point.)
>
> >>> michael rabinovich <misha@research.att.com> 05.09.99 4.11 >>>
> Here are my definition drafts. Apologies if wording is sloppy in some
> places - this can be corrected at a later time. Your examples
>
> Misha Rabinovich.
> A reverse cache is the cache that is controlled by a content provider.
> ^^^^^^^^^^^^^^^
> It is the responsibility of the content provider to deliver requests
> to the reverse cache. Clients are oblivious to the existence of
> reverse caches.
>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST