DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 22 Client-Server

This preview shows page 1-2-3-4-5 out of 15 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 15 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Page 1 CS162!Operating Systems and!Systems Programming!Lecture 22!Client-Server"April 18, 2011!Ion Stoica!http://inst.eecs.berkeley.edu/~cs162!Lec 22.2!4/18! Ion Stoica CS162 ©UCB Spring 2011!Distributed Systems are Everywhere!"• We need (want?) to share physical devices (e.g., printers) and information (e.g., files)!• Many applications are distributed in nature (e.g., ATM machines, airline reservations)!• Many large problems can be solved by decomposing smaller problems that run in parallel (e.g., MapReduce, SETI@home)!• Next three lectures: go over three distributed system models!– Client-server!– Peer-to-peer!– Cloud(cluster) computing!Lec 22.3!4/18! Ion Stoica CS162 ©UCB Spring 2011!Client-Server"• One or more clients interacting with one or more servers providing a service, e.g.,!– Web!– E-mail, chat!– Printer!– Airline reservation!– On-line shopping!– Store/streaming video, audio, and/or photos!– …!• In this lecture!– End-to-end message communication!– Remote Procedure Calls!– Two phase commit transactions!– World Wide Web!Lec 22.4!4/18! Ion Stoica CS162 ©UCB Spring 2011!Message Passing"• Process A (e.g., client) sends a packet to process B (e.g., server)!16.25.31.10 128.15.11.12 Proc. A (port 10) Proc. B (port 7) InternetPage 2 Lec 22.5!4/18! Ion Stoica CS162 ©UCB Spring 2011!Message Passing Details"16.25.31.10 128.15.11.12 Proc. A (port 10) Internet Proc. B (port 7) Transport Network Datalink Physical Proc. A (port 10) Proc. B (port 7) Transport Network Datalink Physical data 16.25.31.10 128.15.11.12 data 10 7 data 10 7 16.25.31.10 128.15.11.12 data data data 10 7 10 7 Internet 16.25.31.10 128.15.11.12 Lec 22.6!4/18! Ion Stoica CS162 ©UCB Spring 2011!From Message Passing to Remote Procedure Call"• Raw messaging is a bit too low-level for programming!• Another option: Remote Procedure Call (RPC)!– Looks like a local procedure call on client!– Translated automatically into a procedure call on remote machine (server) • Implementation:!– Uses request/response message passing “under the covers”!Lec 22.7!4/18! Ion Stoica CS162 ©UCB Spring 2011!Example: Local Procedure Call"."."."n = sum(4, 7);"."."."sum(i, j)"int i, j;"{" return (i+j);"}"Machine"Process"Lec 22.8!4/18! Ion Stoica CS162 ©UCB Spring 2011!Remote Procedure Call"• Transparently invoke a procedure (services) implemented in a different address space either on the same machine or a different machine!– Services can be run wherever itʼs most appropriate!– Access to local and remote services looks the same!• Challenges:!– Argument (parameter) passing, potentially across different architectures!– Discover where the service is located!– Handle failures transparently"Page 3 Lec 22.9!4/18! Ion Stoica CS162 ©UCB Spring 2011!RPC: Argument Passing"• Client and server use “stubs” to glue pieces together!– Client-side stub is responsible for “marshalling” arguments and “unmarshalling” the return values!– Server-side stub is responsible for “unmarshalling” arguments and “marshalling” the return values!• Marshalling involves (depending on system) converting values to a canonical form, serializing objects, copying arguments passed by reference, etc.!– Needs to account for cross-language and cross-platform issues !• Technique: compiler generated stubs!– Input: interface definition language (IDL)!» Contains, among other things, types of arguments/return!– Output: stub code in the appropriate source language!Lec 22.10!4/18! Ion Stoica CS162 ©UCB Spring 2011!RPC Information Flow"Client"(caller)"Server"(callee)"Packet"Handler"Packet"Handler"call"return"send"receive"send"receive"return"call"Network"Network"Client"Stub"bundle"args"bundle"ret vals"unbundle"ret vals"Server"Stub"unbundle"args"Machine A"Machine B"Lec 22.11!4/18! Ion Stoica CS162 ©UCB Spring 2011!Example: Remote Procedure Call"."."."n = sum(4, 7);"."."."sum(i, j)"int i, j;"{" return (i+j);"}"Client"Process"sum"4"7"message"OS"Server"Process"sum"4"7"message"OS"Stubs "Lec 22.12!4/18! Ion Stoica CS162 ©UCB Spring 2011!Client and Server Stubs"• Principle of RPC between a client and server program.!Page 4 Lec 22.13!4/18! Ion Stoica CS162 ©UCB Spring 2011!Encoding"• Server and client may encode arguments differently, e.g.,!– Big-endian: store from most-to-least significant byte!– Little-endian: store from least-to-most significant byte!a) Original message on x86 (e.g., little endian)!b) The message after receipt on the SPARC (e.g., big endian)!c) The message after being inverted. (The little numbers in boxes indicate the address of each byte)!Lec 22.14!4/18! Ion Stoica CS162 ©UCB Spring 2011!Parameter Specification and Stub Generation"a) A procedure!b) The corresponding message.!Lec 22.15!4/18! Ion Stoica CS162 ©UCB Spring 2011!Service Discovery: RPC Binding"• How does client know which machine to send RPC?!– Need to translate name of remote service into network endpoint (e.g., host:port)!– Binding: the process of converting a user-visible name into a network endpoint!» Static: fixed at compile time!» Dynamic: performed at runtime!• Dynamic Binding!– Most RPC systems use dynamic binding via name service!– Why dynamic binding?!» Access control: check who is permitted to access service!» Fail-over: If server fails, use a different one!Lec 22.16!4/18! Ion Stoica CS162 ©UCB Spring 2011!Example of RPC Binding"• Distributed Computing Environment (DCE) framework!• DCE daemon: !– Allow local services to record their services locally!– Resolve service name to local end-point (i.e., port) !• Directory machine: resolve service name to DCE daemon (host:portʼ) on machine running the service !Page 5 Lec 22.17!4/18! Ion Stoica CS162 ©UCB Spring 2011!RPC Semantics in the Presence of Failures"• The client is unable to locate the server!• The request message from the client to server is lost!• The reply message from the server is lost!• The server crashes after receiving a request!• The client crashes after sending a request!Lec 22.18!4/18! Ion Stoica CS162 ©UCB Spring 2011!Client is Unable to Locate Server"• Causes: server down, different version of server binary, …!• Fixes!– Return


View Full Document

Berkeley COMPSCI 162 - Lecture 22 Client-Server

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 22 Client-Server
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 22 Client-Server and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 22 Client-Server 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?