Related Work Check out the new USENIX Web site.



next up previous
Next: Conclusions Up: Using Smart Clients to Previous: Summary

Related Work

 

The problem of transparently providing fault transparency and load balancing to network services has been addressed previously in a number of contexts. File systems have used server-side replication of volumes and servers to provide fault transparency in systems such as Deceit [Marzullo et al. 1990], AFS [Howard et al. 1988], and HA-NFS [Bhide et al. 1991]. More recently, systems such as xFS [Anderson et al. 1995b] and Petal [Lee \& Thekkath 1996] use client-side techniques to improve overall file system performance. Many distributed clusters perform load balancing on the level of jobs (interactive or otherwise) submitted to the system [Zhou et al. 1992][Douglis \& Ousterhout 1991][Bricker et al. 1991][Nichols 1987]. Once again, all these systems implement server-side solutions for load balancing and require client intervention to spread jobs among cluster machines.

Perhaps most closely related to Smart Clients are Transaction Processing monitors [Gray \& Reuter 1993] (TP monitors). TP monitors provide functionality similar to Smart Clients for access to databases. The TP monitor functions as the director for transactions to resource managers, accounting for load on machines, the RPC program number, and any affinity between client and server. Resource managers are usually SQL databases, but can be any server that supports transactions. TP monitors differ from Smart Clients in that they deal exclusively with transactional RPCs as the communication mechanism to the servers. TP monitors are also more closely coupled with the server nodes since they are responsible for starting new server processes.

The Smart Client director can be tailored to each service, while the TP monitor is more of a general purpose director. Smart Clients also provide a bootstrapping mechanism to remove the single point of failure associated with downloading the necessary routing software. In addition, the Smart Client code is significantly more lightweight than the TP monitor which often includes many of the features of traditional operating systems: process management/creation, authentication, and linking resource manager object code with the Transaction Processing operating system (TPOS). This lightweight nature enables Smart Clients to be downloaded into existing Web browsers to customize existing Internet services.

Also related to our systems are ISIS [Birman 1993] and gossip architectures [Ladin et al. 1992] which provide a substrate for developing distributed applications. ISIS provides reliable group communication to support many of the applications we envision. Gossip architectures use front-ends analogous to Smart Clients to access replicated servers which are kept consistent through lazy updates. Both systems are orthogonal to our work in many respects and still use server-side techniques for much of their functionality.



next up previous
Next: Conclusions Up: Using Smart Clients to Previous: Summary



Amin Vahdat
Mon Nov 18 15:34:35 PST 1996