Transcript No Slide Title

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