Intro duction Remote Pro cedure Calls RPC are a p opu- lar mo del for building client/server applica- tions Overview of Remote Pro cedure { ONC RPC and OSF DCE are widely available RPC to olkits Calls RPC RPC forms the basis for many client/server applications Douglas C. Schmidt { e.g., NFS Washington University, St. Louis Distributed object computing DOC frame- works may be viewed as an extension of RPC RPC on sterio ds http://www.cs.wustl.ed u/s chmi dt/ { e.g., OMG CORBA [email protected] u RPC falls somewhere b etween the transp ort layer and application layer in the OSI mo del { i.e., it contains elements of session and presenta- tion layers 1 2 Motivation IPC Overview RPC tries to simplify distributed application rogramming by making distribution trans- p CLIENT HOST SERVER HOST parent RPC to olkits automatically handle CLIENT SERVER PROCESS PROCESS { Reliability e.g., communication errors and transactions . REQUEST RESPONSE { Platform heterogeneity e.g., p erforms parameter \marshaling" of com- . NETWORK plex data structures and handles byte-ordering di erences Many applications require communication among { Service lo cation and selection multiple pro cesses { Service activation and handler dispatching { Pro cesses may b e remote or lo cal { Security 3 4 Message Passing Mo del Message passing is a general technique for exchanging information b etween twoormore pro cesses Message Passing Mo del cont'd Basically an extension to the send/recv I/O In general, message passing do es not make API an e ort to hide distribution { e.g., UDP, VMTP { e.g., network byte order, p ointer linearization, ad- dressing, and security must b e dealt with explicitly Supp orts a numb er of di erent communica- tion styles This makes the mo del ecient and exible, { e.g., request/resp onse, asynchronous oneway, mul- but also complicate and time consuming ticast, broadcast, etc. May serve as the basis for higher-level com- munication mechanisms such as RPC 6 5 Monolithic Application Structure Message Passing Design Consideratio ns FILE Blo cking vs. nonblo cking SYSTEM FILESYSTEM API { A ects reliablility, resp onsiveness, and program struc- ture RECALC RECALC SPREAD API SHEET Bu ered vs. unbu ered DATABASE A ects p erformance and reliability { API DATABASE GUI API Reliable vs. unreliable GUI { A ects p erformance and correctness 7 8 Basic Principles of RPC RPC Application Structure 1. Use traditional programming style for dis- application development FILE tributed SYSTEM FILESYSTEM RECALC API Enable selective replacement of lo cal pro ce- RPC 2. GENERATED RPC calls with remote pro cecure calls RECALC dure SPREAD API CLIENT GENERATED SHEET STUBS SERVER STUBS Lo cal Pro cedure Call LPC DATABASE API DATABASE { A well-known metho d for transferring control GUI rt of a pro cess to another API from one pa GUI . Implies a subsequent return of control to the caller Remote Pro cedure Call RPC Note, RPC generators automate most of { Similar LPC, except a lo cal pro cess invokes a the work involved in separating client and pro cedure on a remote system server functionality . i.e., control is transferred across pro cesses/hosts 9 10 A Temp oral View of RPC A Layered View of RPC CLIENTCLIENT SERVER SERVER KERNEL USER CLIENT HOST SERVER HOST REQUEST CLIENT SERVER PROCESS REMOTE PROCESS REMOTE USER SERVICE PROCEDURE PROCEDURE KERNEL NETWORK CLIENT EXECUTES CALL APPLICATION APPLICATIONSERVER BLOCKED CODE CODEPROCESS STUB CODE STUB CODE RESPONSE RPC RPC RUNTIME RUNTIME LIBRARY LIBRARY REQUEST RESPONSE An RPC proto col contains two sides, the sender and the receiver i.e., client and server NETWORK { However, a server might also b e a client of another server and so on::: 11 12 Typical Server Startup Behavior RPC Automation CLIENT HOST SERVER HOST To help make distribution transparent, RPC hides all the network co de in the client stubs server skeletons and SERVER PROCESS (1) REGISTER INTERFACE { These are usually generated automatically:: : (2) CREATE BINDING INFO (3) ADVERTISE SERVER LOCATION (4) REGISTER ENDPOINTS (5) LISTEN FOR CALLS This shields application programs from net- RPC RUNTIME working details LIBRARY { e.g.,sockets, parameter marshalling, network byte order, timeouts, ow control, acknowledgements, retransmissions, etc. ENDPOINT MAP It also takes advantage of recurring com- NAME SERVICE muncation patterns in network servers to CDS HOST generate most of the stub/skeleton co de automatically 13 14 Typical Client Startup Behavior Typical Client/Server Interaction CLIENT HOST SERVER HOST CLIENT HOST SERVER HOST CLIENT PROCESS (6) MAKE REMOTE CLIENT SERVER PROCEDURE PROCESS PROCESS (14) EXECUTE APPLICATION CALL REMOTE CODE SERVER APPLICATION PROCEDURE (7) FIND CODE S ERVER PROCESS (10) PREPARE SYSTEM (15) PREPARE (13) CONVERT INPUT STUB (18) CONVERT OUTPUT INPUT STUB OUTPUT (8) FIND S ERVER (11) TRANSMIT (12) RECEIVE PROCESS INPUT RPC AND RPC RUNTIME (16) TRANSMIT DISPATCH (9) BIND TO RUNTIME (17) RECEIVE TO STUB LIBRARY S ERVER LIBRARY OUTPUT OUTPUT ENDPOINT ENDPOINT MAP MAP NAME SERVICE NAME CDS SERVICE HOST CDS HOST 15 16 RPC Mo dels RPC Mo dels SYNCHRONOUS RPC There are several variations on the stan- CLIENT SERVER rd RPC \synchronous request/resp onse" da PROCESS mo del NOWAIT RPC CLIENT SERVER (NOWAIT) Each mo del provides greater exibility, at VOID REPLY the cost of less transparency CALLBACK RPC CLIENT (NOWAIT) SERVER Certain RPC to olkits supp ort all the di er- VOID REPLY INTERNE WINDOW SYNCHRONOUS CALLBACK RPC mo dels ent LOOP OR T WAITFOR _RPC { e.g., ONC RPC BATCH RPC CLIENT SUB1 VOID REPLY SERVER NETWORK SUB2 SUB3 Other DOC frameworks do not due to p orta- SUB1 VOID REPLY ACCESS SUB2 y concerns bilit SUB3 SUB3 RETURN { e.g., OMG CORBA and OSF DCE 18 17 RPC Mo dels cont'd BROADCAST RPC SERVER ransparency Issues BROADCAST T CLIENT APPLICATION REQUEST DOESPROCESS NOT REPLY BROADCAST SERVER RPC has a numb er of limit ati ons that must REQUEST BROADCAST BROADCAST HOST-TO- COLLECTION REPLY be understo o d to use the mo del e ectively ROUTINE HOST BROADCAST BROADCAST REPLY REQUEST SERVER { Most of the limitations center around transparency INTERNET NETWORK THREADED RPC SERVER Transforming a simple lo cal pro cedure call APPLICATION CLIENT PROCESS into system calls, data conversions, and net- work communications increases the chance SERVER something going wrong (SYNCHRONOUS RPC) HOST-TO- of HOST i.e., it reduces the transparency of distribution SERVER { INTERNET NETWORK 20 19 Tranparency Issues cont'd Parameter Passing Key Asp ects of RPC Transparency Functions in an application that runs in a 1. Parameter passing single pro cess may collab orate via parame- ters and/or global variables 2. Data representation 3. Binding Functions in an application that runs in mul- tiple pro cesses on the same host may col- 4. Transp ort proto col lab orate via message passing and/or non- distributed shared memory 5. Exception handling 6. Call semantics However, passing parameters is typically the only way that RPC-based clients and servers 7. Security share information { Hence, we have already given up one typ e of transparency:: : 8. Performance 21 22 Parameter Passing cont'd Passing parameters across pro cess/host b ound- Parameter Passing cont'd aries is surprisingly tricky::: Typical solutions include: Parameters that are passed by value are fairly simple to handle { Have the RPC proto col only allow the client to pass arguments by value { The client stub copies the value from the client and packages into a network message . However, this reduces transparency even further! { Presentation issues are still imp ortant, however { Use a presentation data format where the user sp eci cally de nes what the input arguments are and what the return values are Parameters passed by reference are much . e.g., Sun's XDR routines harder { e.g., in C when the address of a variable is passed { RPC facilities typically provide an \interface de - nition language" to handle this . e.g., passing arrays . e.g., CORBA or DCE IDL { Or more generally, handling p ointer-based data structures . e.g., p ointers, lists, trees, stacks, graphs, etc. 24 23 Data Representatio n RPC systems intended for heterogeneous Data Representation cont'd environments must b e sensitive to byte-ordering di erences Examples cont'd { They typically provide to ols for automatically p er- forming data conversion e.g., rpcgen or idl { DCE RPC NDR . Supp orts multiple presentation layer formats Examples: . Supp orts \receiver makes it right" semantics:: : { Sun RPC XDR Allows the sender to use its own internal for- mat, if it is supp orted . Imp oses \canonical" big-endian byte-ordering . The receiver then converts this to the appropri- . Minimum size of any eld is 32 bits ate format, if di erent from the sender's format { Xerox Courier This is more ecient than \canonical" big- endian format for little-endian machines . Uses big-endian . Minimum size of any eld is 16 bits 25 26 Binding Binding cont'd Binding is the pro cess of mapping a request There are two comp onents to binding: for a service onto a physical server some- where in the network 1. Finding a remote host for a desired service { Typically, the client contacts an appropriate name 2. Finding the correct service on the host server or \lo cation broker" that informs it which remote server contains the service { i.e., lo cating the \pro cess" on a given host that is listening to a well-known p ort . Similar to calling 411::: There are several techniques that clients use If service migration is supp orted, it may be to lo cate a host that provides a given typ e necessary to p erform this op eration multiple of service times { These techniques di er in terms of their p erfor- { Also may b e necessary to leave a \forwarding" ad- mance, transparency, accuracy, and robustness dress 28 27 Binding cont'd Binding cont'd \Hard-co de" magic numb ers into programs ugh:: : ;- Sup erserver: inetd and listen { Motivation Another technique is to hard-co de this in- formation into a text le on the lo cal host .