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:
        o 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.
        o Object-oriented sugar. Transport protocol highly optimized for
          fast RPC on a LAN.
        o 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.
        o 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:
        o Hierarchical directory structure. Capabilities for flexible access
          control.
        o 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.
        o Some atomicity sugar.
        o Reliability and availability through replication.
        o 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:
        o More or less standard stuff. Shared memory, user-level VM,
          sharing, threads, etc.
        o Capabilities needed to manipulate memory, threads, exceptions,
          etc.
        o Minimize state of system calls, avoid blocking in kernel. Mimize
          process state.
        o 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:
        o Access control: standard capabilities, implemented with crypto.
        o 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 (?).