In this paper we have identified a number of problems with scaling of very-large services. We described how many of these problems can be eliminated with appropriate network support. In particular, the ability to dynamically install replicas of the transport service access points in strategically placed locations, for example ``near'' large client populations, greatly increases the capability of the network to balance the load on the servers and to pro-actively diffuse flash crowds to a service. We have implemented the concept of TSAP replication in HYDRANET, an extension to the BSD process management and IP stack software, which allows to dynamically install agent programs on host servers and have redirector routers load balance the servers by appropriately directing requests to either the origin host or to locations of replicas.
The versatility of replicating TSAPs extends far beyond what we described in Section 5. For example, transparent replication of services is an alternative to the use of multicast approaches for realizing fault-tolerant servers. In the context of CORBA, for example, current efforts to provide reliable ORB technology (e.g. [16]) rely mostly on multicast capabilities at protocol level, and typically require clients to use these capabilities as well. HYDRANET would allow to replicate ORBs over several host servers. When a particular ORB becomes inaccessible (because of network partitioning, congestion, or host failure,) we rely on the reconfiguration capability of routers and redirectors to appropriately redirect requests to the remaining replicas of the ORB.
Similarly, network support similar to HYDRANET would simplify the transparent migration of services across platforms. A migrating service can be installed on a host server, and the origin host can be transparently decommisioned.
A number of issues need to be addressed further. First of all, we need to find ways to guarantee safe execution to replicas. We envision host servers to be managed by a variety of operators: ISPs, network services, or third-party operators (``service hosting for hire'', similarly to the WebOS's ``Rent-A-Server'' concept [25]). Host servers will therefore often be outside the control of the entity controlling the origin host, but host services from potentially large numbers of different sources. Mechanisms must be in place that enforce safe coexistence of multiple third-party processes on host servers. We plan to set up a transparent run-time environment that provides a replicated server a ``sandbox'', the ``size'' of which is negotiated when the replica is installed.
The fact that programs run ``under your name'' on multiple hosts across the Internet poses serious security risks. Appropriate mechanisms must be in place in the host servers (e.g. digital signatures of downloaded server replica code) and redirectors (e.g. authentication of host servers) to prevent unauthorized execution of replica code under a wrong identity.
%