Back to index
Amin Vahdat (UCB), Tom Anderson (UW), Mike Dahlin (UT Austin)
Late binding of names by executing service-specific nameservers in a
controlled environment. Addresses some of the thorny naming problems
associated with replication/mirroring, transformation, alternates,
customized/cookie-ized pages, etc.
- Define a naming scheme based on a namespace
concatenated with a name. Each namespace is controlled
by a NamespaceProgram that resolves names there via an Eval() method.
- The Eval method also takes as arguments an array of
afterMethods to be called after the original resolution
completes, and a DataStream representing the result/output
state of an evaluation. This allows a pipeline/CPS-like style of
composing name evaluations (think distillation pipeline).
- This enables multi-way RPC without multiple roundtrips:
client calls NS1 which hands off to
NS2,...,NSn via the afterMethods (any intermediate
afterMethod can push more afterMethods).
- Goal: avoid having the one-thread-per-resolution
NamespaceProgram consume too many resources. Approach: a
Java thread metascheduler, but no way to monitor CPU/mem
- Goal: avoid having unrelated NP's stomp on each other.
Approach: run each in a separate meta-VM.
- Implementation: Java class hierarchy; a VM (on top of JVM) in
which AN resolvers (NamespacePrograms) run. ANVM uses
and Felten's stack inspection and secure class loader.
Addresses various name-related problems such as cooki-ized or
customized pages, transforms, alternates, etc. On the other
hand, eliminates some of the self-describing properties of
current names (hostname encapsulation, etc.)
- Besides late binding, a main feature is separation of
"canonical names" from "parameters", in the
sense that cookie-ized pages or transformed objects might
require. This is fine, but important to realize that these
problems are solved by fixing the naming scheme in general---not
necessarily by making names active.
- Security is treated as a first-order concern, but failure
semantics of the multi-way RPC/chaining are not.
- Performance is a concern for high workloads; maybe less so if
resolutions are cached (see below), rare, or expected to be done
near client with redirects going to faraway servers to do the
How about a hybrid active/passive scheme, where name resolution
can be cached as an optimization. The name resolver API could be
extended to express "consistency semantics" for
resolved names, or one of the other expiration-based consistency
schemes could be used. This would avoid the performance hit and
still allow AN's to be perfectly adequate for things like replica
selection. (Yes, you could build this starting from AN as is,
but worth asking whether the abstractions are worth providing as
a first class mechanism.)
Back to index