A M O E B A-The Study of a Distributed Operating

system

AMOEBA

Index
Abstract2 What Is AMOEBA ? ...3 History .3 Design Goals ..........4 System Architecture ....5 Networking ...7 Heterogeneity .....7 New FSD-Amoeba ....7 Amoebas Object ...9 Kernel Feature ....

Concept

&

capabilities

.....

Process Management ....... 9 Memory ..10 Management .......

Communication .11

.............

The Virtual Amoeba Machine (VAM) ......... .12 General Requirements ........13 .....

Implementation .............13
2

AMOEBA

Security .................13 Comparison of Amoeba Vs V ......... 14 Fields Of Application ........15 Conclusion ............15 Bibliography .........16

ABSTRACT For my physical studies like Measurement of velocity gradients in high viscose liquids I use Amoeba as a compact and powerful lab measurement system with many reduced pc systems for only data recording together with high speed Pentium PC's for data analysis connected through a standard 10 Mbps Ethernet network. Putting all machines together to one large coupled system is very simple and flexible. Only less administration work must be done. Amoeba doesn't make any usage of the BIOS. All needed hardware drivers are delivered within the Amoeba kernel. But the first bootstrap stage (Amoeba standalone boot program on floppy or hard disks) needs the BIOS to load the first Amoeba kernel. Amoeba builds upon a traditional micro kernel. It supports true multithreading (kernel controlled), segment based memory management. Currently, it's the fastest distributed operating system. Here I m giving u concise and informal introduction to distributed operating system-AMOEBA

AMOEBA

WHAT IS AMOEBA?

Amoeba is a distributed operating system. It collects a huge variety 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. Amoeba system will connect the multiple Amoeba system in different sites into a single coherent system. 4

AMOEBA This goal is obtained by using the object and capabilities in a uniform way. 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 each other over a standardized RPC (Remote Procedure Call) interface - simple but very powerful. 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 variety 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 a slightly experimental state, but ready to use. FSD-Amoeba is intended to use for dedicated programmers only, and not for end users! HISTORY

Developed at the Vrije Universiteit Amsterdam, Netherlands. Chief designer: Andrew S. Tanenbaum Other developers 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

DESIGN GOALS Transparency: 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...). Distribution: Several machines connected over a network operate as a single system: Distribution. Amoeba gives its users the illusion of interacting with a single, powerful system. Parallelism:

AMOEBA 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) is appropriate for the request, based on the current state of the system. Additionally, special development tools have been made for an Amoeba environment that takes advantage of the inherent parallelism. For example, Amoeba supports a parallel 'make' program. Small Kernel approach: To enhance flexibility and to minimize kernel size its design was based on micro kernel approach. That is, in Amoeba several of the standard services, such as file service, are built outside kernel in user space. This helps in enhancing flexibility because these services can be easily modified and multiple versions of service can be simultaneously run on the same system to suit the needs of different users. Performance: 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 doesnt based on any existing operating system

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

High performance IPC message passing for local, privileged user processes; transfer of several data buffers with one transaction; shared segment support with VM address translation by the IPC module: Implemented, shared segment support now available User process interrupt handler: working

User process I/O port access: done fast context switch (both thread and process): currently not achieved Clean and simple virtual memory (but without page swapping): exists already

SYSTEM ARCHITECTURE Amoeba implements a universal distributed Client-Server-Model. 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. Amoeba Many different Processor architectures are supported: i80386 (Pentium), 68k, SPARC. Today, only the i80386 architecture is significant for building an Amoeba system (cheap!!!). System consists of four principle components:

Workstations Pool Processors Specialized Servers (File server...) Gateways 6

AMOEBA

File Servers The file server distributed with Amoeba is called the Bullet Server. It uses a large buffer cache to provide very high performance. Thus the file server should be run on a machine with a large amount of RAM, and, of course, a disk. There is a modified version of the bullet server, called bulletb, using a different cache method, and needing less memory. For the file server, the more memory present, the better the performance. The following table shows the minimum amount of memory needed for an isolated file server host, a boot host, the installation, and the workstation kernel. It also shows the largest main memory support by the kernel. In most cases this will not be supported by the physical machine. On the various 80x86 machines it may be possible to insert up to 512 MB**, depending on the machine. You need at least 4 MB RAM to run the bare kernel and perhaps a login shell, for example a text only console or a special I/O Hardware Server, a printer spooler or something else. Kernel Minimum Memory Requirement Workstation 4 MB Fileserver 16 MB Installation 32 MB Boot (with 64 MB FS) Software Limit on Memory 512 MB 512 MB 512 MB 512 MB</TD)< tr>

Fig. 1. Minimum memory requirements for file server machines and maximum memory configurations supported by Amoeba. 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 7

AMOEBA 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 control all global system servers (outside the kernel): start, check and poll, restart if crashed. Workstations 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. The primary function of workstations is to run the user interface (for example the X window system) and so they do not require large amounts of memory. 8 MB is the lower limit for color and monochrome X servers. 16 MB and more is recommended. For a generic text terminal, 4MB is still enough. It is also possible to use an X terminal as a workstation. (If the X terminal does not understand the Amoeba network protocol it will be necessary to use a TCP/IP server to convert network protocols which reduces perceived performance.)If no bitmap display is available a regular terminal can be used.It will not run X windows, of course. Pool Processors

. The V8-SPARC processor pool at the VU 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 Processors 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. Nearly all the computing occurs on the pool processors. There is swap support in Amoeba so it is important that pool processors (and of course all machines executing programs) have enough memory to run the processes entirely in core. Between 8 and 16 MB of memory is the minimum for normal use. If large programs such as matrix multiplication (SCILAB, DATAPLOT) or TEX, and of course GCC are to be run then more memory will be required (at least 32 MB, 64128 MB recommended). Each processor pool should have at least 4 or 5 processors to do any useful work. NETWORKING

AMOEBA

Currently Amoeba only has drivers for Ethernet but other network drivers are under consideration. Amoeba sets no upper limit on the number of computers on a local network but in some cases it is limited by the network bandwidth or topology. Note well: Amoeba does not demand exclusive use of the network. It can use the same network as computers running other operating systems. However it is in the nature of distributed systems to consume more network bandwidth than centralized systems. It is therefore a good idea to isolate the Amoeba hosts behind a bridge if the other hosts on the network are performing important functions which require good network response. HETEROGENEITY Amoeba is reasonably portable and has run on five architectures.However it is currently only available on the following architectures: The Motorola MC680x0 family The Intel 80386 family and Certain members of the SPARC family.

The FSD Distribution itself supports only the Intel 80386 family, but can coexist with the old Amoeba5.3 system! But be aware of too much binary and kernel mixing between the old and the new system; you will probably fail. It should be noted that some of these architectures are bigendian and others littleendian. A mixture of different endian machines should not be a problem as standard servers and utilities deal with this. Combinations of different architectures only require that the binaries are available for all the architectures. Processor pools may contain processors of more than one architecture. The run server chooses the optimal processor for the architectures for which the binaries are available. There are several configurations supported for the three architectures to provide the various types of processor required: pool, workstation and specialized server NEW FSD AMOEBA KERNEL FEATURE The kernel is the part of a multitasking operating system responsible for task, resource and communication management. The Vertex-Amoeba kernel has some major features over other commonly used OS kernels: High performance Server-Client communication Remote Procedure Call (RPC): used by processes and the kernel to perform remote or local message based communication; continuous frames up to 1 Gigabytes can be send with one

AMOEBA transaction; achieves highest performance on Ethernet networks - see the performance page for details. Interprocess Procedure Call (IPC): used by processes and the kernel (for example device drivers in user space) to interchange messages and data buffers on the local machine; optimized for low latency and high transfer rates Kernel administration Remote rebooting of kernels: with a simple RPC boot request it's possible to boot new kernels on machines already running with an Amoeba kernel. Remote status report: nearly all kernel related informations and statistics can be retrieved remotely using a simple RPC request, including the kernel message buffer (the content you can see printed on the terminal console). Now it's possible to run device drivers, network protocol stacks, file system servers,..., in user mode as generic user processes (with some more privileges). Local modules now communicate with the new enhanced IPC interface. Most device drivers and many other parts (servers) currently inside the Amoeba should move outside the kernel in usual user processes with privileged rights. Similar concepts from Mach, VSTa, L3/4 and QNX influenced the new design to create an Operating System ready for the third millenium!

MICRO KERNEL DESIGN Clean and unified interaction between kernel modules and processes inside and outside of the kernel device drivers can be implemented as generic user processes outside the kernel fast I/O response time kernel and user thread support (both controlled by the kernel) small set of system calls 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 facilities that it doesn't need. Process concept:

10

AMOEBA

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 cans 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 doesnt enforce any particular pattern on segment usage. I/O-Management: 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 protocol (like the rest of the system in user space) Communication: Two forms of communication are provided: Point-to-Point communication

Group communication AMOEBAS OBJECT CONCEPT & CAPABILITIES

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 organized as a collection of objects (essentially abstract 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 11

AMOEBA

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. All Amoeba objects (files, programs, memory segments, servers) are protected and described with so called Capabilities the capability is used to address and protect the object. A typically capability is shown below.

Figure [Tanenbaumet.al(1990, p 42)]

6.

Capability

Service Port field identifies the server. Object field tells which object is being referred to, since a server normally will manage several objects. Rights field specifies which operations are allowed (e.g. capability for a file may be read only). Since capabilities are managed in user space Check field is needed to protect them cryptographically, to prevent users from tampering with them. 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:

12

AMOEBA

The host descriptor provides the requirements 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 address 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 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. Semaphores is the second way threads can synchronize is by counting 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 does an 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. MEMORY MANAGEMENT Amoeba supplies a simple memory management based on segments. Each process owns at least three segments: 13

AMOEBA 1. Text/Code segment 2. Stack segment 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.

COMMUNICATION

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_siz) get a client request

14

AMOEBA putrep(rep_header,rep_buf,rep_siz) 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 getreq function 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. THE VIRTUAL AMOEBA MACHINE (VAM)

The Virtual Amoeba Machine Environment consists of these main parts: From the underground and below The native Amoeba kernel, a modern micro kernel supplying low level process and thread management, device drivers, for example for network devices, and other things needed for a ground level system. Or the UNIX kernel (many modern UNIX systems are supported) UNIX (see the picture below): UThreads

15

AMOEBA A user level thread package emulating the Amoeba thread system (under the native Amoeba system within the kernel) AMUNIX This the port of the Amoeba system library, supplying routines for the Amoeba basic concepts, like Remote Procedure Call (RPC) interface and many more, to the Unix environment. FLIPD This is the user level implementation of the Amoeba network protocol stack FLIP (Fast Local Internet work Protocol). VAM The VAM itself. It's a fully new implemented Amoeba environment which builds on the top of the above explained parts. It's mostly written in the functional programming language OCaML. OCaML programs are not exceuted directly on the underlying OS and CPU, instead a Virtual Machine executes byte code in an operating system and host processor independent way. Amoeba The native Amoeba kernel (called the VERTEX-Kernel), with these features: Clean and modern micro kernel design Easy to implement device drivers User space device driver support Full network performance through direct FLIP network access The kernel operates standalone, and needs no further configuration The advantages of this dual system concept: The basic Amoeba concepts are available on generic operating systems with your convenient home environment. New operating systems mostly lack of actual device drivers, especially on the i86-pc platform.

For specialized machines, for example data acquisition systems, or device minimized numeric cluster machines, the native Amoeba kernel is the best choice, featuring a modern and clean microkernel, and exploring the power of the Amoeba system.

GENERAL REQUIREMENTS The Amoeba distributed operating system can run on many different types and brands of computers. It is intended that it should run on a network with at least five computers. Although it is today technically possible to run Amoeba with just a single processor, it is not a satisfactory way to use the system. For a standalone system (with perhaps additional secondary machines) the main machine should be equipped with at least 64 MB RAM (128 MB recommended) and at least with 500MB disk space. It is, after all, a distributed operating system. To get good results from the system you should have a separate machine for the file server, one workstation per user (to run the user interface) and a group of pool processors to perform the actual work and to run various servers. In general, at least five hosts are needed for pleasurable computing, although it's not true today anymore because of todays fast Pentium machines. All the Amoeba hosts must be connected by a network so that they can communicate with each other, although they need not

16

AMOEBA necessarily be all on the same network, as long as all the networks are connected via gateways. Currently, Fireball Amoeba only supports Ethernet. In special only the 10 MBit/s connectivity with RJ45 or RG58 connectors, and now 100 MBit/s Fast Ethernet, too. IMPLEMENTATION According to Tanenbaum (1990), AMOEBA system has been implemented to five different CPU : 68010, NS 32016, 8088, VAX, PDP-11. The idea is to provide a universal single powerful time sharing systems, which consists of a collection of machines, potentially distributed among several countries. Current configuration has 48 single board VME based computers using 68020 and 68030 CPU and also 10 VAX CPU forming additional processor pool. A library which supports to run UNIX program on AMOEBA had been written. Current research includes connecting AMOEBA at 5 locations in 3 countries. Using Wide Area Network facilities. SECURITY Amoeba has two level of protection: Ports for protecting access to server Capabilities for protecting access to individual objects. Since the kernel must be kept as small as possible, to implement the security aspect there is two solutions. hardware solution: A small interface box (F - box) are put between each processor module and the network. It can be done by putting into the VLSI chip in interface card, or on a small printed circuit board which attach to network. This solution is currently used. software solution: since ports for public servers are known to all users it is easy for an intruder to impersonate a server just by doing a get_rerequest on the servers port. So the F- box is built as a cryptographic algorithms which has the same function with the F-box. The F box is one way function mapping Get-port to Put-port Put-port = F(Get-port) Thus that given G, P can be computed, but that given P, calculating G is not practically feasible.

Figure 7. Network security[Goscinski(1991, p823)] COMPARISION OF AMOEBA AND V There are some similarity between Amoeba and V. Some of feature in Amoeba are adapted from V. Some features of Amoeba had been planed by the designer of V to be implemented in the future, for instance processor pool concept. [Cheriton (988)].

17

AMOEBA Amoeba and V use the small kernel to provide the infrastructure of the distributed system. Kernel provides the communication, process manager, memory manager and a small server. Most of other facilities which usually are in the Operating System run on the top of the kernel at the user level. This approach makes V and Amoeba more flexible and more reliable, because if something goes wrong in a server, the other server which is in the other site (physically or logically) can take over the process). Amoeba and V are free-market model service, Service such as the file system are in principle just an ordinary user process. Any user who unsatisfied with the standard file system will be able to write their own system. Amoeba and V use client-server and remote procedure call. The difference is the transport protocol, V uses the VMTP but Amoeba does not. V and Amoeba allow the process to migrate to another processor, if the processor is busy or high loaded. V does not have the processor pool, and there is no dynamic processor allocation. Amoeba has a processor pool and does the processor allocation. V had not been developed to use the Wide Area Network, but Amoeba has been implemented using WAN. By using workstation as the processor, V can take advantages of the modern and powerful workstation, and the system will be more reliable, because the responsibility of process is distributed in each workstation. Amoeba use only a single naming mechanism (object with capability), It makes the system will be more consistent and easier to used. V uses 3 level of naming. At the top level of V naming mechanism, the mechanism will works similar with object and capability. Amoeba is more fault tolerance than V (Cheriton 1988), because V was designed for interactive workstation, so if there are something goes wrong, user can re-execute. Amoeba is more secure than V, first Amoeba using cryptography for naming, and secondly Amoeba uses the hardware one way scrambler. Amoeba performance depends on the processor pool, thus if there is a malfunction it the processor pool all system will stop. In contrast, V uses the processor in every workstation, thus the responsibility of the work is distributed to each workstation. In the development process, V is mainly addressed to provide a fast communication between work station, but Amoeba is addressed to provide an object oriented distributed operating system. And V is designed to support parallel and real time application on shared memory multiprocessor machine. The performance comparison between AMOEBA and V System Null Throughput Estimated RPC in KBps CPU in msec AMOEBA 1.1 V 2.5 820 546 MIPS 3.0 2.0

Table 1. Comparison between V and Amoeba [Tanenbaum(1990, p57)] 18

AMOEBA This measurement is done from user to user, and using SUN 3/60 for AMOEBA and SUN 3/75 for V system. From this table can be shown that the throughput of Amoeba is better than V. and the overall CPU MIPS is better as well. FIELDS OF APPLICATION The VAM system can be used in the following applications fields: Distributed measuring and data acquisition systems, for example remote digital camera servers connected with an Ethernet network. The native Amoeba kernel is very well suited for embedded systems. Distributed control systems. High performance parallel computing and other distributed numerical computations.

Distributed file systems using raw disk access on the top of standard operating

systems.

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 CPUServers, too!!! CONCLUSION A distributed system potentially will be more reliable and low cost than a time sharing system. However some problem still arises in the designing of a distributed system . Those problems are communication primitives, naming , resource management, fault tolerance and the protection issues. The hardware configuration which will be used will determine the model of the operating system, for instance a processor poll model will be difference with workstation pool model. The kernel model provide definition of each facility based on maximising performance, minimising complexity in the kernel maximising the reliability and security attribute of the system. By placing the other service outside the kernel and keeping the kernel as small as possible, the system is more flexible and reliable. The client-server model with remote procedure call have proved that using basic primitive communication the overhead of communication can be reduced. The speed of communication between processor determines the performance of the system. By using the object and capability model, Amoeba is more flexible and more easily be used. Amoeba is the only one Distributed Operating System which implements Wide Area Network. BIBLIOGRAPHY BOOK: Distributed Operating Systems by Tanenbaum Distributed Operating Systems Concepts and Design by Pradeep K. Sinha Web site: http://www.cs.odu.edu/ http://images.google.co.in/images? q=distributed+operating+system&hl=en&btnG=Google+Search http://fsd-amoeba.sourceforge.net/amoeba.html

19

AMOEBA BACK TO INDEX

20