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

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

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

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

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

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

7. System Architecture

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

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

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

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

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

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

14. Capabilities n Key that allows holder to perform some (not necessarily all) operations on an object n 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 n Capabilities provide a unified mechanism for naming, accessing and protecting objects

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

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

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

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

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

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

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

22. Trans (cont.) n 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 n The kernel keeps a cache of known locations of ports to improve performance for subsequent RPCs n trans is not called directly by clients, but imbedded in a proc call that handles the marshaling and sending of data

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

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

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

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

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

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

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