Remote Procedure Call (RPC)

1. Remote Procedure Call (RPC)

2. Readings • Tanenbaum and van Steen: 2.2 and 2.3 • Coulouris: Chapter 5 • A good book: “Power Programming with RPC” by John Bloomer • Another good book: “Practical UNIX Programming: A Guide to Concurrency, Communication and Multithreading” • Check out the links on the 402 web page

3. Outline • Difficulties in Socket Programming • Remote Procedure Calls (RPC) concepts • SUN RPC • Remote Object Invocation

4. Difficulties in Socket Programming • Data representation • Binding

5. Data Representation • Complex data structures must be converted • Sender must flatten complex data structures • Receiver must reconstruct them • Sender and receiver must agree on a common format for messages.

6. Example typedef struct { char Name[MAXNAMELENGTH]; float Salary; char JobCode[IDNUMLENGTH]; } Employee You may want to send this information to the server. Using send(s, (void *) &e, sizeof(e), 0) where e is of type Employee is most likely not going to work. The sender and receiver must agree on a format for the message.

7. Data Representation • Sender and receiver must agree on type of message. This can can be quite difficult. • Sender must convert data to send to the agreed upon format. This often requires a “flattening” of the data structure representing this data. • Receiver should parse the incoming message.

8. Data Representation • Useful functions • sprintf() – Used to convert data items to characters. An example is the following: sprintf(msg, “%s %f %s”,name,salary,jobcode); • sscanf() – Retrieves data items from a string. An example is the following: sscanf(msg, “%s %f %s”,name,&salary,jobcode);

9. Data Representation • Code segment for marshalling the Employee structure char *msg; char name[MAXNAMELENGTH]; char jobcode[MAXNAMELENGTH]; float salary; int msglength; Employee e; …. salary = GetSalaryFromEmployee(e); GetJobCodeFromEmployee(e,jobcode); GetNameFromEmployee(e,name); msg = (char *) malloc(sizeof(Employee)); sprintf(msg,"%s %f %s",name,salary,jobcode); ….. msglength = sizeof(Employee); send(s, (void *) msg, msglength));

10. Data Representation • Code segment for unmarshalling the Employee data sent char *msg; char name[MAXNAMELENGTH]; char jobcode[MAXNAMELENGTH]; float salary; int msglength; Employee e; … msg = (char *) malloc(sizeof(Employee)); … msglength = sizeof(Employee); recv(connectfd, (char *) msg, msglength,0); sscanf(msg, “%s %f %s”, name, &salary, jobcode); …

11. Other Representational Issues • Usually in a client-server model, the server provides a set of services. Each service can be invoked by a procedure. For example, in an employee management system you would have services that include: • Insert an employee record for a new employee • Get the salary of an employee • Etc; • The client must identify the service that it wants. • This is part of the message.

12. Other Representational Issues • Thus each service must have an identifier e.g., in the previous code segment examples we may have something like this: sprintf(msg,“%d %s %f %s",methodidentifier, name,salary,jobcode); sscanf (msg,“%d %s %f %s",&methodidentifier, name,&salary,jobcode);

13. Other Representational Issues • What if we have a list of Employees that we want to send in a message. We do not know ahead of time how many employee records will be sent in a message. • There are different ways to handle this. One way is to send a message with the service identifier and the number of employee records being sent. You then send the number of employee records.

14. Other Representational Issues • What was just described works fine if the client and server machines have similar machine types. • However, it is common that there are multiple machine types. • IBM mainframes use the EBCDIC character code, but IBM PCs use ASCII. • It would be rather difficult to pass a character parameter from an IBM PC client to an IBM mainframe server using what has just been described. • Similar problems occur with integers (1’s complement vs two’s complement).

15. Other Representational Issues • Need a canonical form • For the UNIX OS there is XDR(eXternal Data Representation). For Java RMI, there is Java Remote Method Protocol (JRMP).

16. Other Representational Issues • Converting from local representation to XDR representation is called Encoding. • Converting from XDR representation to local representation is called Decoding. • SUN RPC uses XDR; More later. Sender Receiver XDR ENCODE DECODE Functions are provided for the encoding and decoding; Standard representation of datatypes.

17. Other Representational Issues • XDR Example • Assume that you want to transmit a long integer. You need something as follows: XDR xdrs; long i; xdrstdio_create(&xdrs,stdout,XDR_ENCODE); if (!xdr_long(&xdrs,&i)) { … }

18. Binding • Binding refers to determining the location and identity (communication identifier) of the callee • In UNIX, a communication identifier is a socket address containing host’s IP address and port number.

19. Binding • Strategies for binding • Static binding (which binds the host address of a server into the client program at compilation time) is undesirable. • The client and server programs are compiled separately and often at different times. • Services may be moved from one host to another. • Could pass host name and port by reading a file or through the command line. • You do not need to recompile • You still need to know the location of the server ahead of time.

20. Binding • Strategies for binding (cont) • Always run the binder on a “well-known” address (i.e., fixed host and port) • The operating system supplies the current address of the binder (e.g., via environment variable in UNIX). • Users need to be informed whenever the binder is relocated • Client and server programs need not be recompiled • Use a broadcast message to locate the binder • The binder can be easily relocated • Client/Server programs need not be recompiled

21. Binding • Dynamic binding service is desirable. Ideally, a binding service would have the following characteristics: • Allows servers to register their exporting services • Allows servers to remote services • Allows clients to lookup the named service • We will come back to this later when looking at specific examples.

22. Difficulties in Socket Programming • Using sockets does not conceal communication which is important to achieve access transparency (defined as hiding differences in data representation and how a resource is accessed). • Little was done until a paper by Birell and Nelson (1984). They suggested: • Allow programs to call procedures located on other machines. • Sounds simple, but the implementation is actually quite difficult. • This approach is known as Remote Procedure Call (RPC).

23. Remote Procedure Client Server blah, blah, blah bar = foo(a,b); blah, blah, blah int foo(int x, int y ) { if (x>100) return(y-2); else if (x>10) return(y-x); else return(x+y); } protocol

24. Introduction to RPC • An extension of conventional procedure call (used for transfer of control and data within a single process) • Allows a client program to call procedures in a different address space in the same or remote machine.

25. Introduction to RPC • Ideal for the client-server modeled applications • Higher level of abstraction for interprocess communication • The goal is to make distributed programming easier. • Want transparent integration with the programming language. • The calling procedure should not be aware that the called procedure is executing on a different machine. • We will primarily focus on SUN RPC • Can use TCP or UDP • Best known

26. RPC System Components • Stub procedures • A stub is a communications interface that implements the RPC protocol and specifies how messages are constructed and exchanged • Responsible for packing and unpacking of arguments and results; this is referred to as marshalling. • Automatically generated by “stub generators” or “protocol compilers” (more later).

27. RPC System Components • Client stub • Marshalling: Packs the arguments with the procedure name or identifier into a message (this is instead of activation records) • Sends the message to the server and then awaits a reply message • Unpacks the results and returns them to the client • Server Stub • Receives a request message • Unmarshalling: Unpacks the arguments and calls appropriate procedure • When it returns, packs the result and sends a reply message back to client.

28. Interface Interface RPC System Components IPC runtime IPC runtime client stub stub Server invoke return packargs unpackresult send receive receive send unpackargs packresult invoke work return We do not want to write the stub code ourselves

29. Passing Pointers • What about pointers? • Very difficult. • Pointers are meaningful only within the address space of the process in which it is being used. • Could eliminate all together, but this is not necessary. • One strategy: • Assume a parameter that is a pointer to an array of characters and that this array’s size is known. • Copy the array into the message and send to server. Server changes the data, sends it back to the client and the client copies. • Can’t deal with complex data structures e.g. a graph

30. RPC Interface Definition Language and Compiler • How are stubs created? • Servers provide one or more services to client programs • Services are encapsulated and their clients interact with them only via interfaces • An interface definition language (IDL) is used to define these interfaces which are also known as service interfaces.

31. RPCGEN • There is a tool for automating the creation of RPC clients and servers. • The program rpcgen does most of the work for you. • The input to rpcgen is an interface specification.

32. RPCGEN Protocol Description Input File rpcgen Server skeleton XDR filters header file Client Stubs C Source Code

33. Interface Definition Language • The input file defines an interface • The language used to describe the interface is based on XDR and is called the Interface Definition Language. • An interface contains a program number, a version number, procedure definitions and required type definitions. • A procedure definition specifies a procedure declaration and a procedure number.

34. Interface Definition Language • Only a single input and output parameter is allowed. • rpcgen compiles interface definitions into stubs, header files and main server source code.

35. Example • We will illustrate SUN RPC by converting a simple local service for generating pseudorandom numbers into a remote service. • This is based on the drand48 and srand48 functions. • Prior to invoking drand48, a program must initialize a starting value by calling the srand48 function with a long parameter value called the seed. • The seed determines the starting position in a predetermined sequence of pseudorandom numbers. • After initializing the generator by invoking srand48, call drand48 to return successive values in a sequence of pseudorandom values that are uniformly distributed in the interval [0,1).

36. Example There is one file that we will call pseudorandom.c #include "rand.h" void initialize_random(long seed) { srand48(seed); } double get_next_random(void) { return drand48(); }

37. Example A program that uses these functions is in main.c and a segment looks like this: ……. myseed = (long)atoi(argv[1]); iters = atoi(argv[2]); initialize_random(myseed); for (i = 0; i < iters; i++) printf("%d: %f\n",i, get_next_random()); exit(0); Please note that the seed value and the number of iterations are command line arguments.

38. Example • Now let us see how to make initialize_random and get_next_random remote functions. • We first provide a specification (XDR) file for the remote service. This specifies the interface. • The XDR file has a .x extension.

39. Example rand.x is the following: program RAND_PROG { version RAND_VERS{ void INITIALIZE_RANDOM(long) = 1; double GET_NEXT_RANDOM(void) = 2; } = 1; } = 0x31111111

40. Program Identifiers • The Sun convention for program numbers if the following: • 0x00000000 - 0x1fffffff (Sun) • 0x20000000 - 0x3fffffff (User) • 0x40000000 - 0x5fffffff (transient) • 0x60000000 - 0xffffffff (reserved)

41. Procedure Identifiers &Program Version Numbers • Procedure identifiers usually start at 1 and are numbered sequentially • Version numbers typically start at 1 and are numbered sequentially. • The function names are the same as those before except that are all in uppercase. • The functions are numbered so that the initialize_random function is service number 1 and get_next_random is service number 2 in the server.

42. Example • Now to use rpcgen as follows: rpcgen –C –a rand.x • The –C option indicates ANSI C and the –a option tells rpcgen to generate all of the supporting files.

43. Example • Files generated include: • makefile.rand: This file is the makefile for compiling all of the client and server code. • rand_clnt.c: This file contains the client stub, which is usually not motified. • rand_svc.c: This file contains the server stub, which is usually not modified. • rand.h: This header file contains all of the XDR types from the specification. • rand_client.c: This file contains a skeleton client main program with dummy calls to the remote service. You insert code to set up the argument values for the remote service before the dummy call.

44. Example • Files generated include (continued): • rand_server.c: This file contains the stubs for the remote services. Insert the code for the local version of the services into these stubs. • rand_xdr.c: If this file is generated, it contains XDR filters (routines) needed by the client and server stubs.

45. Example • You can now modify the rand_client.c file to contain the client code. • You then modify the rand_server.c file to contain the functions to be called remotely.

46. Example • This is the rand_client.c generated by rpcgen. #include "rand.h" #include <stdio.h> #include <stdlib.h> /* getenv, exit */ void rand_prog_1(char *host) { CLIENT *clnt; void *result_1; long initialize_random_1_arg; double *result_2; char * get_next_random_1_arg;

47. Creates a handle for the remote service Has version number appended to function name clnt pointer is deallocated Example #ifndef DEBUG clnt = clnt_create(host, RAND_PROG, RAND_VERS, "netpath"); if (clnt == (CLIENT *) NULL) { clnt_pcreateerror(host); exit(1); } #endif /* DEBUG */ result_1 = initialize_random_1(&initialize_random_1_arg,clnt); if (result_1 == (void *) NULL) { clnt_perror(clnt, "call failed"); } result_2 = get_next_random_1((void *)&get_next_random_1_arg, clnt); if (result_2 == (double *) NULL) { clnt_perror(clnt, "call failed"); } #ifndef DEBUG clnt_destroy(clnt); #endif /* DEBUG */ }

48. Example main(int argc, char *argv[]) { char *host; if (argc < 2) { printf("usage: %s server_host\n", argv[0]); exit(1); } host = argv[1]; rand_prog_1(host); }

49. Example • In the rand_prog_1, we take note of the following: • The clnt_create call generates a handle for the remote service. If it fails, a NULL pointer is returned. Returns the clnt pointer which is the handle (communication information) for the remote service. • The RAND_PROG and RAND_VERS parameters are the program and version names specified in rand.x • The “netpath” parameter indicates that the program should look for an available network transport mechanism as specified by the NETPATH environment variable. • The converted remote calls to initialize_random and get_next_random have the version number appended to the function names i.e., initialize_random is called as initialize_random_1. • In the remote calls, the parameters and return values are designated by the pointers. • The clnt pointer is deallocated by clnt_destroy.

50. Example The following is a revised version of the mainfunction in rand_client.c #include "rand.h" #include <stdio.h> #include <stdlib.h> /* getenv, exit */ main(int argc, char *argv[]) { int iters, i; long myseed; CLIENT *clnt; void *result_1; double *result_2; char *arg;