Back to index
Using Smart Clients to Build Scalable
Chad Yoshikawa, Brent Chun, Paul Eastham, Amin Vahdat, Tom
Anderson, David Culler, UC Berkeley
Realize scalability through managed replication of servers, either
static or dynamic, along with service-specific client support code to
locate and talk to
an appropriate replica, fail over when that replica goes down, etc. (as
opposed to "generic" support in servers for scalability)
- Philosophy/assumption: it is simpler to upgrade all clients than
all servers, so we should leverage that in deciding where to put
support for scalability.
- Services accessed by Smart Clients assumed to be provided by a
(dynamic) set of peer servers; choice of which one should account
for geography/network topology, load balancing, etc.
- "Director" applet (servicelet?) is the single client-resident
service interface: "Perform this action on some server node".
- Director applet keeps its peer list for each service up-to-date
via an application-specific mechanism.
- Bootstrap: modified jfox browser to support "service://"
name space; services looked up at well-known search engines to
get a service certificate which binds to the client
interface and director applets and gives initial hint as to
service group members; Director may contact one of the members to
validate the list.
- Existing applet examples: telnet front-end to NOW (load
balancing, currently no failover); FTP mirror client; chat, using
an append-only WebFS file, with multiple WebFS servers mirroring
the file and multicasting updates every 300ms. (But see below)
- Seems like the mechanism for keeping server lists up to date
should not necessarily be application-specific; should have at
least some support for making it easier (e.g. choice of polling,
multicast update, or lazy invalidation). Because of this, the
"fault tolerance" claim is suspect; how exactly is FT provided?
- Chat app: with all servers multicasting file updates every 300ms,
is this really scalable? There are no ordering semantics, except
those you're likely to get from such frequent updates, though
authors acknowledge that any well-known ordering scheme
(e.g. ISIS) could be used.
- Authors claim that "entrenched" URL naming scheme is difficult to
modify so we should try to be compatible with it; yet they extend
the naming scheme themselves to support other applications (chat,
- How easy is it, really, to upgrade clients? Assumes users are
willing to install upgrades on demand, willing to run extra code
in their client, and that client software is largely uniform. Not
clear how long these conditions will persist. Should be done in
a proxy instead :)
Back to index