Ameoba

1. Ameoba Designed by: Prof Andrew S. Tanenbaum at Vrija University since 1981

2. Ameoba Design Philosophy • Computers are rapidly becoming cheaper and faster • Widespread use and increasing performance in computer networks • Need for the ability to deal with physically distributed hardware while using logically centralized software

3. Ameoba Design Philosophy Cont. • Provide users with the illusion of a single powerful timesharing system from a collection of machines

4. Ameoba Distributed System Goals • Small • Simple to use • Scalable to large numbers of processors • Degree of Fault-Tolerance • High Performance • Possibility for parallelism • Transparent to Users

5. User logs into system as a whole System decides best place to run program Single, system-wide object naming service User logs into one specific machine Program executes on home machine unless specified Files local unless a remote file system mounted Difference between Ameoba and Network OS Ameoba Network OS

6. System Architecture • Workstations • Processor Pool • Specialized Servers (file, data base, ect) • Gateway

7. System Architecture

8. Workstations • One Per User • Users carry out editing and other tasks • Can be Suns, IBM PC/AT clones, and X terminals

9. Processor Pool • Group of CPU’s • CPU can be dynamically allocated and returned to the pool • Offers possibility of doing many jobs in parallel

10. Specialized Servers • Directory Servers • File Servers and Replicates • Boot Servers • Other Specialized Functions

11. Gateways • Link Amoeba systems at different sites into a single, uniform system • Isolate Amoeba from peculiarities of the protocols that must be used over WAN’s

12. Ameoba Kernal • All Amoeba machines run the same kernal • Provides multithreaded process, communication services, and little else • Goal is to keep kernal as small as possible to enhance reliability and allow OS to run as user processes

13. Objects • Ameoba is object-based • Uses capabilities for accessing objects • System can be viewed as a collection of objects • Both hardware and software objects exist

14. Capabilities • Key that allows holder to perform some (not necessarily all) operations on an object • Each user process owns a collection of capabilities, which define the objects it may access and the types of operations it may perform on each • Capabilities provide a unified mechanism for naming, accessing and protecting objects

15. Remote Procedure Call • Object-based model implemented using RPC’s • Associated with each object is a server process that manages the object • User processes send a request message to the server that manages an object • The request message contains a capability for the object, the operation to be performed, and any parameters

16. Remote Proceedure Call Cont. • The user process blocks while waiting for the call to complete • When complete, the server sends back a reply message that unblocks the user process • Sending a request message, blocking, and accepting a reply message forms the RPC, which can be encapsulated using stub routines

17. Remote Procedure CallCont. • RPC based on 4 primitives • RPC interface built on top the Fast Local Internet Protocol(FLIP). • FLIP provides automatic shortest path routing of messages and provides automatic gatewaying between connected networks

18. RPC Primitives • getreq • putreq • tans • timeout

19. getreq • Used by servers • Once server has initialized itself, it performs a getreq operation with the port it wishes to listen to • getreq blocks server until a client sends a request using trans • when a request arrives, the server checks that the capability is valid and has sufficient rights

20. putreq • When the server completes an operation, it sends a reply to client using putreq

21. trans • Used by clients to send requests to servers • Port of server is the first parameter to trans • trans call blocks until server sends reply • kernel on which trans is executed attemps to locate the server by broadcasting a message with the port in it

22. Trans (cont.) • If another kernel has a server waiting for a request on that port, it responds and the RPC is sent to the server which handles the request and returns a reply • The kernel keeps a cache of known locations of ports to improve performance for subsequent RPCs • trans is not called directly by clients, but imbedded in a proc call that handles the marshaling and sending of data

23. timeout • Used to set the amount of time spent searching for the server when doing a transaction • default timeout is 5 seconds

24. Client/Server Coding • Not necessary to write server loop and client stub code yourself • AIL(Amoeba Interface Language) generates this code automatically • servers can be multithreaded but don’t have to be

25. Directories • File names not implemented by the file server • Many more object types than files, so a general naming service is required • Directory Server implements naming service by implementing an arbitrary directed graph of directories

26. Directories Cont. • Directory object is a list of (ASCII string, capability-set) pairs • Extra degree of fault tolerance is achieved by duplication the directory server • The two servers communicate with each other to keep the data about directories consistent

27. Files • File server is known as a Bullet Server • Uses a vary large buffer cache and stores file contiguously, both in core and on disk to give a very high performance • Bullet server files are immutable(once created cannot be changed) • Files created automically(do not officially exist until commited)

28. Amoeba and POSIX Emulation • POSIX emulation library provides reasonable source code compatibility • This provides Amoeba with a reasonable programming environment and simplifies the migration of software and staff from UNIX-like systems

29. Conclusion • Amoeba was designed to provide a transparent distributed system • Still undergoing development, but current version goes a long way towards satisfying the design goals • POSIX emulation has provided a ready-made programming environment