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 the arguments of the function call include the user request, the IP address of the client machine, the name of the client machine, the document in cache, and a new file descriptor for the applet to write when constructing a new Web page. 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 if the request goes 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, other necessary methods might be added to the ActiveProxy class.

An applet's execution can be aborted at 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 URL-named documents that are from the same server. In other words, 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 provides a timing granularity of one second.

Furthermore, all exceptions are caught and result in a return value of -1 for the FromCache method.

Objects created by an applet (including the log object) are invisible to the outside world except to the original server that sends the applet. A server can gather the log objects of its applets through the Internet Cache Protocol (ICP) (3, 3). ICP is originally designed for cache sharing and serves as a convenient channel for servers to gather log objects.

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.