Transcript Distributed Systems, RPC, and Recap

Distributed Systems
RPC
and
Review
May 31, 2000
Instructor: Gary Kimura
Today’s Topics
•
•
•
•
Distributed Systems
RPC
Review
Class evaluation
3/28/2016
2
Distributed Systems
• Nearly all systems today are distributed in some way,
e.g.:
–
–
–
–
–
–
–
3/28/2016
they use email
they access files over a network
they access printers over a network
they are backed up over a network
they share other physical or logical resources
they cooperate with other people on other machines
soon: they receive video, audio, etc.
3
Why use distributed systems?
• Distributed systems are now a requirement:
– economics dictate that we buy small computers
– everyone needs to communicate
– we need to share physical devices (printers) as well as
information (files, etc.)
– many applications are by their nature distributed (bank teller
machines, airline reservations, ticket purchasing)
– in the future, to solve the largest problems, we will need to get
large collections of small machines to cooperate together
(parallel programming)
3/28/2016
4
What is a distributed system?
• There are several levels of distribution.
• Earliest systems used simple explicit network programs:
–
–
–
–
FTP: file transfer program
Telnet (rlogin): remote login program
mail
remote job entry (or rsh): run jobs remotely
• Each system was a completely autonomous
independent system, connected to others on the network
3/28/2016
5
Loosely-Coupled Systems
•
•
•
•
•
•
•
Most distributed systems are “loosely-coupled:
Each CPU runs an independent autonomous OS.
Hosts communicate through message passing.
Computer don’t really trust each other.
Some resources are shared, but most are not.
The system may look differently from different hosts.
Typically, communication times are long.
3/28/2016
6
Closely-Coupled Systems
• A distributed system becomes more “closely coupled” as it:
–
–
–
–
–
appears more uniform in nature
runs a “single” operating system
has a single security domain
shares all logical resources (e.g., files)
shares all physical resources (CPUs, memory, disks, printers, etc.)
• In the limit, a distributed system looks to the user as if it
were a centralized timesharing system, except that it’s
constructed out of a distributed collection of hardware and
software components.
3/28/2016
7
Tightly-Coupled Systems
• A “tightly-coupled” system usually refers to a multiprocessor.
– Runs a single copy of the OS with a single job queue
– has a single address space
– usually has a single bus or backplane to which all processors and
memories are connected
– has very low communication latency
– processors communicate through shared memory
3/28/2016
8
Some Issues in Distributed Systems
•
•
•
•
•
•
•
Transparency (how visible is the distribution)
Security
Reliability
Performance
Scalability
Programming models
Communications models
3/28/2016
9
Transparency
• In a true distributed system with transparency:
–
–
–
–
3/28/2016
it would appear as a single system
different modes would be invisible
jobs would migrate automatically from node to node
a job on one node would be able to use memory on another
10
Distribution and the OS
• There are various issues that the OS must deal with:
– how to provide efficient network communication
– what protocols to use
– what is the application interface to remote apps (although this
might be a language issue)
– protection of distributed resources
3/28/2016
11
Remote Procedure Call
Clients and Servers
• A common model for structuring distributed
•
•
•
•
•
computation is via the client/server paradigm
A server is a program (or collection of programs) that
provide some service, e.g., file service, name service,
…
The server may exist on one or more nodes.
A client is a program that uses the service.
A client first binds to the server, I.e., locates it in the
network and establishes a connection.
The client then sends requests to perform actions; this
is done by sending messages that indicate which
service is desired, along with params. The server
returns a response.
3/28/2016
12
The Problem with Messages
• While messages provide very flexible communication,
they also have certain problems:
– requires that programmer worry about message formats
– messages must be packed and unpacked
– messages have to be decoded by server to figure out what is
requested
– messages are often asynchronous
– they may require special error handling functions
• Basically, messages are not a natural programming
model for most programmers.
3/28/2016
13
Procedure Call
• A more natural way to communicate is through
procedure call:
– every language supports it
– semantics are well defined and understood
– natural for programmers to use
• Basic idea: let’s just define a server as a module that
exports a set of procedures that can be called by
client programs.
• To use the server, the client just does a procedure
call, as if it were linked with the server
Client
call
Server
return
3/28/2016
14
(Remote) Procedure Call
• So, we would like to use procedure call as a model for
distributed communication.
• Lots of issues:
–
–
–
–
–
3/28/2016
how do we make this invisible to the programmer?
what are the semantics of parameter passing?
how is binding done (locating the server)?
how do we support heterogeneity (OS, arch., language)
etc.
15
Remote Procedure Call
• The basic model for Remote Procedure Call (RPC)
was described by Birrell and Nelson in 1980, based
on work done at Xerox PARC.
• Goals was to make RPC look as much like local PC
as possible.
• Used computer/language support.
• There are 3 components on each side:
– a user program (client or server)
– a set of stub procedures
– RPC runtime support
3/28/2016
16
RPC
• Basic process for building a server:
– Server program defines the server’s interface using an
interface definition language (IDL)
– The IDL specifies the names, parameters, and types for all
client-callable server procedures
– A stub compiler reads the IDL and produces two stub
procedures for each server procedure: a client-side stub and
a server-side stub
– The server writer writes the server and links it with the serverside stubs; the client writes her program and links it with the
client-side stubs.
– The stubs are responsible for managing all details of the
remote communication between client and server.
3/28/2016
17
RPC Stubs
• Basically, a client-side stub is a procedure that looks
•
•
•
•
to the client as if it were a callable server procedure.
A server-side stub looks to the server as if it’s a calling
client.
The client program thinks it is calling the server; in
fact, it’s calling the client stub.
The server program thinks it’s called by the fclient; in
fact, it’s called by the server stub.
The stubs send messages to each other to make the
RPC happen.
3/28/2016
18
RPC Issues
• RPC Binding - Binding is the process of connecting
the client and server
• RPC Marshalling - Marshalling is the packing of
procedure parameters into a message packet.
3/28/2016
19
Review
•
•
•
•
•
•
•
•
•
3/28/2016
What is an OS and what are the major components
and design (monolithic versus layered)
Architectural support for an OS
Processes
Threads
Scheduling
Synchronization
Deadlocks
Shared versus exclusive resources
Argument validation
20
Review (Continued)
•
•
•
•
•
•
•
Memory management
Paging and segmentation
Disk drivers
I/O Systems
File Systems
Software Caching
Accounting, protection, and security
3/28/2016
21