Amoeba Distributed Operating System

What is Amoeba

Amoeba is a distributed operating system

Developed by Andrew Tannenbaum

Uses timesharing

User logs into the system as a whole, not just his local machine.

When the user runs a program, the system decides which machine (or machines) in the

system should execute it.

This decision is invisible to the user.

Amoeba is a distributed operating system. It collects a huge varity of single machines

connected over a (fast) network to one, huge computer. It was originally developed at the Vrije

Universiteit in Amsterdam by Andrew Tanenbaum and many more. Amoeba was always

designed to be used, so it was deemed essential to achieve extremely high

performance. Currently, it's the fastest distributed operating system.  

The original Amoeba sources are handled under a public license - similar the BSD license.

Amoeba builds upon a traditional micro kernel. It supports true multithreading (kernel

controlled), segment based memory management. All Amoeba components communicate with

eachother over a standardized RPC (Remote Procedure Call) interface - simple but very

powerfull. No matter if a client or server thread is running in kernel or user mode - it uses the

same RPC interface. Always. Everywhere. This leads to a very clean and simple OS design,

very well suited for beginners.  

Because Amoeba was designed from scratch with  new concepts, never seen before, it 

suffered from a lack of application programs. Therefore a POSIX-compliant UNIX emulation was

added. It makes porting UNIX programs much easier!  Now, with additional changes, a huge

varity of application programs  from the UNIX-world work under Amoeba:

X11 with applications, various compilers (gcc, ocaml, tcl/tk), bash shell, editors and many, many

more. Amoeba is ready to use!  Of course not without (little) problems.

It's still in an sligthly experimental state, but ready to use. FSD-Amoeba is intended to

use for dedicated programmers only, and not for end users!

Highlights:

A huge number of kernel extensions and changes

New hardware driver stuff:

o several new network driver

o full pci support

o new parallel and serial port support

o virtual console support

o enhanced page protection

100 Mbps Fast Ethernet support

New interrupt handling, national keyboard support, enhanced IOP server for X11

X11 Release 6.4

Bash-2.02, tcl-7.6, tk-4.0, ocaml-3.01, xv-3.10a, ghostscript 4.03 & 6.01, all GNU-

textutils, gmake, gzip...

New Setup and installation scripts, various new menu driven system administration tools

Crosscompiling environment under Linux

Fireball Documentation Project (FDP)

Andrew Toolkit for the Fireball Documentation Project

History

The history of modern computing can be divided into the following eras:

1970s: Timesharing (1 computer with many users)

1980s: Personal computing (1 computer per user)

1990s: Parallel computing (many computers per user)

80’s computers could be networked together and files could be shared between users

RPCs.

Parallel computing in the 90’s and today are used to share CPU resources among a

network of computer systems.

This concept is referred to as distributed computer systems or parallel computing

How can we exploit with the one-to-many computer system configuration?

The answer is Amoeba OS can solve this all problem.

Developed at the Vrije Universiteit Amsterdam, Netherland. Chief designer: Andrew S.

Tanenbaum; other developpers were Frans Kaashock, Sape J. Mullender, Robbert van

Renesse, Leendert van Doorn,  Kees Verstoep and many, many more.

First proto release in 1983 (V1.0), last official release 1996 (V5.3)

Supports multiple architectures: 68k, i80386, SPARC

Virtual Amoeba Machine and Features in Amoeba

The next step: a virtual machine supplying the Amoeba concepts like RPC. Either running

natively under Amoeba, or under UNIX with the AMUNIX library together with the FLIP protocol

module. The VM is derived and build from OCaML. The great advantage: Amoeba programs

written in OCaML and compiled to bytecode can run independently from the underlying OS!

1. Design goals 

The basic design goals of Amoeba are:

Distribution—Connecting together many machines

Parallelism—Allowing individual jobs to use multiple CPUs easily

Transparency—Having the collection of computers act like a single system

Performance—Achieving all of the above in an efficient manner

One of the main goals of the Amoeba development was to design a transparent

distributed system that allows users to log into system as a whole:Transparency. That

means: Hiding the comlexities of a distributed system from the users. Amoeba users

should not be concerned about the number of processors in the system, nor must they

know the location of the other machines or servers (like the Filesystem server...).

Several machines connected over a network operate as a single system: Distribution.

Amoeba gives its users the illusion of interacting with a single, powerfull system.

Parallelism: On an Amoeba system, a single program or command can use multiple

processors to increase performance. The user simply requests an operation, and the

Amoeba OS decides the best way to execute the request. Amoeba will decide which

processor (or processors) are appropriate for the request, based on the current state of

the system. Additionaly, special development tools have been made for an Amoeba

environment that take advantage of the inherent parallelism. For example, Amoeba

supports a parallel 'make'  program.

Peformance:  Much effort was given to meet this goal!!!This is accomplished with a

newly developed High Performance network protocol called FLIP(Fast Local Internet

Protocol). When FLIP was developed, none of the current protocols provided adequate

support for distributed systems. FLIP performs clean, simple and efficient

communication between distributed nodes.

Development from the scratch; Amoeba doesen't based on any existing operating

system

Amoeba  interact with  the user as a UNIX-like Timesharing System

2. System architecture

Amoeba implements a universell distributed Client-Server-Modell. In fact, basically the whole

system needs only three Functions to do all the work: The transaction call from the Client, and

the GetRequest and PutReply functions on the Server side.  

An Amoeba System consists of four principle components: 

1. Workstations

2. Pool Processors

3. Specialized Servers (File server...)

4. WAN Gateways

Objects

Abstract data types with data and behaviors.

Amoeba primarily supports software objects, but hardware objects also exist.

Each object is managed by a server process to which RPCs can be sent. Each

RPC specifies the object to be used, the operation to be performed, and any

parameters to be passed

Capabilities

128-bit value object description created and returned to the caller when the

object is created.

Subsequent operations on the object require the user to send its capability to the

server to both specify the object and prove the user has permission to

manipulate the object.

Capabilities are encrypted to prevent tampering.

In 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 Processorpool. 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. 

Many different Processor architectures are supported: i80386(Pentium), 68k,

SPARC. Today, only the i80386 architecute is significant for building an Amoeba

system (cheap!!!).

Workstations allow the users to gain access to the Amoeba system. There is

typically one workstation per user, and  the workstation are mostly diskless; only

a workstation kernel must be booted (from floppy, via tftp, burned in Flash-

EEPROM). Amoeba supports X-Windows and UNIX-emulation.

At heart of the Amoeba system are several specialized servers that carry out and

synchronize the fundamental operations of the kernel. Amoeba has a directory

server (called SOAP) that is the naming service for all objects used in the

system. SOAP provides a way to assign ASCII names to an object  so it's easier

to manipulate(by humans). The directory server can replicate files without fearing

their change. Amoeba has of course a file server (called the Bullet Server) that

implements a stable high speed file service. High speed is achieved by using a

large buffer cache. Since the files are first created in cache, and are only written

to disk when they are closed, all the files can be stored contigously. The

underlying idea behind immutable files is to prevent the replication mechanism

from undergoing race conditions. And file server crashes normally don't  result in

an inconsistent file system! The Bullet server uses the virtual disk server to

perform I/O to disk, so it's possible that the file server run as a normal user

program!  The Boot server controll all global system servers (outside the kernel):

start, check and poll, restart if crashed.

All Amoeba objects (files, programs, memory segments, servers) are protected 

and discribed with so called Capabilities (see below).

An example for a processor pool: About 60 -80  Sun motherboards were build into a  rack

system at the Vrije Univerity. Of course cheap and normal IBM-PC 's can be used as CPU-

Servers, too!

3. The Amoeba Micro-kernel 

Microkernel and Server Architecture

Amoeba is built upon a microkernel architecture.

The microkernel supports the basic process, communications, and object

primitives. It also handles device I/O and memory management.

Each machine in the Amoeba system runs a small identical software program -

called the microkernel.

The function of the kernel is to allow efficient communication between client

processes, which run application programs, and server processes, such as the

Bullet File server or the directory server.  

A small piece of code, called the microkernel, is present on all Amoeba machines and they run

nearly the same microkernel which handles 

Low level I/O management

Communication between processes or threads

Low level Memory management

Process and  thread (kernel/user space) management

Server processes (see above) supply other  operating system services and generally run in user

mode. This job specialization allows the microkernel to be small and efficient, increases

reliability, allows as much as possible of the operating system to run as user processes,

providing flexibility and no extra burdens are added to individual CPUs with faciliites that it

doesn't need. 

Threads

Each process has its own address space and contains multiple threads.

These threads have their own stack and program counter, but share the global data and code of

the process.

Remote Procedure Calls

RPC is the basic communication mechanism in Amoeba. Communication consists of a client

thread sending a message to a server thread, then blocking until the server thread sends back a

return message, at which time the client is unblocked.

Amoeba uses stubs to access remote services which hide the details of the remote services

from the user. A special language in Amoeba called the Amoeba Interface Language (AIL)

generates these stubs automatically. The stubs will then marshal parameters and hide the

communication details from the user.

Process concept:

Amoeba supports traditional process concept

Processes consists of several threads (at least one)

Each thread has his own registers, Instruction Pointer, stack; but all threads of a

process share the same  memory region

Example: File server. Each request is handled by one thread, but all threads use

the same cache; synchronization through Mutex  and Semaphores

Memory management:

Threads can allocate and deallocate blocks of memory, called Segments . 

These segments can be read and written, and can be mapped into and out of the

address space of the process.

A process owns at leat one segment, but may have many more of them.

Segments can be used for text, data, stack, or any other purpose the process

desires. The operating system doesen't enforce any particular pattern on

segment usage.

I/O-Managment:

For each I/O-Device attached to a machine, there is a device driver in the kernel.

The driver manages all I/O for the device.

All drivers are static linked to the kernel; no dynamic Module support

Mostly the communication with Device-Drivers are performed through the

standard message protocoll (like the rest of the system in user space)

Communication:

Two forms of communication are provided:  

 

o Point-to-Point communication

o Group communication

Group Communication

o Amoeba provides a mechanism that allows all receivers in a one-to-many

configuration to receive a transmitted message in the same order. This

simplifies parallel processing and distributed programming problems.

4. Amoeba's  Object  concept 

Amoeba

Programs can execute wherever OS decides.

No concept of host machine.

Objects and Capabilities are used to manage file systems.

Network OS

Programs run locally unless specified.

User aware he is using a local host machine.

Files are maintained and accessed from local machine unless using a remote file

system.

The central point of the software concept for a server implementation is the Objectconcept.

Each object consists of 

Data and

Operations on this data

Amoeba is organized as a collection of objects (essentially abstarct data types), each with some

number of operations that processes can perform on it.  Operations on an object are performed

by sending a message to the object's server.Objects are created by processes and managed by

the corresponding server. There are many different object classes: 

Files

Directories

Memory segments

Processes

I/O-Devices (Hard drive...)

Terminals

...

Operations on objects are performed with Stub-procedures.When an object is created, the

server returns a Capability.  The capability is used to address and protect the object. A typically

capability is shown below. 

The Port field identifies the server. The Object field tells which object is beeing referred to,

since a server normally will manage several objects. 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, the Check field is needed to protect them cryptographically, to prevent users from

tampering with them.

 

5. Process management 

A process is an object in Amoeba. Information about the processes in Amoeba are contained in

capabilities and in a data structure called a process descriptor, which is used for process

creation and stunned processes (and process migration). The process descriptor consists of

four components: 

 

 

The host descriptor provides the requierements for the system where the process

must run, by describing what machine it can be run

The capabilities include the capability of the process which every client needs,

and the capability of a handler, which deals signals and process exit

The segment component describes the layout of the addess space (see below)

The thread component describes the state of each of the threads (see below) in

the process and their state informations(IP, Stack,...)

Amoeba supports a simple thread model. When a process starts up, it has at least one thread.

The number of threads is dynamic. During execution, the process can create additional threads.

And existing threads can terminate. All threads are managed by the kernel. The advantage of

this design is that when a thread does a RPC, the kernel can block that thread and schedule

another one in the same process if one is ready! 

Three methods are provided for thread synchronization:

Mutexes

Semaphores

Signals

A Mutex is like a binary semaphore. It can be in one of two states, locked or unlocked. Trying to

lock an unlocked mutex causes it to become locked. The calling thread continues. Trying to lock

a mutex that is already locked causes the calling thread to block until another thread unlocks the

mutex.The second way threads can synchronize is by counting Semaphores. These are slower

than mutexes, but there are times when they are needed. A semaphore can't be negative. Try

down a zero semaphore  causes the calling thread to block until another thread do a up

operation on the semaphore.

Signals are asynchronous interrupts sent from one thread to another in the same process.

Signals can be raised, caught, or ignored. Asynchronous interrupts between processes use

the stun mechanism.

6. Memory management  

Amoeba supplies a simple memory management based on segments. Each process owns at

least three segments:

1. Text/Code segment

2. Stack segement for the main thread/process

3. Data segment

Each further thread gets his own stack segment, and the process can allocated arbitrary

additional data segments.

All segments are page protected by the underlying MMU, the kernel segments, too.

7. Communication 

The definitions of the Amoeba communication calls are given in the ANSI C language.

All three calls use a Msg data structure, which is a 32-byte header with several fields to

hold capabilities and other items. Note that each request or reply message can consist

of just a header or a header and an additional component.

All processes, the kernel too, communicate with a standardized RPC (Remote procedure

call) interface. There are only three functions to reach this goal:

trans(Msg *requestHeader, char *requestBuffer, int requestSize, Msg *replyHeader,

char*replyBuffer, int replySize) Client sends a request message and receives a reply; the

header contains a capability for the object upon which an operation is being requested.

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

-> do a transaction to another server

get_request(Msg *requestHeader, char *requestBuffer, int requestSize)Server gets a

request from the port specified in the message header.

getreq( req_header, req_buf, req_size)

-> get a client request

put_reply(Msg *replyHeader, char *replyBuffer, int replySize) Server replies.zza

putrep( rep_header, rep_buf, rep_size)

-> send a reply to the client

The first function is used by client to send a message to a server, and get a reply from the

server on this request. The reply and request buffers are generic memory buffers (char). The

reply and request headers are simple data structures to describe the request and the capability

of the server. On the other side, teh server calls within an infinite loop the getreq function. Each

time a client sends this server (determined by a server port - see capabilities for details) a

message, the getreqfunction returns with the client data filled in the request buffer, if any. The

request header contains informations about the client request.

Because the client expects a reply, the server must send a reply (either with or without reply

data) using the reply function.

How to use Amoeba

Amoeba is freeware

It can be loaded on a LAN or University computer system

Editors such as elvis, jove, ed come with the installation package

Compilers such as C, Pascal, Fortran 77, Basic, and Modula 2

Orca - used for Parallel Programming

Applications

UNIX emulation

Parallel make

Traveling salesman

Alpha-beta search

Parallel make

o Amoeba runs contains a processor pool with several processors.

o One application for these processors in a UNIX environment is a parallel

version of make.

o When make discovers that multiple compilations are needed, they are run in

parallel on different processors.

o pmake was developed based on the UNIX make but with additional code to

handle parallelism.

o many medium-sized files = considerable speedup

o one large source file and many small ones = total time can never be smaller

than the compilation time of the large one.

o A speedup of about a factor of 4 over sequential make has been

observed in practice on typical makefiles.

The Traveling Salesman

o The computer is given a starting location and a list of cities to be visited. The

idea is to find the shortest path that visits each city exactly once, and then

returns to the starting place.

o Amoeba was programmed to run this application in parallel by having one

pool processor act as coordinator, and the rest as slaves.

o Example: the starting place is London, and the cities to be visited include

New York, Sydney, Nairobi, and Tokyo

o The coordinator might tell the first slave to investigate all paths starting with

London-New York, the second slave to investigate all paths starting with

London-Sydney, the third slave to investigate all paths starting with London-

Nairobi...

o All searches go on in parallel.

o When a slave is finished, it reports back to the coordinator and gets a new

assignment.

o Also, the algorithm can be applied recursively.

o The first slave could allocate a processor to investigate paths starting with

London-New York-Sydney, another processor to investigate London-New

York-Nairobi, and so forth.

o Results show that about 75 percent of the theoretical maximum speedup can

be achieved using this algorithm, the remaining 1/4 being lost to

communication and other overhead

Significance of points

Amoeba is a distributed operating system which successfully allows users to execute

jobs transparently over multiple CPUs.

It was primarily developed by Andrew Tannenbaum and others at the Vrije Universiteit

Amsterdam, Netherland.

Its basic design goals are –

Distribution—Connecting together many machines

Parallelism—Allowing individual jobs to use multiple CPUs easily

Transparency—Having the collection of computers act like a single system

Performance—Achieving all of the above in an efficient manner

It is based on a microkernel architecture.

It uses objects to encapsulate data and processes and capabilities to describe the

objects.

The kernel provides just three major system calls

trans(Msg *requestHeader, char *requestBuffer, int requestSize, Msg *replyHeader,

char*replyBuffer, int replySize)

get_request(Msg *requestHeader, char *requestBuffer, int requestSize)

put_reply(Msg *replyHeader, char *replyBuffer, int replySize)

It has proven to be successful at implementing speedup on many common computer

science algorithms including UNIX emulation, parallel make, traveling salesman, and

alpha-beta search.

Summary

The Amoeba distributed operating system succeeds in overcoming many of the

hurdles faces in distributed computing.

It abstracts away the use of RPCs using stubs and is scalable based on available

CPUs.

Although system updates seem to have stopped, the current version appears to

have reached a stable point in its architectural development.

The programming languages included with the distribution are common to most

programmers and should make code creation easy for Amoeba applications.

Results of application speedup and the fact that the system is freely available

make it worth evaluating at the university level.

References

[1]-Based on the article: Amoeba: An Overview of a Distributed Operating

System by Eric W. Lund - March 29, 1998, Rochester Institute of Technolog and

informations about Amoeba taken from a  web site from the University of Halle.

Additional parts are taken from the Amoeba tribute site from Stephen Wagner.

Furthermore the classics: The Amoeba kernel, Andrew S. Tanenbaum, M.F.

Kaashoek.

[2] Tanenbaum, A.S, Sharp, G.J. “The Amoeba Distributed Operating System”

Online: 2006 http://www.cs.vu.nl/pub/amoeba/Intro.pdf

[3] Ramsay, M., Keigel, T., Memmer, H. “Ameoba Distributed Operating

System” Online http://csserver.evansville.edu/~mr56/CS470/Final_Draft.pdf

[4] Coulouris, G. Dollimore, J., Kindberg, T. Distributed Systems – Concepts

and Design, 1994, Online: http://www.cdk3.net/oss/Ed2/Amoeba.pdf

[5] Sharp, G.J.: ‘‘The Design of a Window System for Amoeba,’’ Report IR-

142, Dept. of Math. & Computer Science, Vrije Universiteit, Dec. 1987.

[6] The Amoeba Reference Manual Users Guide Vrije University of

Amsterdam, 1996 Online 2006:

http://www.cs.vu.nl/pub/amoeba/manuals/usr.pdf

[7] Bal, H.E., Renesse R. van, and Tanenbaum, A.S.: ‘‘Implementing

Distributed Algorithms Using Remote Procedure Calls,’’ Proc. 1987 National

Computer Conference, pp. 499-506, June 1987.

[8] Baalbergen, E.H.: ‘‘Parallel and Distributed Compilations in Loosely

Coupled systems,’’ Proc. Workshop on Large Grain Parallelism , Providence,

RI, Oct 1986.

[9] Straven H. van, Renesse R. van, and Tanenbaum, A.S, “The Performance

Of The Amoeba Distributed Operating System” Online: 2006

https://dare.ubvu.vu.nl/bitstream/1871/2589/1/11008.pdf

[10] Tanenbaum, A.S, et al, “Experiences with the Amoeba Distributed

Operating System” Online 2006:

http://citeseer.ist.psu.edu/cache/papers/cs/6593/ftp:zSzzSzftp.sys.toronto.eduzS

zpubzSzamoebazSz03.pdf/tanenbaum90experiences.pdf

[11] Wikipedia – www.wikipedia.com

[12] Slide finder – www.slidefinder.com

[13] Slide share – www.slideshare.com

[14] document share – www.docshare.com