Distributed Systems RPC and Review May 31 2000

Distributed Systems RPC and Review May 31, 2000 Instructor: Gary Kimura

Today’s Topics • • Distributed Systems RPC Review Class evaluation 12/26/2021 2

Distributed Systems • Nearly all systems today are distributed in some way, e. g. : – – – – 12/26/2021 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) 12/26/2021 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 12/26/2021 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. 12/26/2021 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. 12/26/2021 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 12/26/2021 8

Some Issues in Distributed Systems • • Transparency (how visible is the distribution) Security Reliability Performance Scalability Programming models Communications models 12/26/2021 9

Transparency • In a true distributed system with transparency: – – 12/26/2021 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 12/26/2021 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. 12/26/2021 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. 12/26/2021 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 12/26/2021 14

(Remote) Procedure Call • So, we would like to use procedure call as a model for distributed communication. • Lots of issues: – – – 12/26/2021 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 12/26/2021 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 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. 12/26/2021 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. 12/26/2021 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. 12/26/2021 19

Review • • • 12/26/2021 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 12/26/2021 21