CS 162 Spring 2004 Lecture 21 1/9 CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2003 Lecture 21: Remote Procedure Call (RPC) 21.0 Main Point • Send/receive • One vs. two-way communication • Remote Procedure Call • Cross-address space vs. cross-machine communication 21.1 Send/Receive How do you program a distributed application? Need to synchronize multiple threads, only now running on different machines (no shared memory, can’t use test&set). Key abstraction: send/receive messages. (Note: this abstraction is similar to “read” and “write” of the file I/O interface.) Atomic operations: send/receive – doesn’t require shared memory for synchronizing cooperating threads. Questions to be answered: • Blocking vs. Non-blocking calls • Buffered vs. Non-buffered I/O • How does addressing work? Mailbox – temporary holding area for messages (ports) Send(message, mbox) – put message on network, with name of mbox for where it is to go on far end When can Send return? 1. When receiver gets message? (i.e., acknowledgement received) CS 162 Spring 2004 Lecture 21 2/9 2. When message is safely buffered on destination node? 3. Right away, if message is buffered on source node? There are really two questions here: 1. When can the sender be sure that the receiver actually received the message? 2. When can the sender re-use the memory containing the message? Receive(buffer, mbox) • Wait until mbox has message in it, then copy message into buffer, and return. • When packet arrives, OS puts message into mbox, wakes up one of the waiters. Note that send and receive are atomic (the OS ensures this abstraction). • Never get portion of a message (all or nothing) • Two receivers can’t get same message 21.2 Message styles Using send/receive for synchronization: Producer: int msg1[1000] while (1) prepare message // make coke send(msg1, mbox) Consumer: int msg[1000] while (1) receive(msg2, mbox) process message // drink coke No need for producer/consumer to keep track of space in mailbox – handled by send/receive.CS 162 Spring 2004 Lecture 21 3/9 What about two-way communication? Request/response. For instance, “read a file” stored on a remote machine or request a web page from a remote web server. Also called: client-server. Client = requester; server = responder. Server provides “service” (file storage) to the client Request/response: Client: (requesting the file) char response[1000]; send(“read rutabaga”, mbox1); receive(response, mbox2); Server: char command[1000], answer[1000]; receive(command, mbox1); decode command read file into answer send(answer, mbox2); Server has to decode command, just as OS has to decode message to find mbox. CS 162 Spring 2004 Lecture 21 4/9 What if file is too big for response (e.g., maximum message size is 1KB)? Use “remote file access” protocol: send(“open rutabaga”, mbox1); receive(status, mbox2); if (!streq(status, “OK”)) Error(status); while (TRUE) { send(“read 1024”, mbox1); receive(buf, mbox2); if (!streq(status, “OK”)) { if (streq(status, “EOF”)) break; Error(status); } ... } send(“close”, mbox1); receive(status, mbox2); Problem: I/O is not the most natural programming model for many situations. What is? 21.3 Remote Procedure Call (RPC) Call a procedure on a remote machine. Client calls: remoteFileSys->Read(“rutabaga”) Translated into call on server: fileSys->Read(“rutabaga”) Implementation: • Request-response message passing • “Stub” provides glue on client/server. o Client stub is responsible for “marshalling” arguments and “unmarshalling” the return valuesCS 162 Spring 2004 Lecture 21 5/9 o Server-side stub is responsible for “unmarshalling” arguments and “marshalling” the return values. o Marshalling involves (depending on the system): converting values to a canonical form, serializing objects, copying arguments passed by reference, etc. Client (caller)Client stubPacket HandlerServer (callee)Server stubPacket HandlerNetwork transportcallreturnbundle argsunbundle argumentsbundle ret valsreturncallunbundlesendreceivesendreceiveNetwork transport Client stub: Build message Send message Wait for response Unpack reply Return result Server stub: Create N threads to wait for work to do Loop: Wait for command Decode and unpack request parameters Call procedure Build reply message with results Send reply CS 162 Spring 2004 Lecture 21 6/9 21.3.1 Comparison between RPC and procedure call What’s equivalent? Parameters – request message Result – reply message Name of procedure – passed in request message Return address – mbox2 21.3.2 Implementation issues Stub generator – generates stubs automatically. For this, only need procedure signature: types of arguments, return value. Generates code on client to pack message, send it off; on server to unpack message, call procedure. Input: interface definitions in an interface definition language (IDL). Output: stub code in the appropriate source language (C, C++, Java, ...) What if client/server machines are different architectures? Or, they use different programming languages? Examples of modern RPC systems: • CORBA (Common Object Request Broker Architecture) • DCOM (Distributed COM) • RMI (java Remote Method Invocation) How does client know which mbox to send to? Binding Static – fixed at compile time (C) Dynamic – fixed at runtime (Lisp, RPC) In most RPC systems, dynamic binding via name service. Name service provides dynamic translation of service -> mbox Why runtime binding? • Access control – check who is permitted to access service • Fail-over – if server fails, use anotherCS 162 Spring 2004 Lecture 21 7/9 What if there are multiple servers – can they use same mbox? OK, if no state carried forward from one call to the next. For example, open, seek, read, close – each uses context of previous operation. What if multiple clients? All would receive results in same mbox Fix by passing pointer to mbox in request message (this is like pushing the return PC on the stack) 21.4 Problems with RPC RPC provides location transparency, except: 21.4.1 Failures Different failure modes in distributed system than on single machine. Several kinds of failures: – User-level bug causes address space to crash – Machine failure, kernel bug
View Full Document
Unlocking...