1. Remote Procedure Call (Introduction)
What is a procedure? (review)
A procedure is to execute a group of statements and syntactically a procedure call was defined to be a statement.
Parameter passing: the way to pass external variable(s) into a procedure.

2. Remote Procedure Call (Introduction)
Why we need Remote Procedure Call (RPC)?
The procedures of send and receive are fundamentally engaged in doing I/O.
Since I/O is not one of the key concepts of centralized systems, making it the basis for distributed computing has struck many workers in the field as a mistake.
The client needs a easy way to call the procedures of the server to get some services.

3. Remote Procedure Call (Introduction)
What is RPC mechanism?
They enable clients to communicate with servers by calling procedures in a similar way to the conventional use of procedure on the local procedure call, but the call procedure is executed in a different process and usually a different computer.

4. Remote Procedure Call (Introduction)
How to operate RPC?
When a process on machine A calls a procedure on machine B, the calling process on A is suspended, and the execution of the called procedure takes place on B.
Information can be transported from the caller to the callee in the parameters and can come back in the procedure result.
No message passing or I/O at all is visible to the programmer.

5. Remote Procedure Call (Main characteristics)
The called procedure is in another process which may reside in another machine.
Since the processes do not share address space, passing of parameters by reference and passing pointer values are not allowed. Parameters are passed by values.
The called remote procedure executes within the environment of the server process. The called procedure does not have access to the calling procedure’s environment.

6. Remote Procedure Call (Limitation)
Parameters passed by reference only and pointer values are not allowed.
Speed: remote procedure calling (and return) time (i.e., overheads) can be significantly (1 - 3 orders of magnitude) slower than that for local procedure. This may affect real-time design and the programmer should be aware of its impact.
Failure: RPC is more vulnerable to failure (since it involves communication system, another machine and another process). The programmer should be aware of the call semantics.

7. Remote Procedure Call (How does RPC work?)
In the normal case (no failure), the following problems we should solve
P1: How does the client know which procedure (names) it can call from the server?
P2: How does the client transfer its call request (the procedure name) and the arguments to the server via network?

8. Remote Procedure Call (How does RPC work?)
P3: How does the server react the request of the client? From which port? How to select the procedure? How to interpret the arguments?
P4: How does the server transmit the reply back?
P5: How does the client receive the reply?

9. Remote Procedure Call (Solution for P1)
P1: How does the client know which procedure (names) it can call from the server?
Solution: Server interface definition
Interface definition language: RPC interface specifies those characteristics of the procedures provided by a server that are visible to the clients. The characteristics includes: names of the procedures and type of parameters. Each parameter is defined as input or output.

10. Remote Procedure Call (Solution for P1)
In summary, an interface contains a list of procedure signatures - the names and types of their I/O arguments (to be discussed later).
This interface is made known to the clients through a server process binder (to be discussed later).

11. Remote Procedure Call (Solution for P2 - Building client program)
P2: How does the client transfer its call request (the procedure name) and the arguments to the server via network?
Marshalling and communication with server:
For each remote procedure call, a (client) stub procedure is generated and attached to the (client) program.
Replace the remote procedure call to a (local) call to the stub procedure.

12. Remote Procedure Call (Solution for P2 - Building client program)
The (codes in the) stub procedure marshals (the input) arguments and places them into a message together with the procedure identifier (of the remote procedure).
Use IPC primitive to send the (call request) message to the server and wait the reply (call return) message (DoOperation).

13. Remote Procedure Call (Solution for P3 - Building server program)
P3: How does the server react the request of the client? From which port? How to select the procedure? How to interpret the arguments?
Despatching, Unmarshalling, communication with client:
A despatcher is provided. It receives the call request message from the client and uses the procedure identifier in the message to select one of the server stub procedures and passes on the arguments.

14. Remote Procedure Call (Solution for P3 - Building server program)
For each procedure at the server which is declared (at the sever interface) as callable remotely, a (server) stub procedure is generated.
The task of a server stub procedure is to unmarshal the arguments, call the corresponding (local) service procedure. On return, the stub marshals the output arguments into a reply (call return) message and sends it back to the client.

15. Remote Procedure Call (Solution for P4 - Building server program)
P4: How does the server transmit the reply back?
On return, the stub marshals the output arguments into a reply (call return) message and sends it back to the client.

16. Remote Procedure Call (Solution for P5 - Building client program)
P5: How does the client receive the reply?
The stub procedure of the client unmarshals the result arguments and returns (local call return). Note that the original remote procedure call was transformed into a (local) call to the stub procedure.

17. Remote Procedure Call (Summary of RPC steps)
1. The client provides the arguments and calls the client stub in the normal way.
2. The client stub builds (marshals) a message (call request) and traps to OS & network kernel.
3. The kernel sends the message to the remote kernel.
4. The remote kernel receives the message and gives it to the server dispatcher.
5. The server dispatcher selects the appropriate server stub.
6. The server stub unpacks (unmarshals) the parameters and call the corresponding server procedure.

18. Remote Procedure Call (Summary of RPC steps)
7. The server procedure does the work and returns the result to the server stub.
8. The server stub packs (marshals) it in a message (call return) and traps it to OS & network kernel.
9. The remote (receiver) kernel sends the message to the client’s kernel.
10. The client’s kernel gives the message to the client stub.
11. The client stub unpacks (umarshals)the result and
returns to client.

19. Remote Procedure Call (Summary of RPC steps)
Figure 2-18 (Tanenbaum95)

20. Remote Procedure Call (Binding)
Locating a remote procedure
To achieve configuration flexibility, linking to remote procedure is usually done dynamically through the use of a binder process.
A RPC binder provides mapping of a server’s name to the server’s address.
The binder’s address is pre-assigned and is made known system-wide.

21. Remote Procedure Call (Binding)
A client accessing a service first looks up the service’s address from the binder. Remote procedure calls can then use the server’s address in its IPC primitives (used in the client stub).
When a server is relocated, the client’s codes need not be changed. Only the server’s re-registration is required.

22. Remote Procedure Call (Implementation - Interface processing)
Interface processing: Integrating the RPC mechanism with client and server programs in conventional programming languages. The Interface language is required.
Both client and server assign the same unique procedure identifier to each procedure in an interface (they are numbered 0,1,2 …) and the procedure identifier is included in request message
It processes dispatching of request messages to the appropriate procedure in the server, and marshalling and unmarshalling of arguments in the client and server.

23. Remote Procedure Call (Implementation - Interface processing)
Interface definitions written in an Interface Definition Language (IDL); Interface compiler compiling the IDL performs the following tasks:
Generate stub procedures for the client and dispatcher & stub procedures for the server to correspond to each procedure signature in the interface.
The stub procedures (dispatcher & stub procedures) will be linked with the client (server) program.

24. Remote Procedure Call (Implementation - Interface processing)
Use the signatures of the procedures in the interface - which define the argument and result types - to generate (un)-marshalling operations in each stub procedure.
Generate procedure headings for each procedure in the service. The service supplies the bodies of these procedures.
Communication handling: transmitting and receiving request and reply messages, e.g. TCP, UDP.

25. Case Study: SUN RPC Interface definition language: XDR
Interface compiler: rpcgen
Communication handling: TCP or UDP
Version: RPCSRC 3.9 (4.3BSD UNIX)

26. Case Study: SUN RPC SUN RPC consists of the following parts:
rpcgen: a compiler that takes the definition of a remote procedure interface, and generates the client stubs and the server stubs;
XDR: a standard way of encoding data in a portable fashion between different systems;
A run-time library to handle all the details.

27. Case Study: SUN RPC
Simple example: the client calls using RPC and the server have the following two functions:
bin_date_1 returns the current time as the number of seconds since 00:00:00 GMT, January 1, 1970.
str_date_1 takes a long integer value from the previous function and converts it into an ASCII string that is fit for human consumption.

28. RPC specification file
Case Study: SUN RPC
server program
data_proc.c
server procedure
date.x
RPC specification file
rdate.c
client main function CC
data_svc
rdate
server stub
data.h
data_svc.c
data_clnt.c
RPC
run-time
library
rpcgen
client program
client stub CC

29. Case Study: SUN RPC Generate the executable client program:
cc -o rdate rdate.c date_clnt.c -lnsl
Generate the executable server program:
cc -o date_svc date_proc.c date_svc.c -lnsl

30. Case Study: SUN RPC date.x 0x20000000 - 0x3fffffff is defined by user;
program DATE_PROG {
version DATE_VERS {
long BIN_DATE(void) = 1; /* procedure number = 1 */
string STR_DATE(long) = 2; /* procedure number = 2 */
} = 1; /* version number = 1 */
} = 0x ; /* program number = … */
0x x3fffffff is defined by user;

31. Case Study: SUN RPC date.h (generated by rpcgen)
#define DATE_PROG ((u_long) 0x )
#define DATE_VERS ((u_long) 1)
#define BIN_DATE ((u_long) 1)
extern long *bin_date_1();
#define STR_DATE ((u_long) 2)
extern char **str_date_1();

32. Case Study: SUN RPC rdate.c
/* client program for remote date service. */
#include <stdio.h>
#include <rpc/rpc.h> /* standard RPC include file */
#include “date.h” /* generated by rpcgen */
main(argc, argv)
int argc;
char *argv[];

33. Case Study: SUN RPC { CLIENT *cl; /* RPC handle */ char *server;
long *lresult; /* return value from bin_date_1 */
long **sresult; /* return value from str_date_1 */
if (argc != 2) {
fprintf(stderr, “usage: %s hostname\n”, argv[0]);
exit(1); }
server = argv[1];

34. Case Study: SUN RPC /* create the client handle */
if ((cl = clnt_create(server, DATE_PROG, DATE_VERS, “udp”))
== NULL) {
/* couldn’t establish connection with server */
clnt_pcreateerror(server); exit(2); }
/* first call the remote procedure “bin_date” */
if ((lresult = bin_date_1(NULL, cl)) == NULL) {
clnt_perror(cl, server); exit(3);
printf(“time on host %s = %ld\n”, server, *lresult);

35. Case Study: SUN RPC /* now call the remote procedure “str_date” */
if ((sresult = str_date_1(lresult, cl)) == NULL) {
clnt_perror(cl, server); exit(4); }
printf(“time on host %s = %s\n”, server, *sresult);
clnt_destroy(cl); /* done with the handle */
exit(0);

36. Case Study: SUN RPC date_proc.c
/* remote procedure; called by server stub */
#include <rpc/rpc.h> /* standard RPC include file */
#include “date.h” /* generated by rpcgen */
/* return the binary date and time */
long *bin_date_1() {
static long timeval; /* must be static */
long time(); /* UNIX function */

37. Case Study: SUN RPC timeval = time((long *) 0); return(&timeval); }
/* convert a binary time and return a human readable string */
char **str_date_1(long *bintime) {
static long *ptr; /* must be static */
char *ctime(); /* UNIX function */
ptr = ctime(bintime); /* convert to local time */
return(&ptr); /* return the address of pointer */

38. Case Study: SUN RPC
clnt_create: create an RPC handle to the specified program and version on a host;
static variable: if we do not use static variables, their values would be undefined after return statement passes control back to the server stub that calls our remote procedure.

39. Case Study: SUN RPC Steps involved in RPC calls rdate (client)
portmapper
daemon
date_svc
(server) 1
Remote
system 3 2 4

40. Case Study: SUN RPC
1. The server program calls a function in the RPC library, svc_register, register its program number and version to the remote system.
This function contacts the port mapper process to register itself.
2. The client program calls clnt_create to contact the port mapper to find out the UDP port for the server.
3. Call bin_date_1 remote function and receive its return value.
4. Call str_date_1 remote function and receive its return value.