Remote
Procedure
Call
(RPC)
By: Ambrose Njeru [BSc, Msc] 1
Introduction
Remote Procedure Call (RPC) is a powerful
technique for constructing distributed, client-server
based applications.
RPC provides a different paradigm for accessing
network services.
Instead of accessing remote services by sending and
receiving messages, a client invokes services by
making a local procedure call.
The local procedure hides the details of the network
communication.
By: Ambrose Njeru [BSc, Msc] 2
Introduction
It is based on extending the conventional local
procedure calling so that the called procedure need
not exist in the same address space as the calling
procedure.
The two processes may be on the same system, or
they may be on different systems with a network
connecting them.
The main goal of RPC is to hide the existence of the
network from a program.
As a result, RPC doesn't quite fit into the OSI model
because:
By: Ambrose Njeru [BSc, Msc] 3
Introduction
The message-passing nature of network
communication is hidden from the user. The user
doesn't first open a connection, read and write data,
and then close the connection. Indeed, a client often
does not even know they are using the network!
RPC often omits many of the protocol layers to
improve performance. Even a small performance
improvement is important because a program may
invoke RPCs often. For example, on (diskless) Sun
workstations, every file access is made via an RPC.
By: Ambrose Njeru [BSc, Msc] 4
Introduction
By: Ambrose Njeru [BSc, Msc] 5
Introduction
When making a Remote Procedure Call:
1. The calling environment is suspended, procedure
parameters are transferred across the network to
the environment where the procedure is to execute,
and the procedure is executed there.
2. When the procedure finishes and produces its
results, its results are transferred back to the
calling environment, where execution resumes as if
returning from a regular procedure call.
By: Ambrose Njeru [BSc, Msc] 6
Working of RPC
By: Ambrose Njeru [BSc, Msc] 7
Working of RPC
RPC is especially well suited for client-server (e.g.
query-response) interaction in which the flow of
control alternates between the caller and callee.
Conceptually, the client and server do not both
execute at the same time. Instead, the thread of
execution jumps from the caller to the callee and
then back again.
The following steps take place during a Remote
Procedure Call:
By: Ambrose Njeru [BSc, Msc] 8
Working of RPC
1. A client invokes a client stub procedure, passing
parameters in the usual way. The client stub resides
within the client’s own address space.
2. The client stub marshalls (pack) the parameters
into a message. Marshalling includes converting
the representation of the parameters into a
standard format, and copying each parameter into
the message.
3. The client stub passes the message to the transport
layer, which sends it to the remote server machine.
By: Ambrose Njeru [BSc, Msc] 9
Working of RPC
4. On the server, the transport layer passes the
message to a server stub, which demarshalls
(unpack) the parameters and calls the desired
server routine using the regular procedure call
mechanism.
5. When the server procedure completes, it returns to
the server stub (e.g., via a normal procedure call
return), which marshalls the return values into a
message. The server stub then hands the message
to the transport layer.
By: Ambrose Njeru [BSc, Msc] 10
Working of RPC
6. The transport layer sends the result message back
to the client transport layer, which hands the
message back to the client stub.
7. The client stub demarshalls the return parameters
and execution returns to the caller.
By: Ambrose Njeru [BSc, Msc] 11
RPC Issues
1. Marshalling:
Parameters must be marshalled into a standard
representation.
Parameters consist of simple types (e.g., integers)
and compound types (e.g., C structures or Pascal
records). Moreover, because each type has its own
representation, the types of the various parameters
must be known to the modules that actually do the
conversion. For example, 4 bytes of characters would
be uninterrupted, while a 4-byte integer may need to
the order of its bytes reversed.
By: Ambrose Njeru [BSc, Msc] 12
RPC Issues
2. Semantics:
Call-by-reference not possible: the client and server
don't share an address space. That is, addresses
referenced by the server correspond to data residing
in the client's address space.
One approach is to simulate call-by-reference using
copy-restore. In copy-restore, call-by-reference
parameters are handled by sending a copy of the
referenced data structure to the server, and on return
replacing the client's copy with that modified by the
server.
By: Ambrose Njeru [BSc, Msc] 13
RPC Issues
However, copy-restore doesn't work in all cases. For
instance, if the same argument is passed twice, two
copies will be made, and references through one
parameter only changes one of the copies.
3. Binding:
How does the client know who to call, and where the
service resides?
The most flexible solution is to use dynamic binding
and find the server at run time when the RPC is first
made. The first time the client stub is invoked, it
contacts a name server to determine the transport
address at which the server resides.
By: Ambrose Njeru [BSc, Msc] 14
RPC Issues
4. Transport protocol: What transport protocol
should be used?
5. Exception handling: How are errors handled?
By: Ambrose Njeru [BSc, Msc] 15
RPC: Binding
Binding consists of two parts:
Naming: Refers to what service the client wants
to use. Remote procedures are named through
interfaces. An interface uniquely identifies a
particular service, describing the types and
numbers of its arguments. It is similar in purpose
to a type definition in programming languages.
For example, a ``phone'' service interface might
specify a single string argument that returns a
character string phone number.
By: Ambrose Njeru [BSc, Msc] 16
RPC: Binding
Locating: Refers to finding the transport address
at which the server actually resides. Once we have
the transport address of the service, we can send
messages directly to the server.
In a system, a server having a service to offer,
exports an interface for it. Exporting an interface
registers it with the system so that clients can use
it.
A client must import an (exported) interface
before communication can begin. The export and
import operations are analogous to those found in
object-oriented systems.
By: Ambrose Njeru [BSc, Msc] 17
Semantics of RPC
Unlike normal procedure calls, many things can go
wrong with RPC.
Normally, a client will send a request, the server will
execute the request and then return a response to the
client.
What are appropriate semantics for server or network
failures? The possibilities are:
1. Just hang forever waiting for the reply that will never
come. This models regular procedure call. If a
normal procedure goes into an infinite loop, the
caller never finds out. Of course, few users will like
such semantics..
By: Ambrose Njeru [BSc, Msc] 18
Semantics of RPC
2. Time out and raise an exception or report failure to
the client. Of course, finding an appropriate timer
value is difficult. If the remote procedure takes a long
time to execute, a timer might time-out too quickly.
3. Time out and retransmit the request.
While the last possibility seems the most reasonable,
it may lead to problems. Suppose that:
1. The client transmits a request, the server executes it,
but then crashes before sending a response. If we
don't get a response, is there any way of knowing
whether the server acted on the request?
By: Ambrose Njeru [BSc, Msc] 19
Semantics of RPC
2. The server restarts, and the client retransmits the
request. What happens? Now, the server will reject
the retransmission because the supplied unique
identifier no longer matches that in the server's
export table. At this point, the client can decide to
rebind to a new server and retry, or it can give up.
3. Suppose the client rebinds to the another server,
retransmits the request, and gets a response. How
many times will the request have been executed?
At least once, and possibly twice. We have no way
of knowing.
By: Ambrose Njeru [BSc, Msc] 20
Semantics of RPC
Operations that can safely be executed twice are
called idempotent.
For example, fetching the current time and date, or
retrieving a particular page of a file.
Is deducting KShs 10,000 from an account
idempotent? No. One can only deduct the money
once.
Likewise, deleting a file is not idempotent. If the
delete request is executed twice, the first attempt will
be successful, while the second attempt produces a
“nonexistent file” error.
By: Ambrose Njeru [BSc, Msc] 21
Semantics of RPC
Semantics of RPCs could be categorized into three
ways:
Exactly once:
The most desirable kind of semantics, where every
call is carried out exactly once, no more and no less.
Unfortunately, such semantics cannot be achieved at
low cost; if the client transmits a request, and the
server crashes, the client has no way of knowing
whether the server had received and processed the
request before crashing.
By: Ambrose Njeru [BSc, Msc] 22
Semantics of RPC
At most once:
When control returns to the caller, the operation will
have been executed no more than once. What
happens if the server crashes? If the server crashes,
the client will be notified of the error, but will have no
way of knowing whether or not the operation was
performed.
At least once:
The client just keeps retransmitting the request until
it gets the desired response. On return to the caller,
the operation will have be performed at least one
time, but possibly multiple times.
By: Ambrose Njeru [BSc, Msc] 23
RPC Advantages
1. RPC provides ABSTRACTION i.e. message-passing
nature of network communication is hidden from the
user.
2. RPC often omits many of the protocol layers to improve
performance. Even a small performance improvement is
important because a program may invoke RPCs often.
3. RPC enables the usage of the applications in the
distributed environment, not only in the local
environment.
4. With RPC code re-writing / re-developing effort is
minimized.
5. Process-oriented and thread oriented models supported
by RPC. By: Ambrose Njeru [BSc, Msc] 24