Amoeba

Amoeba

Distributing operating system

Agrata shukla
0127cs091001

Introduction
The Amoeba operating system began as a research project in Vriji
universiteit in Amesterdem.
The basic goal of amoeba is to provide user a single powerful time
sharing systems while actually running their jobs on a collection
of machines potentially distributed over several computing sites.
The basic is to provide users with the illusion of single powerful time
sharing system when infact the system is implemented on a
collection of machines potentially distributed among several
countries.

History of Amoeba
The initial research done in Amsterdam led to the design
and implementation of the Amoeba Distributed Operating
System
It is used as a prototype and a vehicle for further research
both at Vrije Universiteit and at the Center for
Mathematics and Computer Science also in Amsterdam.
The goal of this further research was to build a distributed
system that is invisible to users

Main objectives of Amoeba
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

Amoeba System architecture
The hardware of an Amoeba system has three principal components all connected
by a LAN:
- An X-terminal or workstation running X-Windows for each user
- The processor pool (a rack of single-board computers)
- A certain number of dedicated servers (file server, etc.)
Each user has an X-terminal (or workstation running X-Windows) for talking to
the system.
Although it is technically possible to run user jobs on this machine, that is not
normally done, as it is
the intention to have Amoeba programs use multiple processors in parallel to
improve performance.
The processor pool idea is based on the assumption that the ratio of processors to
users is large.

Processor pool model
Although using idle workstations adds a little computing power to the system, it
does not address a more fundamental issue:
�What happens when it is feasible to provide 10 or 100 times as many CPUs as
there are active users?
1.One solution, as we saw, is to give everyone a personal multiprocessor. However
this is a somewhat inefficient design.
2.An alternative approach is to construct aprocessor pool, a rack full of CPUs in the
machine room, which can be dynamically allocated to users on demand.
�Instead of giving users personal workstations, in this model they are given highperformance graphics terminals.
�Conceptually, it is much closer to traditional timesharing than to the personal
computer model, although it is built with modem technology

Objects and capabilities
Amoeba is an object-based system. The system can be viewed as a collection of objects, on
each of which there is a set of operations that can be performed
Associated with each object is a capability [8] a kind of ticket or key that allows the holder
of the capability to perform some (not necessarily all) operations on that object. A user
process might
Each user process owns some collection of capabilities, which together define the set of
objects it may access and the type of operations he may perform on each
Thus capabilities provide a unified mechanism for naming, accessing, and protecting
objects
From the user’s perspective, the function of the operating system is to create an
environment in which objects can be created and manipulated in a protected way.
.

Remote procedure calls
The client has to place the capability, operation
code, and parameters in the request buffer, and
on receiving the reply it has to unpack the results.
The server has to check the capability, extract the
operation code and parameters from the request,
and call the appropriate procedure

Remote procedure call
The author of the handwritten stub uses several pieces
of derived information to do the job.
1. The buffer is used only to receive information from the file server; it is an output
parameter, and should not be sent to the server.
2. The maximum length of the buffer is given in the nbytes parameter. The actual length of
the buffer is the returned value if there is no error and zero otherwise.
3. File􀀀 is special; it defines the service that must carry out the remote operation.
cap
4. The stub generator does not know what the server’s operation code for read􀀀 is. This
file
requires extra information. But, to be fair, the human stub writer needs this extra
information too.

Threads
A process in Amoeba consists of one or more threads that run in parallel. All the
threads of a process share the same address space, but each one has a dedicated
portion of that address space for use as its private stack, and each one has its own
program counter.
The RPC communication is actually between threads of a process, not the process itself

The RPC creation, sending, receiving and decoding are all processed by the
kernel. There are library functions defined which give interfaces to the user
program and allows for a seamless view of thread communication to the
programmer.
.

Servers
The Amoeba kernel, as described above, essentially handles communication and some
process management, and little else. The kernel takes care of sending and receiving
messages,scheduling processes and some low-level memory management. Everything
else is done by user processes.
A process is created by executing the following steps.
1. Get the process descriptor for the binary from the file system.
2. Create a local segment or a file and initialize it to the initial environment of the new
process.
The environment consists of a set of named capabilities (a primitive directory, as it
were), and the arguments to the process (in Unix terms, argc and argv).
3. Modify the process descriptor to make the first segment the environment segment just
created.
Send the process descriptor to the machine where it will be executed.

Bullet server
The bullet server is an immutable file store, with as principal operations read-file and
create-file. (For garbage collection purposes there is also a delete-file operation.) When
a process issues a read-file request, the bullet server can transfer the entire file to the
client in a single RPC, unless it is larger than the maximum size (30,000 bytes), in
which case multiple RPCs are needed. The client can then edit or otherwise modify the
file locally. When it is finished, the client issues a create-file RPC to make a new
version.
The files are stored contiguously on disk, and are cached in the file server’s
memory(currently 12 Mbytes). When a requested file is not available in this memory, it
is loaded from disk in a single large DMA operation and stored contiguously in the
cache.
In the create-file] operation one can request the reply before the file is written to disk (for
speed), or afterwards (to know that it has been successfully written).

Directory server
The bullet server does not provide any naming services. To access a file, a process must
provide the relevant capability. Since working with 128-bit binary numbers is not
convenient for people, we have designed and implemented a directory server to manage
names and capabilities.
Using this capability, the process can then access the file. In UNIX terms, when a file is
opened, the capability is retrieved from the directory server for use in subsequent read
and write operations. After the capability has been fetched from the directory server,
subsequent RPCs go directly to the server that manages the object. The directory server
is no longer involved..

WIDE-AREA AMOEBA
Amoeba was designed with the idea that a
collection of machines on a LAN would be able
to communicate over a wide-area network with a
similar collection of remote machines. The key
problem here is that wide-area networks are slow
and unreliable, and furthermore use protocols
such as X.25, TCP/IP, and OSI, in any event, not
RPC.

APPLICATIONS
Amoeba has been used to program a variety of
applications. In this section we will describe
several of them, including emulation, parallel
make, traveling salesman, and alpha-beta search.
UNIX

UNIX Emulation
One of the goals of Amoeba was to make it useful
as a program development environment.
For such an environment, one needs editors,
compilers, and numerous other standard
software. It was decided that the easiest way to
obtain this software was to emulate and
UNIX

then to run and MINIX [25] compilers and other
utilities on top of it.
UNIX

PERFORMANCE
1. Two user processes running on Amoeba.
2. Two user processes running on Sun OS 4.0.3 but using the Amoeba primitives.
3. Two user processes running on Sun OS 4.0.3 and using Sun RPC.
The latter two were for comparison purposes only. We ran tests for the local case (both
processes on the same machine) and for the remote case (each process on a separate
machine,
with communication over the Ethernet). In all cases communication was from process to
process,
all of which were running in user mode outside the kernel. The measurments represent
the average values of 100,000 trials and are highly reproducible

.

Memory and Process Management
Amoeba’s memory model, which is handled by the microkernel, is very small and
efficient. A process’s address space contains segments mapped onto userspecified virtual addresses
These segments include, but not limited to, a text/code segment, a data
segment, and a stack segment for main/thread process
When a process is executing, all of its segments are in memory. Amoeba does not
utilize virtual memory or swapping so it can only run programs that do not
exceed physical memory. This does however keeps the management scheme
simple and provides high performance.

File System
One area of the system which we think has been eminently successful is the design of the
file server and directory server. We have separated out two distinct parts, the bullet
server, which just handles storage, and the directory server, which handles naming and
protection. The bullet server design allows it to be extremely fast, while the directory
server design gives a flexible protection scheme and also supports file replication in a
simple and easy to understand way. The key element here is the fact that files are
immutable, so they can be replicated at will, and copies regenerated if necessary.
The entire replication process takes place in the background (lazy replication), and is
entirely automatic, thus not bothering the user at all. We regard the file system as the
most innovative part of the Amoeba 4.0 design, combining high performance with
reliability, robustness, and ease of use.

Security
An intruder capable of tapping the network on which Amoeba runs can discover
capabilities and do considerable damage. In a production environment some form of
link encryption is needed to guarantee better security. Although some thought has been
given to a security mechanism [26] it was not implemented in Amoeba 4.0.

We intend to install both versions and investigate the effects on performance of the system.
We are researching the problems of authentication in very large systems spanning
multiple organizations and national boundaries.

I/o scheduling
Input and output (memory, disk) is handled by the microkernel threads. To
read a block from the disk, a process does remote procedure calls to a disk I/O
thread in the kernel. The calling process does not know that the server is
actually a kernel thread because user thread interfaces are identical to kernel
thread interfaces
As far as file I/O goes, having multiple threads within a process accentuates
the distributed and parallel and computing model very well

Reasons to use Amoeba
The need to control several machines from one user process can be
accomplished by a distributed operating system, such as Amoeba.
Another situation that could efficiently utilize a distributed system is any
program that commonly requires large computations.
A more practical reason to use the Amoeba operating system is to save money,
both by utilizing old hardware and by lessening the need to
purchase expensive servers. An additional reason to use Amoeba is that the
source code for the operating system is available for free, so you can make
your own version of Amoeba to suit your needs.

Reasons not to use Amoeba
Other clustered operating systems that operate in a similar fashion to Amoeba
are more readily available and easier to use
This is due to the fact that the source code is available for each user to edit.
These reasons, along with others, make Amoeba a risky business venture.

Conclusion
Overall, the Amoeba distributed operating system is an interesting and
unique idea. It provides system administrators the power to distribute
work over a variety of machines without inconveniencing the users.
Despite this and other useful features, we predict that Amoeba will not
ever become a widely used operating system. However, the knowledge
gained by the development of and research about Amoeba has helped
in the design of other distributed and clustered operating systems.

Amoeba

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Amoeba (20)

More from Agrata Shukla (6)

Recently uploaded (20)

Amoeba