1. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html Networking Operating Systems (CO32010) 1. Operating Systems 2. Processes and scheduling 4. Distributed file systems 5. Routing protocols 6. Routers 7. Encryption 8. NT, UNIX and NetWare 3.1Introduction 3.2Interprocess communication 3.3Flags and semaphores 3.4RPC 3.5Multi-processor systems 3.6Exercises Objectives: To define the concept of distributed processing, and contrast centralized systems against distributed ones. To define mechanisms of interprocess control, such as pipes, semaphores, flags, and message queues. To define, in detail, how semaphores are used, and how the can prevent deadlock. To define the conditions for deadlock. To outline algorithms to prevent deadlock, such as the Banker ’ s Algorithm. To outline practical interprocess control protocols, especially RPC. Objectives: To define the concept of distributed processing, and contrast centralized systems against distributed ones. To define mechanisms of interprocess control, such as pipes, semaphores, flags, and message queues. To define, in detail, how semaphores are used, and how the can prevent deadlock. To define the conditions for deadlock. To outline algorithms to prevent deadlock, such as the Banker ’ s Algorithm. To outline practical interprocess control protocols, especially RPC. 3. Distributed processing

2. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.1 Centralised v. Distributed Head Office Regional Office Local Office ATM Customers Staff Logistics Distributed: Decision making Account management Logistics

3. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html Network Client requests a remote process and passes process parameters Server runs process and returns the results to the client 3.2 Client/server architecture

4. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html Process A Process A Shared memory Shared memory Process A Process A Process B Process B Process B Process B 1. Socket 2. Semaphores 3. Shared memory Resource Process A Process A Process B Process B Sleep until ready Gets access to resource and increments a semaphore (wait) Process A Process A Process B Process B 4. Pipe Process A | Process B Connection over a network over locally 3.3 IPC methods Message queue Message queue Process A Process A Process B Process B 5. Message queue

5. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html wait (); code that must be mutually exclusive signal (); wait (); code that must be mutually exclusive signal (); 0 0 1 1 1 1 Wait decrements the semaphore Signal increments the semaphore wait (); code that must be mutually exclusive signal (); wait (); code that must be mutually exclusive signal (); Process B will go to sleep as the semaphore has a zero value Process A Process B Process B will wake up when the semaphore value becomes a non-zero Semaphore 3.4 Semaphore usage in a program

6. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html #define MAX_BUFF 100 /*maximum items in buffer*/ int buffer_count=0; /*current number of items in buffer*/ void producer_buffer(void) { while (TRUE){/*Infinite loop */ put_item(); /*Put item*/ if (buffer_count==MAX_BUFF) sleep(); /*Sleep, if buffer full */ enter_item(); /*Add item to buffer*/ buffer_count = buffer_count + 1; /*Increment number of items in the buffer */ if (buffer_count==1) wakeup(consumer);/*was buffer empty?*/ } void consumer_buffer(void) { while (TRUE) {/*Infinite loop */ if (buffer_count==0) sleep(); /* Sleep, if buffer empty */ get_item(); /* Get item*/ buffer_count = buffer_count - 1; /* Decrement number of items in the buffer*/ if (buffer_count==MAX_BUFF-1) wakeup(producer_buffer); /* if buffer not full anymore, wake up producer*/ consume_item(); /*remove item*/ } 3.5 Consumer-producer example

7. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.6 Deadlock Resource locking. This is where a process is waiting for a resource which will never become available. Some resources are pre-emptive, where processes can release their access on them, and give other processes a chance to access them. Others, though, are non-pre- emptive, and processes are given full rights to them. No other processes can then get access to them until the currently assigned process is finished with them. An example of this is with the transmission and reception of data on a communication system. It would not be a good idea for a process to send some data that required data to be received, in return, to yield to another process which also wanted to send and receive data. Starvation. This is where other processes are run, and the deadlocked process is not given enough time to catch the required event. This can occur when processes have a low priority compared with other ones, as higher priority tasks tend to have a better chance to access the required resources.

8. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.7 Analogy to deadlock C F A B D E

9. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.8 Four conditions for deadlock Mutual exclusion condition. This is where processes get exclusive control of required resources, and will not yield the resource to any other process. Wait for condition. This is where processes keep exclusive control of acquired resources while waiting for additional resources. No pre-emption condition. This is where resources cannot be removed from the processes which have gained them, until they have completed their access on them. Circular wait condition. This is a circular chain of processes on which each process holds one or more resources that are requested by the next process in the chain.

10. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.7 Analogy to deadlock C F A B D E Circular wait condition Mutual exclusion condition and no pre-emption. None of cars will give up their exclusive access to the Junction.

11. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.9 Banker’s Algorithm (Safe condition) Process A requires a maximum of 50MB. Process B requires a maximum of 40MB. Process C requires a maximum of 60MB. Process D requires a maximum of 40MB. The current state would be safe as Process A can complete which releases 50 MB (which allows the other processes to complete): ProcessCurrent allocationMaximum allocation required A4050 B2040 C2060 D1040 Resource unallocated10

12. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.10 Banker’s Algorithm(Unsafe condition) Process A requires a maximum of 50MB. Process B requires a maximum of 40MB. Process C requires a maximum of 60MB. Process D requires a maximum of 40MB. The current state would be unsafe as no process can complete: ProcessCurrent allocationMaximum allocation required A1550 B3040 C4560 D040 Resource unallocated5

13. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.11 Banker’s Algorithm Each resource has exclusive access to resources that have been granted to it. Allocation is only granted if there is enough allocation left for at least one process to complete, and release its allocated resources. Processes which have a rejection on a requested resource must wait until some resources have been released, and that the allocated resource must stay in the safe region. Problems: Requires processes to define their maximum resource requirement. Requires the system to define the maximum amount of a resource. Requires a maximum amount of processes. Requires that processes return their resources in a finite time. Processes must wait for allocations to become available. A slow process may stop many other processes from running as it hogs the allocation.

14. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html 3.12 RPC

15. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html The caller process sends a call message, with all the procedure’s parameters Client Server reads parameters and runs the process Server Caller process waits for a response Server process waits for a call The caller process sends a call message, with all the procedure’s parameters Process, and parameters Server sends results to the client Results Server process waits for a call 3.13 RPC operation

16. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC RPC provides: A unique specification of the called procedure. A mechanism for matching response parameters with request messages. Authentication of both callers and servers. The call message has two authentication fields (the credentials and verifier), and the reply message has one authentication field (the response verifier). Protocol errors/messages (such as incorrect versions, errors in procedure parameters, indication on why a process failed and reasons for incorrect authentication).

17. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC RPC provides three fields which define the called procedure: Remote program number. These are numbers which are defined by a central authority (like Sun Microsystems). Remote program version number. This defines the version number, and allows for migration of the protocol, where older versions are still supported. Different versions can possibly support different message calls. The server must be able to cope with this. Remote procedure number. This identifies the called procedure, and is defined in the specification of the specific program’s protocol. For example, file service may define that an 8 defines a read operation and a 10 defines a write operation.

18. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC RPC call message format: Message type. This is either CALL (0) or REPLY (1). Message status. There are two different message status fields, depending on whether it is a CALL or a REPLY. Rpcvers. RPC Version number (unsigned integer). Prog, vers and proc. Specifies the remote program, its version number and the procedure within the remote program (all unsigned integers). Cred. Authentication credentials. Verf. Authentication verifier. Procedure specific parameters.

19. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC authentications RPC authentication No authentication (AUTH_NULL). No authentication is made when callers do not know who they are or when the server does not care who the caller is. This type of method would be used on a system that did not have external connections to networks, and assumes that all the callers are valid. Unix authentication (AUTH_UNIX). Unix authentication uses the Unix authentication system, which generates a data structure with a stamp (an arbitrary ID which the caller machine may generate), machine name (such as ‘Apollo’), UID (caller’s effective user ID), GID (the caller’s effective group ID) and GIDS (an array of groups which contain the caller as a member). Short authentication (AUTH_SHORT). DES authentication (AUTH_DES). Unix authentication suffers from two problems: the naming is too Unix oriented and there is no verifier (so credentials can easily be faked). DES overcomes this by addressing the caller using its network name (such as ‘unix.111@mycomputer.net’) instead of by an operating system specific integer. These network names are unique on the Internet. For example unix.111@mycomputer.net identifies user ID number 111 on the mycomputer.net system.

20. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC programming RPC programming levels: Highest layer. At this level the calls are totally transparent to the operating system, the computer type and the network. With this the programmer simply calls the required library routine, and does not have to worry about any of the underlying computer type, operating system or networking. For example, the rnusers routine returns the number of users on a remote computer (as given in Program 3.2). Middle layer. At this level the programmer does not have to worry about the network connection (such as the TCP sockets), the Unix system, or other low-level implementation mechanisms. It just makes a remote procedure call to routines on other computers, and is the most common implementation as it gives increased amount of control over the RPC call. These calls are made with: registerrpc (which obtains a unique system-wide procedure identification number); callrpc (which executes a remote procedure call); and svc_run. The middle layer, in some more complex applications, does not allow for timeout specifications, choice of transport, Unix process control, or error flexibility in case of errors. If these are required, the lower layer is used. Lowest layer. At this level there is full control over the RPC call, and this can be used create robust and efficient connections.

21. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC highest level programming #include int main(int argc, char *argv[]) { int users; if (argc != 2) { fprintf(stderr, "Use: rnusers hostname\n"); return(1); } if ((users = rnusers(argv[1])) < 0) { fprintf(stderr, "Error: rnusers\n"); exit(-1); } printf("There are %d users on %s\n", users, argv[1]); return(0); }

22. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC middle level programming #include #define RUSERSPROG 10002/* Program number*/ #define RUSERSVERSION 2/* Version number*/ #define RUSERPROCVAL1/* Procedure number*/ int main(int argc, char *argv[]) { unsigned long users; int rtn; if (argc != 2) { fprintf(stderr, "Use: nusers hostname\n"); exit(-1); } if (rtn = callrpc(argv[1], RUSERSPROG, RUSERSVERSION, RUSERSPROCVAL, xdr_void, 0, xdr_u_long, &users) != 0) { clnt_perrno(stat); return(1); } printf("There are %d users on %s\n", users, argv[1]); return(0); }

23. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC lowest level programming #include #define RUSERSPROG 10002/* Program number*/ #define RUSERSVERSION 2/* Version number*/ #define RUSERPROCVAL1/* Procedure number*/ char *nuser(); intmain(void) { registerrpc(RUSERSPROG, RUSERSVERS, RUSERSPROC_NUM, nuser, xdr_void, xdr_u_long); svc_run(); fprintf(stderr, "Error: server terminated\n"); return(1); }

24. bill@napier, 2002 http://www.soc.napier.ac.uk/~bill/nos.html RPC lowest level programming Sample contents of /etc/rpc file: portmapper100000portmap sunrpc rstatd100001rstat rstat_svc rup perfmeter rusersd100002rusers nfs100003nfsprog ypserv100004ypprog This shows RPC process name, and RPC procedure number.