Networking Operating Systems (CO32010)

Transcription

1 Networking Operating Systems (CO32010) 3.1 Introduction 3.2 Interprocess communication 3.3 Flags and semaphores 3.4 RPC 3.5 Multi-processor systems 1. Operating Systems 3.6 Exercises 6. Routers 7. Encryption 5. Routing protocols 2. Processes and scheduling Objectives: To define the concept of distributed processing, and contrast centralized systems against distributed ones. 8. NT, UNIX and NetWare 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 4. Distributed file systems Banker s Algorithm. To outline practical interprocess control protocols, especially RPC. 3. Distributed processing

2 3.1 Centralised v. Distributed Distributed: Decision making Account management Logistics Head Office Customers Staff Logistics Regional Office Local Office ATM

3 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

4 3.3 IPC methods Process Process A Connection over a network over locally Process Process B 1. Socket Process Process A Gets access to resource and increments a semaphore (wait) Process Process A Resource Resource Shared Shared memory memory Sleep until ready Process Process B Process Process B Process Process A 3. Shared memory 2. Semaphores Message Message queue queue Process Process B 5. Message queue Process Process A Process A Process B Process Process B 4. Pipe

5 3.4 Semaphore usage in a program Process A Wait decrements the semaphore wait wait (); (); code code that that must must be be mutually mutually exclusive exclusive signal signal (); (); Signal increments the semaphore Semaphore Process B will go to sleep as the semaphore has a zero value Process B will wake up when the semaphore value becomes a non-zero Process B wait wait (); (); code code that that must must be be mutually mutually exclusive exclusive signal signal (); ();

6 3.5 Consumer-producer example #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 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*/ } }

7 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.

8 3.7 Analogy to deadlock C A B E D F

9 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 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 A B E D F

11 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 A B C D Resource unallocated Current allocation Maximum allocation required

12 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 A B C D Resource unallocated Current allocation Maximum allocation required

13 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 3.12 RPC Application Application program program Session layer (RPC) supports the running of remote processes and passing run parameters and results Remote Remote process process Data link 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 Network Application Application Presentation Presentation Session Session Transport Transport Network Network Data Data Link Link Physical Physical Application program RPC TCP/IP UDP/IP Ethernet/ISDN/ FDDI/ATM/etc

15 3.13 RPC operation Client The The caller caller process process sends sends a a call call message, message, with with all all the the procedure s procedure s parameters parameters Caller Caller process process waits waits for for a a response response Process, and parameters Server Server Server process process waits waits for for a a call call Server Server reads reads parameters parameters and and runs runs the the process process The The caller caller process process sends sends a a call call message, message, with with all all the the Results procedure s procedure s parameters parameters Server Server sends sends results results to to the the client client Server Server process process waits waits for for a a call call

16 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 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 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 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 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 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); }

22 RPC middle level programming #include <stdio.h> #include <rpc.h> #define RUSERSPROG /* 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); }

23 RPC lowest level programming #include <stdio.h> #include <rpc.h> #define RUSERSPROG /* Program number */ #define RUSERSVERSION 2 /* Version number */ #define RUSERPROCVAL 1 /* 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); }

24 RPC lowest level programming Sample contents of /etc/rpc file: portmapper rstatd rusersd nfs ypserv portmap sunrpc rstat rstat_svc rup perfmeter rusers nfsprog ypprog This shows RPC process name, and RPC procedure number.