1 / 21

Distributed Systems RPC and Review

Distributed Systems RPC and Review. May 31, 2000 Instructor: Gary Kimura. Today’s Topics. Distributed Systems RPC Review Class evaluation. Distributed Systems. Nearly all systems today are distributed in some way, e.g.: they use email they access files over a network

quasim
Télécharger la présentation

Distributed Systems RPC and Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed SystemsRPCandReview May 31, 2000 Instructor: Gary Kimura

  2. Today’s Topics • Distributed Systems • RPC • Review • Class evaluation

  3. Distributed Systems • Nearly all systems today are distributed in some way, e.g.: • 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.

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

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

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

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

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

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

  10. Transparency • In a true distributed system with transparency: • 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

  11. 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. Remote Procedure CallClients 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.

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

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

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

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

  17. 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 server-side 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.

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

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

  20. Review • 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

  21. Review (Continued) • Memory management • Paging and segmentation • Disk drivers • I/O Systems • File Systems • Software Caching • Accounting, protection, and security

More Related