Figure 6 shows the architecture of our system. The browser connects to a local (client) proxy using the usual HTTP proxy-caching mechanism, by sending it requests containing the full URL of a desired page. We assume that the browser does not cache pages, but instead relies on the client proxy; however, this does not affect correctness, only storage utilization and caching effectiveness. The client proxy serves the request out of its cache if possible, or forwards it to the server proxy on the other side of the slow connection. The added overhead of a client proxy on the same machine is minimal by comparison to network delays and so the analysis in Section 2.2 still holds.
Figure 6: System architecture.
The server proxy can respond using its cache if the request is for a cached page, the page is not out of date with respect to its expiration date (if any), and the client has not issued the nocache pragma. Otherwise, it forwards the request upstream, either directly to the content provider or to yet another proxy-caching server. In either case, if the client and server proxies share a cached version, a delta from that version to the current version can be sent once the current version is available. If they do not share a cached version but the server proxy has some version cached, the server can send the possibly stale version followed by a delta from that version to the current version.
The server proxy determines what the client proxy has cached via some extra headers in the HTTP request. First, an Accepts: multipart/attdelta field indicates that the client understands the delta format. This way, a browser or other unmodified client can talk to our proxy without getting back something it cannot interpret. Second, a Current-version: [signature] field informs the server which version the client has cached, if any. The signature can in principle be anything that can distinguish different versions of a document, such as an MD5 checksum. We make the simplifying assumption that any client proxy that requests a new version from a server proxy will have received the previous version from the same proxy, and we use a monotonically increasing version number (instead of a checksum) that the server generates and passes to its clients.
Table 1 summarizes the possible combinations of client/server proxy states and the procedures that are followed.
Table 1: Possible states when requesting a URL. ``Cached copy
current?'' refers to whether the server proxy can respond using
its cached copy without consulting the content provider.
