Amoeba - A Distributed System for the 1990s

1. Amoeba - A Distributed System for the 1990s Group A6 Abdul Aziz Habib Ammari Pearl Thomas Vamsi Krishna

2. Introduction • Amoeba: distributed operating system developed at the Free University (Amsterdam), and Center for Mathematics and Computer Science (Amsterdam) • Single big timesharing system - Transparency of processors assigned to jobs - Transparency of user’s files storage and their replication - Transparency of processes-machine intercommunications • Amoeba 4.0 system released in 1990

3. Amoeba Hardware architecture • Workstations • Execution of processes interacting intensively with the user • Examples. Window manager, command interpreter, editors, CAD/CAM graphical front-ends • Processor Pool • Computing power • Large number of single-board computers (several megabytes of private memory, network interface)

4. Amoeba Hardware architecture (cont’d) Example. make <program> - <program>: program with dozens of source files - Processor allocation for running many compilations in parallel - Return of processors to the pool at the end of execution • Multiprogrammed pool processors (best performance when a process is assigned its own processor) • Dynamic number of processors • Crash of few processors will not affect the system (some jobs may have to be restarted): degree of fault tolerance

5. Amoeba Hardware architecture (cont’d) • Specialized Servers • Running dedicated processes with unusual resource demands • Example: running file servers on machines having disks (performance optimization) 4. Gateways • Gateways to other Amoeba systems accessed over wide area networks • Amoeba is spans several countries • Gateway: local machines protection from the idiosyncracies of the protocols used over the wide area links Centralized computing power: incremental growth, fault tolerance, large amount of computing power assigned to a single job (temporarily)

6. Amoeba Software architecture • Amoeba: Object-based system using clients and servers • Use or RPCs for client processes-server processes communication (sending requests: operations on objects) • Objects identified and protected by capabilities • Capability structure - Server port: server who manages the object - Object number: object identifier - Rights field: permitted operations - Check field: cryptographic protection (keeping users from tampering with the other fields) • Capabilities embedded in a huge address space: key to protection in Amoeba • Capabilities managed by user processes

7. Amoeba Software architecture (cont’d) • Objects implemented by server processes (managers) • Server port used to locate the appropriate server process • RPCs: requests and replies delivered to authorized processes • Objects - System level identification: capabilities - User level identification: human-sensible hierarchical naming scheme - Directory server: mapping of ASCII path names onto capabilities • File server: Bullet server (faster than a speeding Bullet) storing immutable files as contiguous byte strings on disk and in its cache • Amoeba kernel: memory segments management, multiple-threads processes and their interactions • Process-management facilities: remote process creation, debugging, checkpointing, migration

8. Amoeba Software architecture (cont’d) • Other services (directory service) provided by user-level processes: flexible system with high performance • Amoeba design: avoiding concessions to existing OS and software • Ajax: Unix emulation service developed for running existing software on Amoeba

9. Communication in Amoeba • Amoeba’s conceptual model is that of a client thread performing operations on objects. • A client sends a request message to the service that manages the object • A server thread accepts the message,carries out the request, and sends a reply message back to the client. • Multiple server processes jointly manage a collection of objects of the same type to provide the service for fault tolerance and performance.

10. Remote Procedure Calls • The kernel provides three basic system calls • GetRequest: used by servers to announce their willingness to accept messages addressed to a specific port. • SendReply: used by servers, to send back replies. • DoOperation: sending a message to a server and then blocking until a reply comes back

11. Remote Procedure Calls • user-oriented interface built on top of three system calls, to allow users to think directly in terms of objects and operations on these objects. • Classes can be composed hierarchically, that is, a class may contain the operations from one or more underlying classes. • This multiple inheritance mechanism allows many services to inherit the same interfaces for simple object manipulations, such as for changing the protection properties on an object, or deleting an object.

12. RPC Transport • The Amoeba Interface Language(AIL) compiler generates code to marshal or unmarshal the parameters of remote procedure calls into and out of message buffers and then call the Amoeba’s transport mechanism for the delivery of request and reply messages • Messages consist of two parts, a header and a buffer. • The header has a fixed format and contains addressing information, an operation code which selects the function to be called on the object, and some space for additional parameters.

13. RPC Transport Continued… • The buffer can contain data. • With this setup, marshalling the file data takes zero time, because the data can be transmitted directly from and to the arguments specified by the program.

14. Locating Objects • Before a request for an operation on an object can be delivered to a server thread that manages the object, the location of such a thread must be found • All capabilities contain a Service Port field, which identifies the service that manages the object the capability refers to. • When a server thread makes a GetRequest call,it provides its service port to the kernel, which records it in an internal table. • When a client thread call DoOperation, it is the kernels job to find a server thread with an outstanding GetRequest that matches the port in the capability provided by the client.

15. Locating Objects Continued… • In a wide area network, a slightly different scheme is used, each server wishing to export its service sends a special message to all the domains in which it wants its service known. • In each such domain, a dummy process, called a server agent is created, which does a GetRequest using the server’s port and then lies dormant until a request comes in, at which time it forwards the message to the server for processing.

16. Performance of Amoeba RPC • We booted the Amoeba kernel on two 16.7 MHz Motorola 68020’s and created auser process on each and let them communicate over a 10 Mbps Ethernet. • For just a header, the complete RPC took 1.4 msec. • With 8K of data it took 13.1 msec, and with 30K it took 44.0 msec. • The latter corresponds to a throughput of 5.4 megabits/sec, which is half the theoretical capacity of the Ethernet, and much higher than most other systems achieve.

17. The Amoeba File System • Capabilities form the low-level naming mechanism of Amoeba • Extra level of mapping provided from human sensible hierarchical path names to capabilities. • Directory Server • The Hierarchical Directory Structure • Directory as a set of (names, capabilities) pair. • Lookup (DirCap, ObjectName) • Enter (DirCap, ObjectName, ObjectCap) • Delete (DirCap, ObjectName)

18. Amoeba File System - Cntd • Complex sharing • directory as n+1 column table with ASCII names in column 0 and capabilities in column 1 through n • The Bullet Server • Support only three principal operations • ReadFile • CreateFile • DeleteFile

19. Amoeba File System - Cntd • All files are immutable • Advantage: Final file size is known • Disadvantage: Segmentation • Reliability • Directory Server has a crucial role • Up & Running: Replication of data • Trusted to work correctly: Encryption • Techniques:Fault Tolerant Database Systems

20. Process Management • Amoeba processes can have multiple threads of control • A process consists of a segmented virtual address space and one or more threads • Processes can be remotely created, destroyed, checkpointed, migrated and debugged • Processes have explicit control over their address space • adding and removing of new segments

21. Process Management - Cntd • Process created by sending a process descriptor to a kernel in an execute process request • A process consists of

22. Process Management - Cntd • Main System calls in Amoeba • DoOperation • GetRequest • Processes can be in two states • Running • Stunned

23. Memory Management in Amoeba • Process is entirely memory resident to run • extremely high transfer rates for large RPC’s are possible. • Each segment is contiguosly stored in memory • Design is helpful for performance, simplicity and economics • Not having to page or swap makes the design considerably simpler and makes the kernel smaller and more manageable • Large memories will substantially reduce the need for paging and swapping, namely to fit large programs into small machines

24. Unix Emulation • The emulation facility does the work by calling the bullet server, directory server and the Amoeba Process Management facilities • Initially implemented system calls: open , close, dup, read, write, lseek • Session server was developed to allocate Unix PIDs,PPIDs and assist in the handling of system calls involving(fork, exec, signal, kill, UNIX pipes etc) • The X window system ported in Amoeba

25. Conclusion • The concept of Distributed Operating system without attempting to restrict to existing operating systems • It was remarkably easy to port all the Unix software to use in Amoeba • Use of Objects and capabilities • The design to build directly on the hardware • Amoeba kernel is small and simple • The few operations that are implemented by Amoeba kernel are versatile and simple to use.

26. Questions ? & Comments !