: This figure describes the design space for providing
transparent access to scalable network services. Transparency
mechanisms can be implemented in a number of places, including the
client, network, network routers, or at the service site.
Existing architectures include DNS Aliasing [Katz et al. 1994][Brisco 1995], HTTP redirect [Berners-Lee 1995], Magic Routers [Anderson et al. 1996], fail-safe TCP [Goldstein \& Dale 1995], and Active Networks [Wetherall \& Tennenhouse 1995]. Figure 1 describes how Smart Clients fits in the space of existing solutions. We will describe each of the existing solutions in turn leading to a description of the Smart Client architecture.
A number of Web servers use Domain Name Server (DNS) aliasing to distribute load across a number of machines cooperating to provide a service. A single logical hostname for the service is mapped onto multiple IP addresses, representing each of the physical machines comprising the service. When a client resolves a hostname, alternative IP addresses are provided in a round-robin fashion. DNS aliasing has been demonstrated to show relatively good load balancing, however the approach also has a number of disadvantages. First, random load balancing will not work as well for requests demonstrating wide variance in processing time. Second, DNS aliasing cannot account for geographic load balancing since DNS does not possess knowledge of client location/server capabilities.
On a client request, HTTP redirect allows a server to instruct the client to send the request to another location instead of returning the requested data. Thus, a server machine can perform load balancing among a number of slave machines. However, this approach has a number of limitations: latency to the client is doubled for small requests, a single point of failure is still present (if the machine serving redirects is unavailable, the entire service appears unavailable), and servers can still be overloaded attempting to serve redirects. Further, this mechanism is currently only available for HTTP; it does not work with legacy services nor does it optimize wide-area access.
The Magic Router provides transparent access by placing a modified router on a separate subnet from machines implementing a service. The Magic Router inspects and possibly modifies all IP packets before routing the packets to their destination. Thus, it can perform load balancing and fault transparency by mapping a logical IP address to multiple server machines. If a packet is destined for the designated service IP address, the Magic Router can dynamically modify the packet to be sent to an alternative host. Unresolved questions with Magic Routers include how much load can be handled by the router machine before the dynamic redirection of the packets becomes the bottleneck (since it must process every packet destined for a particular subnet). Magic Routers also require a special network topology which may not be feasible in all situations. Finally, the Magic Router is not aware of the load metrics relevant to individual services, i.e. it would have to perform remappings based on a generic notion of load such as CPU utilization.
Fail-safe TCP replicates TCP state across two independent machines. On a server failure, the peer machine can transparently take over for the failed machine. In this fashion, fail-safe TCP provides fault transparency. However, it requires a dedicated backup machine to mirror the primary server, and it does not address the problem of the front-end becoming a bottleneck. Finally, both fail-safe TCP and Magic Routers are relatively heavy-weight solutions requiring extra hardware.
Proposals for Active Networks allow for computation to take place in network routers as packets are routed to their destination. This approach could potentially provide fault transparency and load balancing functionality inside of the routers. We believe Active Networks, if widely deployed, can provide a mechanism for implementing Smart Client functionality.
All of the above solutions provide a level of transparent access to network services with respect to load balancing and fault transparency. However, they are all limited by the fact that they are divorced from the characteristics and implementations of individual services. We observe that the greatest functionality and flexibility can often be provided by adding service-specific customization to the client, rather than service-independent functionality on the server.
