S.J. Mullender, G. van Rossum, A.S. Tanenbaum, R. van Renesse, H. van Staveren
Amoeba: A Distributed Operating System for the 1990s
IEEE Computer 23(5):44-53 (May 1990)
---------------------------------------------------------------------------

Everything in Amoeba is an object, whose methods are invoked over RPC
(location transparent). Objects are managed by processes and named by
user-space capabilities. A capability identifies the service port,
object ID, rights, and a cryptochecksum.

The model:
  - pool of processors (tens-hundreds per user)
  - workstations for running the interactive processes
  - specialized servers
  - gateway to the WAN

Argument for centralized processor pool: incremental growth, fault
tolerance, high-MIPS availability for brief period of time

File system is split into two components:

  1. bullet service (fast way to store immutable files contiguously on
     disk, because all data is specified at creation time)
  2. regular service

  - directory service maps symbolic names to capabilities and provides
    features such as replication and atomicity; a directory is a
    (n+1)-column table, with ASCII names in the first column and
    capabilities in the other, with access to each column being
    controlled by the capability with which you access the directory
  - a capability to a directory becomes a capability for other
    capabilities
  - directory is single point of failure, so Amoeba replicates it
  - directory can be encrypted, for safety (key is in capability)

Communication (uses RPC):
  - 3 basic syscalls: do_operation, get_request, send_reply
  - When srv ready to serve a request, it does a get_request; this is
    registered by the local kernel. When client does a do_operation,
    its kernel broadcasts a query for a server serving that port;
    kernels that have registered a corresponding get_request
    respond. These service mappings can also be cached or be
    well-known.
  - in the WAN, services will use forwarding agents in their target
    domains who will pretend to be the servers themselves

Security:
  - 2 levels of "protection": you must know the port and own a
    capability for the requested service
  - For each service, have 2 ports P and G, where P=F(G) (F-box is
    some sort of secure hashing device). G is secret, P is public, and
    you cannot get G from P. A server must do get_request(G) behind
    the F-box in order for it to listen on P (this protects against
    server impersonation). Clients authenticity is ensured by them
    advertising R=F(Q) as a reply port, but in order to listen on R
    they must do a listen on Q behind the F-box.

Processes:
  - see layout of process descriptor on page 51
  - processes can have multiple threads of control, have a segmented
    VA space, and can be remotely created, destroyed, checkpointed,
    migrated, or debugged
  - processes have only 2 states: running or stunned (by the outside
    world, or an uncaught exception)


Issues/questions:

1. If we disregard the execution of interactive processes on
   workstations, how far is the "centralized process pool" model from
   the mainframe model? Does it give us more sharing w/o migration?

2. "the gateway protects local machines from the idiosyncrasies of the
   WAN" -- How smart does a stateless gateway/proxy have to be to do a
   good job at that in the context of an operating system?

3. What would it take to allow services (ports) be multi-homed?

4. How useful are the atomic "mapping updates" when we're dealing with
   immutable objects?

5. When Amoeba processes/threads wait on condition variables, do they
   get stunned? Whether yes or no, does it make sense? (basically, is
   the lack of a "BLOCKED" state reasonable?)