Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

About amoeba os

Published in: Education, Technology
  • Be the first to comment


  1. 1. Amoeba Distributing operating system Agrata shukla 0127cs091001
  2. 2. 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.
  3. 3. 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
  4. 4. 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
  5. 5. 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.
  6. 6. 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
  7. 7. 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. .
  8. 8. 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
  9. 9. 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.
  10. 10. 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. .
  11. 11. 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.
  12. 12. 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).
  13. 13. 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..
  14. 14. 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.
  15. 15. 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
  16. 16. 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
  17. 17. 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 .
  18. 18. 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.
  19. 19. 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.
  20. 20. 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.
  21. 21. 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
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.