Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details. (A procedure call is also sometimes known as a function call or a subroutine call.) RPC uses the client/server model. The requesting program is a client and the service-providing program is the server. Like a regular or local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple RPCs to be performed concurrently.

1. Mrs S G Bavachkar ATS,SBGI Miraj
Communication
1

2. Mrs S G Bavachkar ATS,SBGI Miraj
Introduction
 Remote procedure Call (RPC)
Hiding most of the intricacies of message passing
client-server applications
2

3. Remote Procedure Calls (RPC)
• Avoid explicit message exchange between processes
• Basic idea is to allow a process on a machine to call
procedures on a remote machine
– Make a remote procedure possibly look like a local one
Mrs S G Bavachkar ATS,SBGI
Miraj
3

4. Conventional Procedure Call
Figure 4-5. (a) Parameter passing in a local procedure call: the
stack before the call to read. (b) The stack while the called
procedure is active.
a) Parameter passing in a local procedure call: the
stack before the call to read(fd,buf,bytes)
b) The stack while the called procedure is active
Mrs S G Bavachkar ATS,SBGI Miraj
4

5. Mrs S G Bavachkar ATS,SBGI Miraj
Client and Server Stubs
Figure 4-6. Principle of RPC between a client and server program.
5

6. Remote Procedure Calls
Mrs S G Bavachkar ATS,SBGI Miraj
Remote procedure call (RPC) abstracts procedure calls
between processes on networked systems.
❒ Stubs – client-side proxy for the actual procedure on the
server.
❒ The client-side stub locates the server and Marshalls the
parameters.
❒ The server-side stub receives this message, unpacks the
marshalled parameters, and performs the procedure on the
server.
6

7. Mrs S G Bavachkar ATS,SBGI Miraj
Passing Value Parameters (1)
Figure 4-7. The steps involved in a doing a
remote computation through RPC. 7

8. Passing Value Parameters
a) Original message on the Pentium (little-endian)
b) The message after receipt on the SPARC (big-endian)
Note: the little numbers in boxes indicate the address of each byte
Mrs S G Bavachkar ATS,SBGI
Miraj
8

9. Passing Value Parameters
a) Original message on the Pentium (little-endian)
b) The message after receipt on the SPARC (big-endian)
c) The message after being inverted (integer 5, string: “LLIJ”)
Note: the little numbers in boxes indicate the address of each byte
Mrs S G Bavachkar ATS,SBGI
Miraj
9

10. Passing reference parameters
– What is Call By Value and Call By Refernce?
– Example: call foo(int, int * ) or read(fd, buf, nbytes)
– Call by copy/restore
– The dreaded “pointer problem”
• Linked list
• Complex graph
a
b
a’
b’
foo(a, &b ) Call foo(a, &b’ )
Copy value a and contents of loc b
into a’ and loc b’
Return Copy contents of loc b’ into b
Machine A
Machine B
Mrs S G Bavachkar ATS,SBGI
Miraj
10

11. Marshalling
Values must cross the network
Machine formats differ
– Integer byte order
• Little-endian or big-endian
– Floating point format
• IEEE 754 or not
Marshalling − transferring data structure used in remote
procedure call from one address space to another.
Define a “network format”, for example following XDR
(eXternal Data Representation) standard
http://www.ietf.org/rfc/rfc1832.txt
Mrs S G Bavachkar ATS,SBGI
Miraj
11

12. RPC: The basic mechanism
Client
routines
Client stub
RPC
runtime
Network
routines
Source: R. Stevens, Unix Network Programming (IPC)
Vol 2, 1998
Server
routines
Server
stub
RPC
runtime
Network
routines
Process
kernel
Process
kernel
Client process Server process 1. Client calls a local procedure on the
client stub
2. The client stub acts as a proxy and
marshalls the call and the args.
3. The client stub send this to the
remote system (via TCP/UDP)
4. The server stub unmarshalls the call
and args from the client
5. The server stub calls the actual
procedure on the server
6. The server stub marshalls the
reply and sends it back to the client
1
2
3
4
5
6
Mrs S G Bavachkar ATS,SBGI
Miraj
12

13. Mrs S G Bavachkar ATS,SBGI Miraj
Remote Procedure Calls (1)
A remote procedure call occurs in the following
steps:
1. The client procedure calls the client stub in the normal
way.
2. The client stub builds a message and calls the local
operating system.
3. The client’s OS sends the message to the remote OS.
4. The remote OS gives the message to the server stub.
5. The server stub unpacks the parameters and calls the
server.
Continued …
13

14. Mrs S G Bavachkar ATS,SBGI Miraj
Remote Procedure Calls (2)
A remote procedure call occurs in the following
steps (continued):
6. The server does the work and returns the result to the
stub.
7. The server stub packs it in a message and calls its local
OS.
8. The server’s OS sends the message to the client’s OS.
9. The client’s OS gives the message to the client stub.
10. The stub unpacks the result and returns to the client.
14

15. Asynchronous RPC
As in conventional procedure calls, when a client calls a remote
procedure, the client will block until a reply is returned. This strict
request-reply behaviour is unnecessary when there is no result to
return, and only leads to blocking the client while it could have
proceeded and have done useful work just after requesting the
remote procedure to be called.
RPC systems may provide facilities for what are called
asynchronous RPCs, by which a client immediately continues after
issuing the RPC request. With asynchronous RPCs, the server
immediately sends a reply back to the client the moment the RPC
request is received, after which it calls the requested procedure. The
reply acts as an acknowledgement to the client that the server is
going to process the RPC. The client will continue without further
blocking as soon as it has received the server’s acknowledgement
Mrs S G Bavachkar ATS,SBGI
Miraj
15

16. Mrs S G Bavachkar ATS,SBGI Miraj
Traditional RPC (1)
Figure 4-10. (a) The interaction between client and
server in a traditional RPC. 16

17. Mrs S G Bavachkar ATS,SBGI Miraj
Asynchronous RPC (2)
Figure 4-10. (b) The interaction using asynchronous RPC.
17

18. Mrs S G Bavachkar ATS,SBGI Miraj
• communication between the client and server through
two asynchronous RPCs
• The client first calls the server to hand over a list of host
names that should be looked up, and continues when the
server has acknowledged the receipt of that list. The
second call is done by the server, who calls the client to
hand over the addresses it found. Combining two
asynchronous RPCs is sometimes also referred to as a
deferred synchronous RPC
18

19. Mrs S G Bavachkar ATS,SBGI Miraj
Asynchronous RPC (3)
Figure 4-11. A client and server interacting through
two asynchronous RPCs. 19

20. Mrs S G Bavachkar ATS,SBGI Miraj
DCE RPC
 Distributed Computing Environment (DCE) developed by
Open Software Foundation (OSF)
 DCE is a true middleware system in that it is designed to
execute as a layer of abstraction between existing (network)
operating systems and distributed applications. Initially
designed for UNIX
 There are a number of services that form part of DCE itself.
The distributed file service is a worldwide file system that
provides a transparent way of accessing any file in the
system in the same way.
 The directory service is used to keep track of the location of
all resources in the system. These resources include
machines, printers, servers, data, and much more.
20

21. Mrs S G Bavachkar ATS,SBGI Miraj
 The security service allows resources of all
kinds to be protected, so access can be
restricted to authorized persons
 The distributed time service is a service that
attempts to keep clocks on the different
machines globally synchronized
 Goals of DCE RPC
 First and foremost, the RPC system makes it
possible for a client to access a remote service
by simply calling a local procedure
 To start with, the RPC system can automatically
locate the correct server, and subsequently set
up the communication between client and server
software (generally called binding).
21

22. Mrs S G Bavachkar ATS,SBGI Miraj
 Finally, the RPC system can automatically handle data type
conversions between the client and the server, even if they run
on different architectures and have a different byte ordering.
Writing a Client and a Server
22

23. Mrs S G Bavachkar ATS,SBGI Miraj
Writing a Client
and a Server (1)
Figure 4-12. The steps in writing a client and
a server in DCE RPC. 23

24. Mrs S G Bavachkar ATS,SBGI Miraj
Writing a Client and a Server (2)
 The header file contains the unique identifier, type
definitions, constant definitions, and function prototypes. It
should be included (using #include) in both the client and
server code. The client stub contains the actual
procedures that the client program will call.
 The client stub also handles unpacking the reply and
returning values to the client.
 The server stub contains the procedures called by the
runtime system on the server machine when an incoming
message arrives. These, in turn, call the actual server
procedures that do the work.
 The next step is for the application writer to write the client
and server code. Both of these are then compiled, as are
the two stub procedures 24

25. Mrs S G Bavachkar ATS,SBGI Miraj
Binding a Client to a Server (1)
• Registration of a server makes it possible for
a client to locate the server and bind to it.
• Server location is done in two steps:
1. Locate the server’s machine.
2. Locate the server on that machine.
25

26. Mrs S G Bavachkar ATS,SBGI Miraj
Binding Client to Server (DCE RPC)
 Server asks operating system for an end point (port)
 Register the endpoint with DCE daemon that records in the end
table
 Server register with directory server with its network address and
its name (program name)
 Now Client pass the name to directory server and find the server
network address
 Client goes to DCE daemon (well know port) on that machine
and ask for look up the end point (port) of the server in its end point
table
 In DCE, a table of (server, endpoint)-pairs is maintained on each
server machine by a process called the DCE daemon.
 The DCE daemon records this information (including which
protocols the server speaks) in the endpoint table for future use.
26

27. Mrs S G Bavachkar ATS,SBGI Miraj
Binding a Client to a Server (2)
Figure 4-13. Client-to-server binding in DCE.
27