1 INTRODUCTION

Operating system was originally developed to provide a set of

common systems services, such as I/O, communication and persistent
storage, to simplify application programming. With the advent of
multiprogramming, this charter expanded to include abstracting shared
resources so that they were as easy to use (and sometimes easier) as
dedicated physical resources. he introduction of local area networ!s in "#$s
expanded this role even further. % goal of networ! operating systems such as
&ocus, 'ach, (prite and %moeba was to ma!e remote resources over the
&%) as easy to use as local resources, in the process simplifying the
development of distributed applications.
With analogy to these systems, argues that it is time to provide a
common set of services for wide area applications, in effect to ma!e wide
area resources as easy to use as those on a &%). he past few years has seen
a dramatic increase in the number and variety of services that are available
over the internet, beyond simple documents to a wide variety of on*line
services, such as search engines, real*time news, weather forecasts,
interactive games and chat room, airplane reservations and tic!eting, to
name +ust a few.
oday, although the World Wide Web has made geographically
distributed read*only data easy to use, geographically distributed computing
resources are not. he result is that wide area applications that re,uire access
to remote -./ cycle, memory, or dis! must be programmed in an ad*hoc
and application*specific manner. 0or example, many popular services, such
as 1igital$s %lta 2ista or )etscape$s download page, are geographically
replicated to improve bandwidth, reduce latency, and improve availability*
no single connection onto the Internet can support tens of millions of users.
his situation will only get worse3 it is currently predicted that the number
of Internet users will increase by an order of magnitude to over 4## million
in less than 5 years.
o address these problems, we have built WebO(, a framewor! for
supporting applications that are geographically distributed, highly available,
incrementally scalable, and dynamically reconfiguring. WebO( includes
mechanisms for resource discovery, a global namespace, remote process
execution, resource management, authentication and security .he WebO(
used to demonstrate the synergy of these services in simplifying the
development of wide area distributed applications and in providing more
efficient global resource utili6ation.
he WebO( framewor! enables a new paradigm for Internet services.
Instead of being fixed to a single location, services can dynamically push
parts of their responsibilities out onto Internet computing resources, and
even all the way to the client.
Characteristics
In addition to demonstrating the synergy of a common framewor! for
wide area distributed applications, made a number of specific contributions.
0irst, demonstrated and extensible mechanism for running service*
specific functionality on client machines and show that this allows for more
flexible implementation of name resolution, load balancing, and fault
tolerance.
(econd, provided a file system abstraction that combines persistent
storage with efficient wide*area communication pattern3 demonstrated that
this simplifies the implementation of a number of wide area applications.
)ext, presented a methodology for coherently caching program results
through the file system, speeding the performance of applications which
must repeatedly execute programs with common inputs. 0inally,
demonstrated how 7ent*%*(erver, an application developed in our
framewor!, both improves system performance and more efficiently utili6es
system resources for Web server access.
2 WebOS Overview
In this section, we provide a brief overview of the ma+or WebO(
components3 together, they provide the wide area analogue to local area
operating system services, to ma!e using geographically remote resources
easier to use. 8ach of these components is operational in our current
prototype.
7esource 1iscovery9 'any wide area services are geographically
distributed. o provide the best overall system performance, a client
application must be able to dynamically locate the server able to deliver the
high ,uality of service. In WebO(, resource discovery includes mapping a
service name to multiple servers, an algorithm for balancing load among
available servers, and maintaining enough state to perform fail*over if a
server becomes unavailable. hese operations are performed through (mart
-lients, which flexibly extended service*specific functionality to the client
machine.
Wide %rea 0ile (ystem9 o (upport replication and wide*scale
sharing, WebO( provides a cache coherent wide area file system. WebO(
extends to wide area applications running in a secure :. name space the
same interface, caching, and performance of existing distributed file
systems. In addition, we demonstrate the benefit of integrating the file
system with application*controlled efficient wide area communication.
(ecurity and %uthentication9 o support applications operating across
organi6ational boundaries, WebO( defines a mode of trust providing both
security guarantees and an interface for authenticating the identity of
principals. % !ey enabling feature is fine*grained control of capabilities
provided to remote processes executing on behalf of principals.
.rocess -ontrol9 In WebO(, executing a process on a remote node
should be as simple as the corresponding local operation. he underlying
system is responsible for authenticating the identity of the re,uester and
determining if the proper access rights are held. .recautions must be ta!en to
ensure that the process does not violate local system integrity and that it
does not consume more resources than allocated to it by local system
administrators.
%s an explicit design choice, we leverage as much functionality as
possible from existing low level services. 0or example, for compatibility
with existing applications, we adopt I. address and /7&$s for the global
name space. -. is used to provide reliable communication, while ((& is
used for lin! level security.
3. Resource Discovery
In this section, we discuss how WebO( clients locate representatives
of geographically distributed and dynamically reconfiguring services, while
providing load balancing and end*to*end high availability.
3.1 Current Aroaches
o address increasing demand, some popular services such as the %lta
2ista search engine ;1ig 4<<5= or the )etscape download page ;)et 4<<>=
are geographically distributed by being replicated manually by the service
provider. &oad balancing across the wide area is achieved by instructing
users to access a particular ?mirror site@ based on their location. o
distribute load across servers, techni,ues such as :. redirect or 1)(
%liasing can be used to send user re,uests to individual machines. With
:. redirect, a front*end machine redirects the client to resend the re,uest
to an available wor!er machine. his approach has the disadvantage of
either adding a round trip message latency to each re,uest or of binding the
client to a single server for the duration of a session. 0urther, the front*end
machine serving redirects is both a single point of failure and a central
bottlenec! for very popular services.
1)( %liasing allows the 1omain )ame (ervice to map a single
hostname (/7&) to multiple I. addresses in a round robin fashion. hus,
1)( aliasing does not suffer from the added latency and central bottlenec!s
associated with :. redirect. :owever, currently load balancing with 1)(
aliasing is restricted to round*robin, ma!ing it difficult to use service*
specific !nowledge such as load information. 0urther, because clients cache
hostname to I. address mappings, a single server can become overloaded
with multiple re,uests while other servers remain relatively idle.
3.2 S!art C"ients
In WebO(, we address the shortcomings of existing solutions for
resource discovery through (mart -lients. (mart -lients enable extensions
of server functionality to be dynamically loaded onto the client machine.
Aava$s portability and availability in all ma+or Internet browsers allow us to
distribute these extensions as Aava applets. We believe that performing
naming, load balancing, and fail over from the perspective of the client has a
number of fundamental advantages over server*side implementations. We
demonstrate these advantages by using our (mart -lients prototype to
implement scalable access to services such as 0., chat, and the 7ent*%*
(erver application described in (ection B.
Figure 1: Two cooperating threads make up the Smart
Client architecture. The GUI thread presents the service
interface and passes user reuests to the !irector
Thread. The !irector is responsi"le for picking a service
provider likel# to provide "est service to the user.
The decision is made in a service$specific manner. In
this case% the nearest mirror site is chosen.
he (mart -lient architecture is summari6ed in 0igure 4. % typical
applet$s code is composed of two cooperating threads9 a customi6able
graphical interface thread implementing the user$s view of the service and a
director thread responsible for performing load balancing among service
representatives and maintaining the necessary state to transparently mas!
individual failures. Coth the interface and director threads are extensible in a
service*specific manner.
3.3 #ootstrain$ A"et Retrieva"
While the (mart -lient architecture provides a portable mechanism
for fault tolerant and load balanced access to Web services, bootstrapping
(mart -lient startup remains to be described. )aively, services would be
named through /7&$s with the applet downloaded each time the service is to
be accessed. his would imply a central bottlenec!, a single point of failure,
and effectively doubling latency for small re,uests.
Figure &: 'ootstrapping applet retrieval in Smart
Clients. ( new service name space is introduced. In step
1% a name is translated into a certificate reuest from
highl#$availa"le search engines in step &. The certificate
contains hints as to initial service group mem"ership.
The Smart Client applet is retrieved from one of
these sites in step ). 'oth the certificate and applet are
cached to disk to avoid future "ootstrapping.
0igure D summari6es our approach to addressing these issues. % meta*
applet runs in a Aava enabled browser and is responsible for bootstrapping
accessing to Web services. % new service namespace is introduced, allowing
users to ma!e re,uests of the form service9 ///7&3 we leverage the /7&
namespace to simplify integration with existing browsers. he meta*applet
translates these names into re,uests to a well*!nown and highly available
Internet name service to fetch a service certificate E the list of servers
capable of providing the service, along with individual server characteristics.
-urrently, we use %lta 2ista to perform this operation3 however we plan to
switch to a more lightweight techni,ue, such as 1)(. he service$s (mart
-lient applet is downloaded from one of these sites and operation proceeds
normally described in section F.D. he service certificate, the (mart -lient
applet, and any service state are cached to dis! (with timeouts) by the meta*
applet to avoid bootstrapping on subse,uent accesses.
%. Security an& Authentication
%pplications operating across the wide area are such susceptible to a
variety of potential attac!s by sophisticated adversaries. 0or users to trust
their sensitive computations to WebO(, a well*defined and easily validated
model of trust must be defined and implemented. he goal of our
implementation is to ma!e issues of security as transparent as possible for
common operations while still allowing for arbitrary levels of paranoia for
programs that are re,uired. In this section, we describe such a model and
show how it is used for secure, authenticated access to global resources.
WebO( provides security at number of levels. 0irst, two principals
communicating at the lin! layer believe one another$s identity and trust that
the data cannot be compromised by a third party. )ext, principals are able to
have fine*grained control over which capabilities are transferred to remote
WebO( processes running on their behalf. 0inally, WebO( provides an
interface for registering users and for specifying access rights to individual
system resources. he WebO( security model is summari6ed in figure F.
Figure ): *e"+S Securit# ,odel. First% users transfer
some portion of their access rights to a *e"+S server.
*hen attempting to access a remote resource% *e"+S
servers communicate using SS- .step &/. Finall#% the remote
server checks if the proper credentials are held in
local (C-0s.
%.1 'in( 'ayer
WebO( relies upon a hierarchy of certification authorities (-%$s).
hese authorities are responsible for producing G.5#< certificates ;--I
4<""= mapping principals to their public !eys. hese certificates are
generated by the -% and contain the following information9 the identity of
the -%, the name of the principal, its public !ey, the period during which the
mapping is valid, and a digital signature of the entire certificate by the -%.
Cy using these certificates and by placing trust in the -%$s, we are able to
guarantee that any data successfully decrypted by a given public !ey was in
fact generated by the associated principal.
We use the (ecure (oc!et &ayer (((&) to authenticate the identity of
communicating servers to one another. ((& uses the public !eys from a
WebO( server$s G.5#< certificate to establish an 7-> symmetric !ey for
session communication, and an '15 hash of chun!s of the byte stream to
allow the principals to determine if an adversary is attempting to patch*their
communication. (ymmetric !eys are used for encryption because of their
computational simplicity relative to public !ey cryptography. WebO(
manages a cache of available connections to remote servers to avoid the
overhead of establishing a secure connection for each login operation.
%.2 Trans)er o) Ri$hts
.rincipals register with WebO( and are able to control the transfer of
portions of their rights to servers acting on their behalf. 0or example, a
principal might register with a remote WebO( compute engine, transferring
to the server the right to access a particular sub*directory containing the
relevant data files. he server would be able to access the files necessary to
carry out any computation on the principal$s behalf but would be able to
accessing the principal$s private financial information located in another
directory. % WebO( server can recursively transfer rights to a second server
by signing the appropriate transfer certificate, unless a transfer right is not
granted by the user.
In WebO(, principals transfer rights by creating a transfer certificate
that the resources in ,uestion (for example, all files in a particular Web0(
sub*directory), the identity of the target WebO( server, and a time period
during which the transfer certificate is valid. his transfer certificate is
attached to the principal$s G.5#< certificate (identifying the principal) and an
'15 hash of both the G.5#< and transfer certificates encrypted in the user$s
private !ey. his encrypted hash certifies that the user actually created the
transfer certificate. /sing this scheme, a WebO( server is able to prove to
other sites that it is authori6ed to act on the principal$s behalf when
accessing the resources specified in the transfer certificate. )ote that the
program generating the transfer certificate re,uires the principal$s private
!ey3 however, this registration program is distributed as source and runs on a
principal$s local machine.
%.3 Seci)yin$ an& *a"i&atin$ Ri$hts
WebO( access rights are specified through %ccess -ontrol &ists
(%-&$s). hese access rights specify the list of principals which possess
read, write, modify, and execute permission on a given resource. When a
principal attempts to access a resource, WebO( sends the re,uest with the
proper transfer certificate to the site that owns the resource. he destination
site ta!es the following steps in validating access to the resource in ,uestion9
(i) it chec!s for a valid timestamp in the transfer certificate, (ii) it determines
if the re,uesting WebO( server has the proper authority to act on the
principal$s behalf for the re,uested resource, as described in the transfer
certificate, and (iii) it chec!s its local %-&$s to determine whether the
principal has the proper access permissions for the re,uested resource.
We chose to use %-&$s because of their relative conceptual simplicity
both form the principal$s and implementer$s point of view. % capability
based system is more manageable in a global context where the access rights
of potentially millions of users must be monitored. :owever, capabilities
present complications for rights revocation and transfer. o partially address
the issues of scale associated with %-&$s, WebO( allows for global group
access rights and implements an efficient storage/loo!up mechanism for its
%-&$s. Cased on the assumption that many resources will have identical
groups of principals associated with them, Web0( resources point to uni,ue
?buc!ets@ containing the appropriate rights specification. &oo!ups are
executed by performing a hash of the re,uesting principal into the buc!ets.
+. WebOS A"ications
his section provides an overview of four applications built using the
WebO( framewor!. he applications demonstrate that WebO( services
enable and simplify their implementation. he first two applications have
been completed, while the last two are under development.
+.1 Internet Chat
Internet chat allows for individuals to enter and leave chat rooms to
converse with others co*located in the same logical room. In our
implementation, chat rooms are modeled as Web0( files accessed by (mart
-lients. he file system interface is well*matched to chat semantics in a
number of ways9 (i) % simple file append abstracts the re,uired networ!
communication necessary to send messages, (ii) the chat file provides a
persistent log of chat activity, and (iii) access control lists allow for private
and secure (through Web0( encryption) chat rooms. 0or scalability, we
allow multiple Web0( servers to handle client re,uests for a single file
(room). 8ach Web0( server accumulates updates, and periodically
propagates the updates to other servers in the Web0( group, who in turn
transmit the updates to local clients. (mart -lients choose the least loaded
Web0( server for load balancing and connect to alternative servers on host
failure or networ! partition for fault transparency.
+.2 Re!ote Co!ute ,n$ine
(ites with uni,ue computing resources, such as supercomputer
centers, often wish to ma!e their resources available over the Internet. /sing
WebO(, we allow remote programs to be invo!ed in the same way as local
programs and can allow access to the same files as local programs. WebO(
functionality is used to address a number of issues associated with such
access9 the identity of re,uesting agents is authenticated, programs are
provided secure access to private files on both local and remote systems, and
programs run in a restricted virtual machine isolated from other programs to
protect the local system from malicious users. %t our site, WebO( provides
compute access to research cluster 4## machines. 7esource allocation within
the virtual machine allows external users to ta!e advantage of the aggregate
computing resources, while ensuring system developers have the re,uisite
priority.
+.3 Wi&e Area Cooerative Cache
We are using WebO( to build a geographically distributed Web
cooperative cache to both validate our design and to provide an immediate
benefit to the Internet by doing more intelligent caching of Web content.
8xisting proposals for hierarchical caching of the Web suffer from an
inability to dramatically grow the cache si6e and processing power at each
level of the hierarchy. With cooperative caching among peer servers, the
aggregate capacity grows dramatically with the distance from the client.
hus, while caches above the first level in existing hierarchical designs have
very low hit rates and simply increase the latency to end clients, a
cooperative cache is more li!ely to successfully retrieve a caches copy from
a peer. We plan to explore tradeoffs associated with maintaining directories
of peer cache contents, hints, or using simple I. multicasts or broadcasts.
WebO( simplifies the implementation of the cooperative cache in a
number of ways. 0irst, (mart -lients are used to determine the appropriate
proxy cache to contact. Web0( is used to transport cache files among the
proxies and to securely share any necessary (private) state among the
proxies. 0inally, the authentication model allows proxies to validate their
identities both to one another and to the client.
Internet Weather
% number of sites are currently attempting to provide regular updates
of congestion, latency, and partitions in the Internet. (uch information is
invaluable for services ma!ing placement and load networ! measurements
from a centrali6ed site, ma!ing it difficult to measure networ! characteristics
between two arbitrary sites. We are addressing this limitation by using the
WebO( framewor! to generate more comprehensive snapshots of Internet
conditions. In our implementation, a centrali6ed server provides (mart
-lient applets for whose wishing to view the current Internet weather. In
exchange for the weather report, the user implicitly agrees to allow the
applet to execute trace route to a subset of server*determined sites and to
transmit the result bac! to the server. /sing these results from multiple sites,
the service is able to construct fairly comprehensive snapshots of Internet
weather.
-. Rent.A.Server
his section describes the design, implementation, and performance of
7ent*%*(erver, an application demonstrating the power of using a unified
system interface to wide area resources and of moving a service out across
the Internet.
Figure 1: 2ent$($Server (rchitecture. 3TT4 servers periodicall# send load
information to a load daemon. In response to an update% the load daemon transmits the
state of all servers. In turn% the 3TT4 servers transmit this state information as part of
the 3TT4 header to Smart Clients. The Smart Clients can use this information to
determine which server to contact for its ne5t reuest. *hen the load daemon notices
that the service as a whole is "ecoming overloaded% it contacts the resource manager
on an availa"le surrogate to create another server replica. *e"FS is used to securel#
transmit an# e5ecuta"les or data files needed to start the server.
-.1 /otivation
7ent*%*(erver allows sites to deal with pea! loads that are much
higher than their average loads by ?renting@ hardware to deal with pea!s.
0or example, the Internal 7evenue (ervice site (http9//www.irs.ustreas.gov)
is overwhelmed by re,uests around %pril 45, but providing the computation
power and networ! bandwidth necessary to handle pea! levels of demand
year round is a waste of resources. he benefits for 7ent*%*(erver can be
summari6ed as follows9
Heographic &ocality9 In addition to distributing load, 7ent*%*
(erver improves performance by increasing locality. 7ather than satisfying
re,uests from centrali6ed site, a system can distribute its re,uests across
geographically distributed servers, each of which satisfies nearby clients.
1ynamic 7econfiguration9 he location and number of sites
representing a service can be determined dynamically response to client
access patterns. 7ent*%*(ervers can be spawned to locations ?near@ current
spi!es in client demand, and torn down once client activity subsides.
ransport 8nd*o*8nd %vailability9 Once a service is replicated
with 7ent*%*(erver, users can transparently access whichever replica is
available, routing around both Internet and service failures.
(ecure -oherent 1ata %ccess9 o address limitations associated
with caching proxies which are unable to generate dynamic Web pages (e.g.
results cgi*bin programs) and often serve stale data, 7ent*%*(erver uses
WebO( to provide authenticated, coherent global file access to data pages,
-HI scripts, and internal server state needed by -HI scripts.
(afe 7emote 8xecution9 (urrogate sites securely execute service
programs and associated scripts (such as -HI programs) without violating
the surrogate$s system integrity.
-.2 Current Aroaches
-urrent efforts to distribute :. server load focus on either
distributing load across a fixed set of machines maintained by the owner of
the data or distributing data across ( proxy ) caches under client ( not server )
control. 'any :. server implementations achieve scalability by
replicating their data across a fixed set of servers at a single site and then
using the 1omain )ame (ervice (1)() to randomly distribute re,uests
across the servers. /nfortunately, this approach re,uires that each site
purchase enough computing power and networ! bandwidth to satisfy pea!
demand.
?'irror (ites@ are also used to improve locality and to distribute load,
but this manual approach re,uires more effort to set up the mirrors and to
maintain data consistency across the mirrors. 0urther, users must specify
which mirror to use, which is both inconvenient and unli!ely to yield a
balanced load across sites. 0inally, as with the approach of running multiple
servers at one site, mirror sites are allocated statically. he system must
always maintain enough mirrors cannot be shifted to address shifts in
geographic hotspots.
%nother approach to distributing load, caching proxies, is used to
reduce server load and to improve networ! locality. o use a proxy, groups
of clients send all of their re,uests to their proxy machine. he proxy
machine attempts to satisfy the re,uests from its local cache, sending the
re,uests to the remote server if the cache cannot supply the data. If proxies
satisfy many re,uests to the server through their caches, both server load and
networ! congestion are reduced.
Syste! Desi$n
In this subsection, we demonstrate how WebO( services simplify the
implementation of this application. he architecture of the 7ent*%*(erver is
described in 0igure E >. (mart -lients access :. services. .eriodically
(currently every tenth response), servers piggybac! service state information
to (mart -lients in the :. reply header. his state information includes a
list of all servers currently providing the service. he following information
is included for each serer9 its geographic location, an estimate of its
processing power, an estimate of current load, and a time period during
which the server is guaranteed to be active. he last field is determined with
short term leases that are periodically renewed if high demand persists. he
short leases prevent clients with stale state information from trying to access
inactive surrogates (or worse, surrogates acting on behalf of a different
service).
8ach 7ent*%*(erver maintains information about client geographic
locations (location is sent by (mart -lients as part of :. re,uest) and its
own load information in the form of re,uests per second and bytes
transmitted per second. 8ach 7ent*%*(erver periodically transmits this state
information to a centrali6ed load daemon. 0or software engineering reasons,
the load daemon is currently a separate process3 however its functionality
could be rolled into an elected member of the server group. he load
daemon is responsible for determining the need to spawn or to tear down
7ent*%*(ervers based on current load information and client access patterns.
It also transmits server group state (e.g. membership and load information)
to each member of the server group, which is in turn piggybac!ed by the
servers to (mart -lients as part of :. replies, as described above.
Once the load daemon determines the need to spawn an additional
server, it first determines a location for the new 7ent*%*(erver. he new
server should be located close to any hotspots in client access patterns to
both conserve bandwidth and to minimi6e client latency (this policy has not
yet been implemented). Once the target machine is selected, the load
daemon established an ((& channel with the surrogate$s resource manager.
he load daemon then ads the surrogate to the necessary %-&$s allowing it
access to Web0( files containing the executables (e.g. :. server) or
internal service state (e.g. -HI scripts or internal database). In addition, the
load daemon provides a signed certificate with an expiration date) granting
the surrogate the right to serve data on behalf of the service. his certificate
is transmitted to (mart -lients on demand to prevent spoofing of the service
by malicious sites.
When setup negotiation is completed, the surrogate site builds a Aanus
virtual machine to execute the necessary programs (in our case an arbitrary
:. server) to establish a service identity at the surrogate. he virtual
machine ensures that the surrogate$s system integrity is not violated by a
buggy executable or a malicious server. Coth the service executable and any
necessary service state are securely accessed and cached on demand through
Web0(. he load daemon propagates the identity of the new surrogate to
other members of the server group, which in turn transmit the identity and
location of the new server to (mart -lients. ear down of a surrogate is
accomplished when client demand subsides and the load daemon decides not
to renew leases with a surrogate. he load daemon removes the surrogate
from the appropriate %-&$s.
-.3 0er)or!ance
o demonstrate the power of dynamic resource recruitment available
from our approach, we measure the performance of a 7ent*%*(erver when
placed under a heavy synthetic load. Our experiments are conducted on a
cluster of (un /ltra (ervers interconnected by 4# mbps switched 8thernet.
(even /ltra (ervers are designated as surrogates available to provide :.
service on behalf of an eighth machine designated as the primary. %ll eight
server machines run WebO(, including the file system and the resource
manager responsible for process control. %nother FD machines are used to
generate gradually increasing load to the :. service. %ll machines are
running (olaris D.5.4 and %pache 4.DbB is used for the :. server.
1uring the experiment, each client machine starts 45 (mart -lients
use random load balancing to pic! from a changing list of available :.
servers. o simulate increasing load, all FD client machines do no begin
ma!ing re,uests at the same time. 7ather, clients start in four groups of eight
machines each, with the a start time of each group staggered by two minutes.
he results of our tests are summari6ed in 0igure 5. he graphs plot
average client*perceived latency in seconds as a function of elapsed time,
also in seconds. Initially, only a single :. server is available3 however,
the load daemon spawns new servers onto available surrogates as service
load increases. he thic! dar! columns corresponding to execution of new
:. servers, while the lighter thin lines correspond to the startup of a
clients starting at time #. 0or example the 7ent*%*(erver graph shows that a
third surrogate server was started at t I 4DD shortly after the second group of
eight clients start. he experiment reaches steady state at approximately
seconds after the last group of client machines start running at t I FB#
seconds. he graph is truncated at t I B## seconds. In summary, 0igure 5(a)
shows that 7ent*%*(erver is able to dynamically recruit resources in
response to increased client demands. %s clients increase server load over
time, 7ent*%*(erver is able to dynamically recruit needed surrogates to
maintain relatively steady ,uality of service, delivering "## ms average
latency.
While the number of active :. servers varies from between one
and eight, on average 5.J servers are active. o contrast the performance of
7ent*%*(erver with static server allocation, the experiment is executed with
identical parameters, with the exception that B fixed servers are allocated for
the duration. 0igure 5(b) depicts the results. Cetween t I # and t I 4D# with
relatively light client demand, static allocation outperforms 7ent*%*(erver,
delivering an average latency of approximately B## ms. :owever, it can be
argued that resources are wasted because measurements indicate that three
servers could deliver the same performance for eight clients. When all FD
clients are running between t I FB# and t I B## ms, 7ent*%*(erver$s ability
to dynamically recruit resources results in improved performance. 1uring
this time period, clients see "5# ms average latency while the statically
allocated resources become constrained, delivering <B5 ms average latency.
hus, 7ent*%*(erver outperforms static resource allocation even when the
average amount of consumed service resources stays constant.
he performance of 7ent*%*(erver demonstrates the power of
dynamically recruiting resources for wide area services. :owever, it is
e,ually important to provide a convenient interface for application
development. Our implementation of 7ent*%*(erver in WebO( consists
solely of the load daemon and additions to the %pache :. server to
transmit state information to the load daemon and to transmit aggregate
service state (in :. headers) to (mart -lients. he load daemon consists
of 4### lines of -KK code, and we added 45# lines of - code to %pache.
Ceginning with the WebO( framewor!, our prototype of 7ent*%*(erver was
operational in less than one wee!.
A&vanta$es
hese dynamically reconfiguring and geographically mobile services
provide a number of advantages, including9
(i) better end*to*end availability (services*specific extensions running in
the client mas! Internet or server failures),
(ii)better cost*performance (by dynamically moving information closer to
clients, networ! latency, congestion, and cost can all be reduced while
maintaining server control ), and
(iii) better burst behavior (by dynamically recruiting resources to handle
spi!es in demand ) .
0or example, many Internet news services were over whelmed on the
night of the last /.(. .residential election3 the framewor! would enable
those services to handle demand through dynamic replication.
1. Conc"usion
In this paper, we have demonstrated the synergy available from
exporting traditional operating system functionality to wide area
applications. Our prototype implementation, WebO(, describes one possible
organi6ation
Of these system services, in this framewor!, we ma!e the following
contributions. 0irst, we show that extending server functionality onto client
machines allows for more flexible implementation of name resolution, load
balancing, and fault tolerance. (econd, by providing a file system
abstraction combining communication and persistence, we simplify the
implementation of a number of wide area applications. )ext, we present a
methodology for coherently caching program results through the file system,
speeding the performance of applications which must repeatedly execute
programs with common inputs. 0inally, we demonstrate how 7ent*%*(erver,
an application developed in our framewor!, both improves system
performance and more efficiently utili6es system resources for Web server
access.
#ib"io$rahy
www.researchIndex.com