/**********************************************************************/

/* Note : A very short introduction on RPC.

*/
/* By
: Albert van der Sel
*/
/* Version: 1
*/
/* Date : 11/06/2009
*/
/**********************************************************************/
This very short note, introduces the concept of RPC (Remote Procedure Call).

===========================
Section 1. RPC: What is it?
===========================
RPC lets you write programs, that may call procedures from other programs on dif
ferent computers.
(If your program would call a procedure from a local program (on the same machin
e), you would
use a "local procedure call").
We say "procedure", but what about 'methods' or 'memberfunctions' from (oo like)
objects?
Should we then call it "Remote Method Invocation" (RMI), or something like that?
Indeed there is already
a mechanism named "RMI" in the java world. But the mechanics of RMI is somewhat
different from RPC, although
in many respects they are quite similar.
(A seperate short note on RMI can be found on the "Java links" page, of this sit
e.)
Let's try to list a few characteristics of RPC:
- RPC is quite "old". So, at that time, programming was mainly done with procedu
ral languages
like C. Therefore, writing procedures was the "thing to go for". Hence the name
RPC is thus quite obvious.
Even if the basic idea is quite old, the protocol has evolved, and is still heav
ily used at many
Client/Server systems, and other distributed systems.
Here you might think of many business-like programs (like for example financial
transaction systems).
Yes, but even many "stuff" we all take for granted on the OS level, uses RPC.
Think of authentication services with a client and server part, or some types of
file- and
print services, or network filesystems (nfs) etc..
- RPC is an IPC (Inter Process Communication) implementation. It's a way to let
remote processes communicate.
Especially here, it is understood that the client wants a remote Server process
to do some work, and
typically return values to the client.
RPC is a high level protocol, that usually "sits" above "sockets", and below the
sockets functionality, ofcourse,
the transport layer and the network layer are in place (which usually is TCP IP)
.
But, instead of the sockets interface, other communication facilities might be u

sed, like "named pipes".

And even "Transport Independent" (TI) RPC might be used, and that usually might
need special libararies
at the client and Server.
But as said, socket based RPC is widely in use, and the following figure tries t
o show that.
--------| RPC |
--------|sockets| (portnumbers / registering portnumbers)
--------|TCP/UDP|
--------| IP |
--------- Synchroneous and Asynchroneous RPC.
The traditional RPC model was synchroneous, which means that the client calls th
e remote procedure,
and "waits" for the result to return.
In many articles, that mechanism is depicted as in the following picture.
|
|
|call
|
------------>|
response
|
<------------|
|
|
|
|
Client

Server

The vertical lines then, are supposed to depict the

Ofcourse, a number of obvious drawbacks can be seen
client
must wait for the Server to give the response.
Asynchronous RPC, separates a remote procedure call
resolves
a number of limitations of traditional, synchronous

"activity" of the process.

on this model. For one, the
from its return value, which
RPC

- Stubs, marshalling:
The client and Server processes, might reside on very different platforms, and O
perating Systems.
Furthermore, the client and Server might even be programmed with completely diff
erent compilers.
So, for example, what the Server process expects to get in terms of data represe
ntations, formats,
and parameters, might be very different from what the client thinks is right.
So, at the location of the client and Server, socalled "stubs" has to be present
,
along with some other rpc runtime libraries, which which will do the neccessary
marshalling.
Now let us try to make a simplistic figure, that gives an idea on how RPC works:
--------

----------

|Client|
<------|Server |
-------------->
---------|
|
------------------------|Client Stub|
|Server Stub|
------------------------|
|
------------------------|RPC Runtime|
|RPC Runtime|
|Library
|
|Library
|
------------------------|
network
|
---------------------------------------- Locating the services:
How does the client "find" the machine and Server process, that is supposed to r
un a certain procedure?
You can imaging, that the client wants to know:
Hostname (ip address)
program identifier
procedure identifier
Well, to find a machine, there are several ways to do that.
And it must certainly be so, that RPC includes support for looking up the portnu
mber of a remote program.
So portmappers (or other modules with some name, but with the same function) mus
t be present on any
machine running RPC Servers.
A RPC Server will register itself on which ports they listen, for providing serv
ices.

That's it. But I told you so: it's short !