Chapter 2: Remote Procedure Call (RPC) Contents - Chapter 2 - RPC IP, TCP, UDP and RPCThe basics of client/serverProblems to solveProgramming languagesInteroperabilityExample (XDR in SUN RPC)Binding Call semanticsMaking it work in practiceIn more detailIDL (Interface Definition Language)Programming RPCRPC ApplicationRPC in perspectiveRPC system issuesFrom RPC we go to ...DCEDCE architectureDCE’s model and goalsEncina’s extensions to DCEChapter 2:Remote Procedure Call (RPC)Gustavo AlonsoComputer Science DepartmentSwiss Federal Institute of Technology (ETHZ)[email protected]://www.iks.inf.ethz.ch/©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 2Contents - Chapter 2 - RPC  Distributed designÄ Computer networks and communication at a high levelÄ Basics of Client/Server architectures• programming concept• interoperability• binding to services• delivery guarantees Putting all together: RPCÄ programming languagesÄ bindingÄ interface definition languageÄ programming RPC RPC in the context of large information systems (DCE, TP-Monitors)©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 3IP, TCP, UDP and RPC The most accepted standard for network communication is IP (Internet Protocol) which provides unreliable delivery of single packets to one-hop distant hosts IP was designed to be hidden behind other software layers:Ä TCP (Transport Control Protocol) implements connected, reliable message exchangeÄ UDP (User Datagram Protocol) implements unreliable datagram based message exchanges TCP/IP and UDP/IP are visible to applications through sockets. The purpose of the socket interface was to provide a UNIX-like abstraction Yet sockets are quite low level for many applications, thus, RPC (Remote Procedure Call) appeared as a way toÄ hide communication details behind a procedural callÄ bridge heterogeneous environments RPC is the standard for distributed (client-server) computingIPTCP, UDPSOCKETSRPC©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 4The basics of client/server Imagine we have a program (a server) that implements certain services. Imagine we have other programs (clients) that would like to invoke those services. To make the problem more interesting, assume as well that:Ä client and server can reside on different computers and run on different operating systemsÄ the only form of communication is by sending messages (no shared memory, no shared disks, etc.)Ä some minimal guarantees are to be provided (handling of failures, call semantics, etc.)Ä we want a generic solution and not a one time hack Ideally, we want he programs to behave like this (sounds simple?, well, this idea is only 20 years old):Machine A(client)Machine B(server)Execution ThreadService requestService responseMessage©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 5Problems to solve How to make the service invocation part of the language in a more or less transparent manner.Ä Don’t forget this important aspect: whatever you design, others will have to program and use How to exchange data between machines that might use different representations for different data types. This involves two aspects:Ä data type formats (e.g., byte orders in different architectures)Ä data structures (need to be flattened and the reconstructed) How to find the service one actually wants among a potentially large collection of services and servers.Ä The goal is that the client does not necessarily need to know where the server resides or even which server provides the service. How to deal with errors in the service invocation in a more or less elegant manner:Ä server is down,Ä communication is down,Ä server busy,Ä duplicated requests ...©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 6Programming languages The notion of distributed service invocation became a reality at the beginning of the 80’s when procedural languages (mainly C) were dominant. In procedural languages, the basic module is the procedure. A procedure implements a particular function or service that can be used anywhere within the program.  It seemed natural to maintain this same notion when talking about distribution: the client makes a procedure callto a procedure that is implemented by the server. Since the client and server can be in different machines, the procedure is remote. Client/Server architectures are based on Remote Procedure Calls (RPC) Once we are working with remote procedures in mind, there are several aspects that are immediately determined:Ä data exchange is done as input and output parameters of the procedure callÄ pointers cannot be passed as parameters in RPC, opaque references are needed instead so that the client can use this reference to refer to the same data structure or entity at the server across different calls. The server is responsible for providing this opaque references.©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 7Interoperability When exchanging data between clients and servers residing in different environments (hardware or software), care must be taken that the data is in the appropriate format:Ä byte order: differences between little endian and big endianarchitectures (high order bytes first or last in basic data types)Ä data structures: like trees, hash tables, multidimensional arrays, or records need to be flattened (cast into a string so to speak) before being sent This is best done using an intermediate representation format The concept of transforming the data being sent to an intermediate representation format and back has different (equivalent) names:Ä marshalling/un-marshallingÄ serializing/de-serializing The intermediate representation format is typically system dependent. For instance:Ä SUN RPC: XDR (External Data Representation) Having an intermediate representation format simplifies the design, otherwise a node will need to be able to transform data to any possible format©Gustavo Alonso, ETH Zürich. Web services: Concepts, Architectures and Applications - Chapter 2 8Example (XDR in SUN RPC) Marshalling or serializing can be done by hand (although this