Summary

We have described a solution to the problem of scalability and high-availability which logically migrates server functionality into the client. We will now revisit the goals set forth in Section 1 and examine how Smart Clients addresses each goal:

• Incremental Scalability - When a machine is added to or removed from a service group, the director applet supplied by the service updates its list of peer servers. The director applet discovers such modifications through a service-specific mechanism, e.g. keep-alive messages, connecting to a well-known port, or refetching the service certificate.

• Load Balancing - The director applet maintains a service-specific notion of load (such as number of processes, number of open connections, available bandwidth). Using this information, client requests are routed to the best candidate node.

• Fault Transparency - When a failure occurs, the director applet allows the client to clean up any stale state before resending the request to another server. Providing fault transparency requires service support when the request is non-idempotent. For example, in the chat application, the chat service provides atomic writes to the chat transcript.

• Wide Area Service Topology - Smart Clients does not place any restriction on topology of server machines. In fact, the director applet can choose an arbitrary site based on considerations such as proximity or predicted performance.

• Scalable Services To Legacy Servers - Existing servers that replicate a read-only database can be grouped together for access by Smart Clients. With knowledge of the group set, the director applet can load balance client requests among existing unmodified servers.

Finally, we believe that the architecture presented in this paper can simplify implementation of scalable services with respect to at least fault transparency and load balancing. The Smart Client director provides the illusion of a single, highly available server. This model substantially decreases the complexity of the client interface applet since this applet need not be concerned with maintaining the set of server nodes. In addition, because of the public interface between the client interface and director applets, each can be written once and interchanged for a number of different services.