2.3 Hit-Server Architecture

 

The hit-server provides efficient mechanisms for processing client requests that hit in the object cache. Upon a client request, the hit-server locates the requested object and either downloads it to the client (on a get), creates a new version (on a put), or forwards the request to the miss-server (on a miss).

The hit-server is free of policy. Its general mechanisms are intended to support any policy that the miss-servers can implement, so developers can create application-specific server systems. For example, when cache replacement is signaled by the hit-server, the miss-server is free to select the objects to be replaced. A miss-server library provides general miss-server primitives and a set of functions that use these primitives to implement predefined policies. However, the developer can choose to build a miss-server from any combination of predefined and custom policies or even build a new miss server from scratch.

The hit-server processes client get/put requests to access a large RAM cache of objects and processes miss-server add/remove requests to modify the cache. Requests that result in cache misses are forwarded to the miss-server.

The default get operation first checks whether the object is available. Then, the client is authorized against the object's ACL. Next, the object's status data and consistency matrix may indicate that the object's miss-server be signaled, so it can implement the object's consistency policy (see Section 5 for details). Finally, after verifying that a download is necessary by checking version numbers, the hit-server sends the requested object data to the client.

The put operation is similar except that each put generates a new version of the object: First, the entire object is copied (lazily); then, those object parts are modified that are addressed by the put data. The mentioned copy operation is based on copy-on-write techniques; basically, the newly received packets are simply linked into the new version's data descriptor. (The per-object data descriptor is similar to a multi-level page table but implements a granularity of 1K.) This technique makes it easy to update an object while gets are concurrently active. After all gets on the old version are finished, the old version can be garbage collected.

Similar to the DynamicWeb cache [8], the hit-server interface permits to cache dynamic Web pages or other dynamic objects. The application running on the miss server constructs the dynamic object on demand and invalidates or updates it in the hit-server whenever necessary. Note that this requires only default putget operations. If the method is too expensive, e.g.\ for a dynamic object that delivers random numbers, an object-specifc putget can be used that executes directly on the hit-server.

The architecture enables flexible handling of objects through object-specific putget operations. An object-specific operation supersedes the default. Object-specific putget methods are run on the hit-server to enable efficient implementation of custom operations. An object-specific put operation is invoked after the new data is received, but prior to updating the object cache. E.g., it can be used to implement object-specific consistency protocols that are executed when an update is made. An object-specific get operation is invoked prior to delivery to the client. An object-specific get can be used to deliver modified object data to a client (e.g., for displaying the object effectively on the client).

In order to prevent corruption of the hit-server and denial-of-service to clients, the hit-server must control these object-specific putget operations. We assign each object-specific putget operation to its own address space to protect the hit-server and other object-specific operations from modification. Resource requests, such as access to a client descriptor, are intercepted and authorized against the object-specific operations access rights [9, 13]. For example, object-specific operations are permitted to read the requesting client's description and the requested object descriptor. If multiple objects share the same putget operation, they are all mapped into the same address space. Address spaces are a relatively lightweight resource, see Section 3.2. Custom putget operations can be multithreaded to execute multiple requests concurrently.

The hit-server also processes miss-server operations, add and remove, by which miss-servers can add or remove objects (specified by name and version) from the object cache, respectively. An add enables the miss-server to set the initial values for the object's attributes.