IP, TCP, UDP and RPC The most accepted standard for Yet sockets are quite low level for network communication is IP many applications, thus, RPC (Internet Protocol) which provides (Remote Procedure Call) appeared unreliable delivery of single packets as a way to to one-hop distant hosts Ä hide communication details IP was designed to be hidden behind behind a procedural call other software layers: Ä bridge heterogeneous Ä TCP (Transport Control environments Protocol) implements connected, RPC is the standard for distributed reliable message exchange (client-server) computing Ä UDP (User Datagram Protocol) Remote Procedure Call (RPC) implements unreliable datagram based message exchanges RPC TCP/IP and UDP/IP are visible to Gustavo Alonso applications through sockets. The SOCKETS Computer Science Department purpose of the socket interface was Swiss Federal Institute of Technology (ETHZ) to provide a UNIX-like abstraction TCP, UDP [email protected] http://www.iks.inf.ethz.ch/ IP ©Gustavo Alonso, ETH Zürich. 2 The basics of client/server Problems to solve Imagine we have a program (a Ideally, we want he programs to How to make the service invocation How to find the service one actually server) that implements certain behave like this (sounds simple?, part of the language in a more or wants among a potentially large services. Imagine we have other well, this idea is only 20 years old): less transparent manner. collection of services and servers. programs (clients) that would like to Ä Don’t forget this important Ä The goal is that the client does invoke those services. aspect: whatever you design, not necessarily need to know Machine A Machine B To make the problem more others will have to program and where the server resides or even interesting, assume as well that: (client) (server) use which server provides the Ä client and server can reside on service. different computers and run on Service request different operating systems How to exchange data between How to deal with errors in the Ä the only form of communication machines that might use different service invocation in a more or less is by sending messages (no representations for different data elegant manner: shared memory, no shared disks, types. This involves two aspects: Ä server is down, etc.) Service response Ä data type formats (e.g., byte Ä communication is down, Ä some minimal guarantees are to orders in different architectures) be provided (handling of Ä server busy, Ä data structures (need to be Ä duplicated requests ... failures, call semantics, etc.) flattened and the reconstructed) Ä we want a generic solution and not a one time hack Execution Thread Message ©Gustavo Alonso, ETH Zürich. 3 ©Gustavo Alonso, ETH Zürich. 4 Programming languages Interoperability The notion of distributed service Once we are working with remote When exchanging data between The concept of transforming the data invocation became a reality at the procedures in mind, there are several clients and servers residing in being sent to an intermediate beginning of the 80’s when aspects that are immediately different environments (hardware or representation format and back has procedural languages (mainly C) determined: software), care must be taken that different (equivalent) names: were dominant. Ä data exchange is done as input the data is in the appropriate format: Ä marshalling/un-marshalling In procedural languages, the basic and output parameters of the Ä byte order: differences between Ä serializing/de-serializing module is the procedure. A procedure call little endian and big endian The intermediate representation procedure implements a particular Ä pointers cannot be passed as architectures (high order bytes format is typically system function or service that can be used parameters in RPC, opaque first or last in basic data types) dependent. For instance: anywhere within the program. references are needed instead so data structures: like trees, hash Ä Ä SUN RPC: XDR (External Data It seemed natural to maintain this that the client can use this tables, multidimensional arrays, same notion when talking about reference to refer to the same or records need to be flattened Representation) distribution: the client makes a data structure or entity at the (cast into a string so to speak) Having an intermediate procedure call to a procedure that is server across different calls. The before being sent representation format simplifies the design, otherwise a node will need implemented by the server. Since server is responsible for This is best done using an the client and server can be in providing this opaque intermediate representation format to be able to transform data to any different machines, the procedure is references. possible format remote. Client/Server architectures are based on Remote Procedure Calls (RPC) ©Gustavo Alonso, ETH Zürich. 5 ©Gustavo Alonso, ETH Zürich. 6 Example (XDR in SUN RPC) Binding Marshalling or serializing can be SUN XDR follows a similar A service is provided by a server With a distributed binder, several done by hand (although this is not approach: located at a particular IP address and general operations are possible: desirable) using (in C) sprintf and Ä messages are transformed into a listening to a given port Ä REGISTER (Exporting an sscanf: sequence of 4 byte objects, each Binding is the process of mapping a interface): A server can register byte being in ASCII code service name to an address and port service names and the Message= “Alonso” “ETHZ” “2001” Ä it defines how to pack different that can be used for communication corresponding port data types into these objects, purposes Ä WITHDRAW: A server can char *name=“Alonso”, place=“ETHZ”; which end of an object is the Binding can be done: withdraw a service int year=2001; most significant, and which byte Ä locally: the client must know the Ä LookUP (Importing an of an object comes first sprintf(message, “%d %s %s %d %d”, name (address) of the host of the interface): A client can ask the strlen(name), name, strlen(place), place, Ä the idea is to simplify server binder for the address and port year); computation at the expense of Ä distributed: there is a separate of a given service bandwidth service (service location, name There must also be a way to locate Message after marshalling = and directory services, etc.) in the binder (predefined location, “6 Alonso 4 ETHZ 2001” 6 String length charge of mapping names and environment variables, broadcasting A l o n addresses. These service must to all nodes looking for the binder) Remember that the type and number s o be reachable to all participants of parameters is know, we only need 4 String length to agree on the syntax ... E T H Z 2 0 0 1 cardinal ©Gustavo Alonso, ETH Zürich. 7 ©Gustavo Alonso, ETH Zürich. 8 Call semantics Making it work in practice A client makes an RPC to a service At least-once: the procedure will be One cannot expect the programmer at a given server. After a time-out executed if the server does not fail, to implement all these mechanisms CLIENT Client process expires, the client may decide to re- but it is possible that it is executed every time a distributed application call to remote procedure send the request. If after several tries more than once. This may happen, is developed. Instead, they are there is no success, what may have for instance, if the client re-sends the provided by a so called RPC system happened depends on the call request after a time-out. If the server (our first example of low level CLIENT stub procedure semantics: is designed so that service calls are middleware) Bind idempotent (produce the same What does an RPC system do? Marshalling outcome given the same input), this Communication Maybe: no guarantees. The Ä Provides an interface definition Send procedure may have been executed might be acceptable. language (IDL) to describe the module (the response message(s) was lost) At most-once: the procedure will be services executed either once or not at all. or may have not been executed (the Ä Generates all the additional code request message(s) was lost). It is Re-sending the request will not result in the procedure executing necessary to make a procedure Communication very difficult to write programs call remote and to deal with all SERVER stub procedure several times module based on this type of semantics since the communication aspects Unmarshalling the programmer has to take care of Return all possibilities Ä Provides a binder in case it has a distributed name and directory Dispatcher service system (select SERVER stub) remote procedure Server process ©Gustavo Alonso, ETH Zürich. 9 ©Gustavo Alonso, ETH Zürich. 10 In more detail IDL (Interface Definition Language) Client Client Comm. Comm. Server Server All RPC systems have a language Given an IDL specification, the code stub Module Binder that allows to describe services in an interface compiler performs a variety module stub code abstract manner (independent of the of tasks: programming language used). This Register service request generates the client stub procedure for language has the generic name of each procedure signature in the RPC bind ACK Look up request IDL (e.g., the IDL of SUN RPC is interface. The stub will be then XDR) compiled and linked with the client Look up response The IDL allows to define each code service in terms of their names, and Generates a server stub. It can also send input and output parameters (plus RPC request create a server main, with the stub and maybe other relevant aspects). the dispatcher compiled and linked An interface compiler is then used to into it. This code can then be extended call generate the stubs for clients and by the designer by writing the servers (rpcgen in SUN RPC).