The Active Cache Protocol

In Active Cache, the Web server specifies the association between a cache applet and a URL-named document by sending a new entity header, ``CacheApplet,'' with the document:

• CacheApplet: code = ``code.class'', archive = ``code.jar'', codebase = ``codebase_url''

The header follows the convention for applet specification in HTML documents. It specifies that the applet ``code.class'' at code base "codebase_url" is the cache applet for the document, and associated classes are grouped in an archive [#!sun-jar-guide!#]. Codebase and archive directives are optional. Since HTTP/1.1 allows the introduction of new entity headers, and requires that if a proxy does not recognize an entity header, it should forward the header, the server can be assured that Active-Cache enabled proxies will receive the header even if they have parent proxies.

For security concerns, we require that the codebase of the applet, if present, has the same server URL as the document. That is, only the Web server can supply the applet for its documents.

An Active-Cache enabled proxy agrees to fulfill the following obligations:

• if the document is cached and a user request hits on the document, it will either invoke the cache applet, or send the request directly to the server.
• if the applet's execution fails due to any reason, the request is sent to the server;
• if the applet's execution succeeds, the proxy will take the appropriate action based on the return value of the FromCache method (see below);
• each applet can deposit information in a special log object (whose name is ``appletname.log''), and the proxy will send the log object back to the server periodically. If the proxy evicts the log object from the cache, it will send it back to the server.

In other words, the proxy will not return a cached reply to the user unless the cache applet has been executed successfully, and the applet can deposit information in the log object which will eventually be reflected to the server.

However, the proxy decides whether it wants to cache the document, when it fetches the applet and the archive, and whether it wants to invoke the applet. Furthermore, the proxy can evict any document or any applet from its cache at any time. The only constraint on the proxy is the above agreements.

Active Cache Interface

The cache applet must implement an interface called ``ActiveCacheInterface.'' Currently, we require that the applet be written in Java. The interface defines a function called FromCache. The function is called when an access hits in the document, and arguments include the user request, the client IP address, client's machine name, the document in cache, and a new file descriptor for the applet to write in the reply file. The prototype of the function is listed below:

• public abstract int FromCache(String User_HTTP_Request, String Client_IP_Address, String Client_Name, int Cache_File, int New_File);

The arguments are included based on the principle that any information that the server can gather should the request go to the server, can be seen by the cache applet. The function can only return three values:

• 1: the content placed in New_File is to be returned to the user as the reply to the HTTP request;
• 0: the content in Cache_File can be returned to the user as the reply;
• -1: the request must be forwarded to the server.

All other return values are treated as -1.

The cache applet can only call the ActiveProxy class to perform its functions. The ActiveProxy class provides the native methods for file access , cache query, locking and unlocking as well as sending requests to servers. Currently, the methods include:

• public native static boolean is_in_cache(String URL);
• public native static int open(String URL, int mode);
• public native static int close(int fd);
• public native static int create(String URL, int mode);
• public native static int read(int fd, byte[] buf, int size);
• public native static int write(int fd, byte[] buf, int size);
• public native static long lseek(int fd, long off, int where);
• public native static int send_request_to_server(String HTTP_Request);
• public native static int lock(int fd);
• public native static int unlock(int fd);
• public native static String curtime();

As we gain more experience with the Active Cache paradigm, necessary methods will be added to the ActiveProxy class.

An applet's execution can be aborted any time. All changes to files and objects are voided if the execution is aborted. In other words, file changes are not committed until the applet finishes its execution.

The restrictions on the use of the proxy calls are the following:

• is_in_cache, open for read, lseek, read and close can only be called on the URL from the same server; the proxy verifies that the server URL of the document is the same as the server URL of the cache applet;
• open for write, create, write, lock and unlock can only be applied to URL-named objects that the applet has created; the create call automatically appends the applet's URL to the object's name;
• send_request_to_server can only send HTTP requests to the Web server; the method automatically connects to the server where the cache applet comes from.
• curtime is called that provide granularity only at the level of a second.

Any exception is caught and result in a return of -1 for the FromCache method.

In addition to the ActiveProxy methods, the only other packages present in the Java run-time environments are java.util, java.text, java.math, java.security and java.sql. All other packages, including java.io, java.lang, and java.systems, are simply not loaded. The proxy can do so because the cache applet has only one purpose, that is, performing per-request processing of the document, and thus needs a very simple security interface.