Amoeba

• 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.
• Communication:
  • 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.
• Filesystem:
  • Hierarchical directory structure. Capabilities for flexible access control.
  • 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 filesystems.
• Process management:
  • More or less standard stuff. Shared memory, user-level VM, sharing, threads, etc.
  • Capabilities needed to manipulate memory, threads, exceptions, etc.
  • Minimize state of system calls, avoid blocking in kernel. Mimize process state.
  • 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.
• Protection:
  • 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 (?).