- Amoeba: a distributed system highly optimized for performance and not
hamstrung by backwards-compability.
- Motivation: processors getting really cheap, have large processor pool, a
few workstations for user interaction and specialized servers for dedicated
services, local clusters connected by WANs. Throw away existing OS
implementations and start from scratch: mini-kernel + user-level servers, Unix
emulation for existing software.
- Overview: objects, RPC, threads. Optimize like mad.
- Primitives: server does get_request (like Unix ``accept''); client does
do_operation on an object, causing a synchronous RPC; server does work and
then does send_reply, completing the RPC.
- Object-oriented sugar. Transport protocol highly optimized for fast RPC
on a LAN.
- Addressing: uses port number, an opaque 48 bit quantity that uniquely
identifies the server. Ports don't contain any information to help locate
where the server is running; broadcast to find the location of the server.
Cache port->host lookups. For many small Amoeba clusters connected by a
WAN, server does broadcast to all clusters at bind time, each cluster has a
proxy portmapper, and clients do broadcast only to their local cluster to
find port->host lookup.
- Performance: max RPC bandwidth is about 680 KB/sec, which is pretty
close to max Ethernet speed on standard 10 Mb/sec Ethernets; 1.4 msec
latency minimum on tiny packets.
- Hierarchical directory structure. Capabilities for flexible access
- Bullet server: super-high-speed file server. Supports only create, read,
delete; entire file must be specified at creation time, and thereafter is
immutable. Entire file is stored contiguously on disk. Super-high-speed
because nearly all accesses hit in the huge cache and never need to touch
disk; RPC the bottleneck, not cache or disk.
- Some atomicity sugar.
- Reliability and availability through replication.
- Some security sugar: encrypted directories, with decryption key
specified only in capability, so server can't read the directory until
someone gives it a legitimate capability for it. ``forward secrecy'' for
- Process management:
- More or less standard stuff. Shared memory, user-level VM, sharing,
- Capabilities needed to manipulate memory, threads, exceptions, etc.
- Minimize state of system calls, avoid blocking in kernel. Mimize process
- Handlers for exception processing, debugging, migration.
- Unix emulation: syscall emulation, session server. Ported X, 150 little
utilities. Claim that incompability is a feature, not a bug.
- Access control: standard capabilities, implemented with crypto.
- Network security: two levels of user authentication, must know port
number to access the server (address-based authentication), and servers may
optionally require capabilities for fine-grained access control. Preventing
server spoofing: all folks must access the wire through trusted hardware,
which hashes port numbers to bind the server-location-advertising step with
the get_request. Can use similar hashing scheme to link a client-issued
do_operation with subsequent send_reply (?) and similar hashing to
authenticate the client's identity to the server (?).