Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Networking Operating Systems (CO32010) 3.1 Introduction 2. Processes 3.2 Interprocess communication and 3.3 Flags and semaphores scheduling 3.4 RPC 3.5 Multi-processor systems Exercises 1.3.6 Operating Systems 7. Encryption 6. Routers 3. Distributed processing Objectives: • To define the concept of distributed processing, and contrast centralized systems against distributed ones. 8. NT, UNIX control, such as • To define mechanisms of interprocess andand NetWare pipes, semaphores, flags, 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 4. Distributed Algorithm. 5.Banker’s Routing • Toprotocols outline practical interprocess control protocols, file systems especially RPC. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.1 Centralised v. Distributed Distributed: Decision making Account management Logistics Head Office Customers Staff Logistics Regional Office Local Office ATM http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.2 Client/server architecture Client requests a remote process and passes process parameters Network Server runs process and returns the results to the client http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.3 IPC methods Connection over a network over locally Process A Process A Process A Shared memory Process A Sleep until ready Process B Process A Process B 3. Shared memory Process A | Process B http://www.soc.napier.ac.uk/~bill/nos.html 1. Socket 2. Semaphores Message queue Gets access Resource to resource and increments a semaphore (wait) Process B Process B Process B 5. Message queue 4. Pipe bill@napier, 2002 3.4 Semaphore usage in a program Process A Semaphore 1 wait (); Wait decrements the semaphore 0 code that must be mutually exclusive signal (); Process B will go to sleep as the semaphore has a zero value Process B wait (); 1 Signal increments the semaphore Process B will wake up when the semaphore value becomes a non-zero http://www.soc.napier.ac.uk/~bill/nos.html code that must be mutually exclusive signal (); bill@napier, 2002 3.5 Consumer-producer example #define MAX_BUFF 100 int buffer_count=0; /* /* maximum items in buffer */ 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 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); consume_item(); /*remove item*/ } } http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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-preemptive, 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.7 Analogy to deadlock C B A D E F http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.7 Analogy to deadlock Circular wait condition Mutual exclusion condition and no pre-emption. None of cars will give up their exclusive access to the Junction. C B A D E F http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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): Process Current allocation Maximum allocation required A 40 50 B 20 40 C 20 60 D 10 40 Resource unallocated 10 http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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: Process Current allocation Maximum allocation required A 15 50 B 30 40 C 45 60 D 0 40 Resource unallocated 5 http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.12 RPC Application Application program program Remote Remote process process Session layer (RPC) supports the running of remote processes and passing run parameters and results Transport layer sets up a virtual connection, and streams data Network layer responsible for the routing data over the network and delivering it at the destination Application program Application Application Presentation Presentation Session Session RPC Transport Transport TCP/IP UDP/IP Network Network Network Data DataLink Link Physical Physical Ethernet/ISDN/ FDDI/ATM/etc Data link http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 3.13 RPC operation Server Client The caller process sends a call message, with all the procedure’s parameters Server process waits for a call Process, and parameters Server reads parameters and runs the process Caller process waits for a response The caller process sends a call message, with all the procedure’s parameters Server sends results to the client Results http://www.soc.napier.ac.uk/~bill/nos.html Server process waits for a call bill@napier, 2002 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). http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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 ‘[email protected]’) instead of by an operating system specific integer. These network names are unique on the Internet. For example [email protected] identifies user ID number 111 on the mycomputer.net system. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 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. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 RPC highest level programming #include <stdio.h> 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); } http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 RPC middle level programming #include <stdio.h> #include <rpc.h> #define RUSERSPROG 10002 /* Program number #define RUSERSVERSION 2 /* Version number #define RUSERPROCVAL 1 /* 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); } http://www.soc.napier.ac.uk/~bill/nos.html */ */ bill@napier, 2002 RPC lowest level programming #include <stdio.h> #include <rpc.h> #define RUSERSPROG 10002 #define RUSERSVERSION 2 #define RUSERPROCVAL 1 /* Program number /* Version number /* Procedure number */ */ */ char *nuser(); int main(void) { registerrpc(RUSERSPROG, RUSERSVERS, RUSERSPROC_NUM, nuser, xdr_void, xdr_u_long); svc_run(); fprintf(stderr, "Error: server terminated\n"); return(1); } http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002 RPC lowest level programming Sample contents of /etc/rpc file: portmapper rstatd rusersd nfs ypserv 100000 100001 100002 100003 100004 portmap sunrpc rstat rstat_svc rup perfmeter rusers nfsprog ypprog This shows RPC process name, and RPC procedure number. http://www.soc.napier.ac.uk/~bill/nos.html bill@napier, 2002