DOC PREVIEW
MIT 6 033 - Lecture 4: Client/server

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

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 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 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

MIT OpenCourseWare http://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.6.033 Lecture 4: Client/server Modularityhow to impose order on complex programs?break into modules [big Therac-25 blob => components, interactions]goal: decouple, narrow set of interactions Modularity (2)what form does modularity take?interactions are procedure callsC -> P, P returns to Cprocedure clarifies interface, hides implementation P(a) { ... } C() { ... y = P(x); ... } Enforced? is the interface enforced? is the implementation hidden? What actually happens when C calls P?6.004 they communicate via a shared stack, in memory [stack: regs, args, RA, P's vars, maybe args...] C: push regs, push args, push PC+1, jmp P, pop args, pop regs, ... R0P: push vars, ..., pop vars, mov xx -> R0, pop PC Call Contract P returns P returns to where C said P restores stack pointerP doesn't modify stack (or C's other memory)P doesn't wedge machine (e.g. use up all heap mem) Soft modularityat a low level, none of call contract is enforced!want: spec + contractspec: we cannot hope to enforce (e.g. does sqrt() return the right answer?)contract: is purely mechanical, we can try to enforcegoal: programmer need only worry about spec, not contract== Enforced Modularitythere are many ways to enforce modularity we'll look at one today Client/servernote much of prob from sharing same machine and memoryso: put C and P on separate machinesinteract only w/ msgs[diagram: two boxes with a wire]Examples: web client / server, AFS, X windows (about to read) Code + time diagramClient: put args in msg (e.g. URL) send msg wait for replyread result from replyServer: wait for req msg get args compute... put result in reply msg (e.g. content of index.html) send reply goto start C/S Benefits1. protects control flow (e.g. return address)2. protects private data3. no fate sharing (crashes and wedges don't propagate)4. forces a narrow spec (for better or worse, no global vars)c/s enforces most of call contract bugs can still propagate via messages but that's a fairly restricted channel easier to examine than all of memory spec still programmer's problem: ensure server returns the right answer C/S helps with Multiple Partiesit turns out c/s has benefits more than just enforced modularity[diagram: emacs, AFS, print]emacs on workstation, AFS, print serverworkstation uses multiple serversAFS has multiple clientsprint server might be both server and client of AFSe.g. client sends file name to print server AFS server is a "Trusted Intermediary"1. get at your data from multiple physical locations2. share with other clients 3. control the sharing (private vs public data, ACLs) private, friends, public bugs in one client don't affect other clients 4. servers physically secure, reliable, easy to find these c/s benefits are as important as enforcing modularity e.g. e-mail server, eBay RPC c/s involves a lot of nasty error-prone msg formatting &cwhy not hide details behind real procedure interface? Example:imagine this is your original single-program ebay implementation:ui(){print bid("123", 10.00); } bid(item, amt) { ... return winning; } you want to split at bid() w/o re-writing this code Client stub idea: procedure that *looks* like bid() but sends msgclient stub:bid(item, amt){ put item and amt in msg; send msg; wait for reply; winning <- reply msg; return winning; now original ui() is using a server! Server stub want to use original bid() code on serverserver stub: dispatch(){while(1){ read msg item, amt <- msg; w = bid(item, amt) msg <- w; send msg; } } Marshal / unmarshalneed standard way to put data types into messagesa message is a sequence of bytesstandard size for integers, flat layout for strings and arraystypical request message format:proc# id 3 '1' '2' '3' 10.00??? Automatic stub generationtool to look at argument and return types: run it on bid()generate marshal and unmarshal codegenerate stub proceduressaves programmingensures agreement on e.g. arg types RPC very successful at simplifying c/s, but RPC != PC despite syntactic similarityamazon web, warehouse back-end[time-line]user (browser) wants to place an orderRPC 1: check inventory(isbn) -> countwhat if network loses/corrupts request? loses reply? warehouse crashes? stub can hide these failures by timeout + resend wrap loop around stub leads to duplicates -- OK, no side effects RPC 2: ship(isbn, addr) -> yes/no request lost? reply lost? warehouse crashes? can stub hide these failures by retrying? are duplicates OK?How do RPC systems handle failure?a couple of approaches, often called "failure semantics"1. at least once client keeps re-sending until server responds -> more than once -> error return AND success only OK for RPCs w/o side effects e.g. check inventory 2. at most once client keeps re-sending (may time out + error) server remembers requests and suppress duplicates -> error return AND success is it OK for ship()? not if we also want to charge credit card iff book shippedif client gives up, or crashes, did the book ship?3. exactly once this is often what we really want: just do it hard to do in a useful way, will see practical versions later most RPC systems do #1 or #2 RMI code slide you feed first part to the rmic stub generator it produces implementation of BidInterface for main() to call and server dispatch stubs the server stubs call your implementation of bid() (not shown) public interface ensures client/server agree on arguments (msg format)procedure call to bid() looks very ordinary!but around it there are non-standard aspectsNaming.lookup() -- which server to talk to? server has registered itself with Naming system lookup() returns a proxy BidInterface object has bid() method, also remembers server identity try/catchthis is new, every remote call must have this, for timeouts/no reply SummaryEnforced modularity via C/SRPC automates details RPC semantics are different Next: enforced mod on same machine RMI code slide (l4.ppt): public interface BidInterface extends Remote {public String bid(String) throws RemoteException;} public static void main (String[] argv) {try {BidInterface srvr = (BidInterface)Naming.lookup("//xxx.ebay.com/Bid"); winning = srvr.bid("123"); System.out.println(winning); } catch (Exception e) { System.out.println ("BidClient exception: " + e); }


View Full Document

MIT 6 033 - Lecture 4: Client/server

Documents in this Course
TRIPLET

TRIPLET

12 pages

End Layer

End Layer

11 pages

Quiz 1

Quiz 1

4 pages

Threads

Threads

18 pages

Quiz I

Quiz I

15 pages

Atomicity

Atomicity

10 pages

QUIZ I

QUIZ I

7 pages

Load more
Download Lecture 4: 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 4: 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 4: 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?