Amoeba

A Distributed Operating System

Amoeba is a distributed operating system developed by Andrew S.

Tanenbaum and others at the Vrije University Amsterdam. The aim
of the Amoeba project was to build a timesharing system that
makes an entire network of computers appear to the user as
a single machine.

Overview
The Amoeba project's purpose was to create an operating system for computer networks that
would appear to the user as if it were a single machine. An Amoeba network consists of a
number of workstations connected to a "pool" of processors, and running a programme from
a terminal causes it to run on any of the available processors, with the operating system
providing load balancing.[4] Unlike the modern Sprite, Amoeba does not support process
migration. Additional computers, in addition to workstations and processors, function as
servers for files, directory services, and TCP/IP connections, among other things .[4]

Amoeba is an operating system based on micro kernels. It has multithreaded programmes and
a communication technique called a remote procedure call (RPC).

System Hardware Architecture

The universal distributed Client-Server-Model is implemented by Amoeba. In fact, just three
functions are required to complete the entire system: the transaction call from the client, and
the GetRequest and PuReply methods on the server side.

There are four main components to an amoeba system.

1. Workstations
2. Pool Processors
3. Specialized Servers (File server...)
4. Gateways

Some more Detail:

 Amoeba is designed as a collection of micro kernels. Thus the Amoeba system consists of many
CPU's connected over a network. Each CPU owns his own local Memory in the range from 2MB to
several 100MB. A huge number of  Processor's build the so called Processor pool. This group of
CPUs can be dynamically allocated as needed by the system and the users. Specialized servers,
called Run server, distribute processes in a fair manner to these machines.
 
 i80386 (Pentium), 68k, and SPARC are among the processor architectures supported. Only the
i80386 architecture is relevant nowadays for constructing an Amoeba system (cheap!!!).

 The third system component is specialized servers, which are machines that are used to perform
dedicated processes with exceptional resource requirements.

 Finally, there are gateways to other Amoeba systems that can only be reached via a wide area
network. We constructed a distributed Amoeba system that spanned several nations for a European
Community-sponsored project. Local machines are protected by the gateway from the quirks of
protocols that must be utilized over wide area networks.

Q:Why did we choose this architecture instead of the traditional workstation model?

Because Centralizing computing power will allow incremental expansion, fault tolerance, and the
potential for a large job to temporarily get a huge quantity of processing power as it becomes
practical to give each user 10 to 100 processors. Why not allow them to have computer servers as
well? Current systems have file servers, so why not allow them to have computer servers as well?
 System Software Architecture
The central point of the software concept for a server implementation is the Object concept. Each
object consists of 

 Data and
 Operations on this data

Amoeba is arranged as a collection of objects (basically abstract data types), each of which can
be subjected to a certain number of actions by processes. Sending a message to the object's
server allows you to conduct operations on it. Processes produce objects, which are then
maintained by the relevant server. There are numerous object classes to choose from:

 Files
 Directories
 Memory segments
 Processes
 I/O-Devices (Hard drive...)
 Terminals

Stub-procedures are used to perform operations on objects. The server returns a Capability
when an object is created. The item is addressed and protected using this capability. Below is an
example of a typical capability.

o The Port field identifies the server.

o The Object field tells which object is being referred to, since a server normally will manage
several objects.
o The Rights field specifies which operations are allowed (e.g. capability for a file may be read
only). Since capabilities are managed in user space,
o The Check field is needed to protect them cryptographically, to prevent users from
tampering with them

Memory segments are managed by the Amoeba kernel, which also supports processes
with numerous threads and handles interprocess communication. Remote process
creation, debugging, checkpointing, and migration are all possible with the process
management features, thanks to a few simple procedures detailed in a later section.
In contrast to Unix, which has a massive monolithic kernel for these services, all other
services (such as the directory service) are provided by user-level processes. We were
able to develop a flexible system without sacrificing performance by putting as much as
possible in user space.

Concessions to existing operating systems and applications were deliberately avoided in

the Amoeba architecture. However, to execute existing software on Amoeba, a Unix
emulation service was created.

Memory Management

Amoeba provides a straightforward memory management system based on segments.

At least three segments belong to each process:

 Segment of text/code
 The primary thread/process has its own stack segment.
 segmentation of data

Each subsequent thread gets its own stack segment, and the process can allocate as
many more data segments as it wants.
The underlying MMU protects all segments, including kernel segments, from page
faults.

Process Management

In Amoeba, a process is an object. Process information is stored in capabilities and a

data structure known as a process descriptor, which is used for process creation and
stunned processes in Amoeba (and process migration). The process descriptor is made
up of four parts:
 The host descriptor specifies the system requirements for the process to execute
on by defining which computer it can run on.
 The capabilities include the process capability, which every client requires, and
the handler capability, which deals with signals and process departure.
 The layout of the addess space is described by the segment component (see
below)
 The thread component describes the state of each thread in the process (see
below) as well as their state information (IP, Stack,...)

A rudimentary thread model is supported by Amoeba. A process has at least one

thread when it starts up. The number of threads changes on a regular basis.
Additional threads can be created by the process during execution. Existing
threads can also be terminated. The kernel is in charge of all threads. The benefit
of this architecture is that whenever a thread performs an RPC, the kernel can
block it and schedule another thread in the same process if one is available!

Thread synchronization is accomplished using one of three methods:

 Mutexes = A Mutex functions similarly to a binary semaphore. It can be
locked or unlocked in one of two states. When you try to lock an unlocked
mutex, it becomes locked. The phone is still ringing. When attempting to
lock a mutex that is already locked, the caller thread will be blocked until
the mutex is unlocked by another thread

 Semaphores= Counting Semaphores is the second way threads can

synchronize. These are slower than mutexes, although they are sometimes
necessary. It's impossible for a semaphore to be negative. When a thread
 tries to down a zero semaphore, it will block until another thread performs
an up operation on the semaphore.

 Signals= Asynchronous interrupts transmitted from one thread to another

in the same process are known as signals. Signals can be raised,
intercepted, or dismissed. Interrupts that aren't synchronous

Communication in Amoeba

All processes, the kernel too, communicate with a standardized RPC (Remote procedure call)
interface. There are only three functions to reach this goal:

 trans(req_header, req_buf, req_size, rep_header,rep_buf, rep_size)

 -> do a transaction to another server
 getreq( req_header, req_buf, req_size)
 -> get a client request
 putrep( rep_header, rep_buf, rep_size)
-> send a reply to the client

The first function allows a client to submit a message to a server and receive a response from
the server. The reply and request buffers are memory buffers that are general in nature (char).
The request and reply headers are simple data structures that specify the request and the
server's capabilities. On the other hand, the server calls the getreq method in an infinite loop.
The getreq method returns with the client data placed in the request buffer, if any, each time
a client sends a message to this server (defined by a server port - see capabilities for details).
The information about the client request is contained in the request header.

Because the client expects a response, the server must respond (with or without data).

Assume the new broadcast has sequence number 25, while the previous one had number 23.
When the kernel realizes it has missed number 24, it sends a point-to-point communication to
the sequencer, requesting a private retransmission of the missing message.

The sequencer retrieves and sends the missing message from its history buffer. The moment it
arrives, Kernel processes 24 and 25 receive the data and deliver it to the application software
in numerical sequence .As a result, the only effect of a misplaced communication is a (usually)
slight time delay. All application programmes are aware of this.Even if some communications
are missed, all transmissions are aired in the same order.
 File System in Amoeba
Capabilities are Amoeba's low-level naming mechanism, however they're difficult to utilize for
most people. As a result, a second level of mapping from symbolic hierarchical path names to
capabilities is supplied. A typical user has access to tens of thousands of capabilities, including
those of the user's own private objects as well as public objects like command executables,
pool processors, databases, and public files .While a user may be able to save his own private
capabilities, a system manager or project coordinator cannot expressly grant capabilities to
every user who may access a shared public object. Users require public venues where they can
learn about the capabilities of shared objects, so that when a new object is made shareable, or
when a shareable object changes, they can be informed.

Bullet Service= The bullet service is an out-of-the-ordinary file server. There are only three
main operations supported by each bullet server: read file, create file, and delete file .When a
file is created, the user typically submits all of the data at once, which results in the file being
created and a capability being returned. In most cases, the user will name the file right away
and ask the computer to save it. To enter the name capability pair in a directory, use a
directory service .All files are immutable, which means they can't be modified after they've
been created.

Atomicity =Names should always refer to consistent objects, and sets of names are useful for
dedicated transaction-processing applications (for example, banking and airline reservation
systems). However, they do not prevent the glitches that can occur when people use an
application shortly after a new version is installed, or the lost update that can occur when two
people update a file at the same time.

Security and dependability = The directory service is critical to the system because it allows
nearly every application to find the capabilities it requires. Everything else will grind to a halt if
the directory service fails. To ensure that no single site failure may bring it down, the directory
service replicates all of its internal tables over numerous discs using techniques similar to
those used in fault-tolerant database systems.

Unix Emulation of Amoeba

The system interface of Amoeba differs significantly from that of today's most popular
operating systems. We didn't want to start from scratch and build hundreds of utility
applications for Amoeba, so we quickly decided to write a Unix emulation package that would
allow most Unix utilities to function on Amoeba with little adjustments. Binary compatibility
was considered, but we decided against it for the initial emulation package because binary
compatibility is more complicated and less beneficial. (For starters, we'd have to pick a Unix
version; second, binaries are normally limited to a single system architecture, whereas sources
can be produced for any machine architecture; and third, binary emulation is almost always
slow.)Our emulation system began as a collection of Unix routines.

The X Window System has been ported  to Amoeba and supports both TCPnP and  Amoeba
RPCs, so an X client on Amoeba  can converse with an X server on Amoeba  and vice versa.

Because of Amoeba's use of objects and capabilities, we don't have to worry about object
protection while designing a service. The capacities mechanism protects you well enough on
its own. The system also has a fairly uniform and decentralized approach for object naming
and access.

Amoeba's success has been dependent on building directly on the hardware rather than
using an existing operating system. One of the main objectives was to design and create a
high-performance system, which is difficult to execute on top of another system. Only
custom-built hardware or customised microcode, as far as we can determine, can surpass
Amoeba's remote procedure calls and file system on comparable hardware.