Contents – RPC

† Distributed design
ƒ Computer networks and communication at a high level
ƒ Basics of Client/Server architectures
• programming concept
• interoperability
• binding to services
• delivery guarantees
Remote Procedure Call (RPC)
† Putting all together: RPC
ƒ programming languages
Cesare Pautasso (Gustavo Alonso) ƒ binding
Computer Science Department
Swiss Federal Institute of Technology (ETHZ) ƒ interface definition language
[email protected] ƒ programming RPC
http://www.iks.inf.ethz.ch/
† RPC in the context of large information systems (DCE, TP-Monitors)

©IKS, ETH Zürich. 2

IP, TCP, UDP and RPC Sockets vs. Remote Procedures

† The most accepted standard for † Yet sockets are quite low level † Two alternatives for the design
network communication is IP for many applications, thus, RPC of distributed programs.
(Internet Protocol) which (Remote Procedure Call) Socket Protocol Socket
provides unreliable delivery of appeared as a way to † Bottom-Up
single packets to one-hop ƒ hide communication details 1. First design network protocol
distant hosts behind a procedural call 2. Build program that follows the
† IP was designed to be hidden ƒ bridge heterogeneous protocol using sockets
behind other software layers: environments † Top-Down
ƒ TCP (Transport Control Design program first
RPC
† RPC is the standard for 1. Procedure Procedure
Protocol) implements distributed (client-server) 2. Partition the program in Protocol
connected, reliable message computing different modules
exchange
3. Describe the set of procedures
ƒ UDP (User Datagram that make up the module
Protocol) implements RPC interface
unreliable datagram based What is the advantage?
SOCKETS 4. Place modules on different
message exchanges
network hosts Using an RPC Compiler the
† TCP/IP and UDP/IP are visible to communication protocol
applications through sockets. TCP, UDP 5. Add the network protocol to
The purpose of the socket make the procedures is generated automatically
interface was to provide a UNIX- IP communicate
from the interface description
like file abstraction
©IKS, ETH Zürich. 3 ©IKS, ETH Zürich. 4
The basics of client/server Problems to solve
† Imagine we have a program (a † Ideally, we want he programs to 1. How to make the service 3. How to find the service one
server) that implements certain behave like this (sounds simple?, invocation part of the language actually wants among a
services. Imagine we have other well, this idea is only 20 years in a more or less transparent potentially large collection of
programs (clients) that would like old): manner. services and servers.
to invoke those services. ƒ Don’t forget this important ƒ The goal is that the client
Machine A Machine B
† To make the problem more (client) (server) aspect: whatever you does not necessarily need to
interesting, assume as well that: design, others will have to know where the server
ƒ client and server can reside on program and use resides or even which server
Service request
different computers and run provides the service.
on different operating 2. How to exchange data between
systems machines that might use 4. How to deal with errors in the
ƒ the only form of different representations for service invocation in a more or
communication is by sending Service response different data types. This less elegant manner:
messages (no shared memory, involves two aspects: ƒ server is down,
no shared disks, etc.) ƒ data type formats (e.g., byte ƒ communication is down,
ƒ some minimal guarantees are orders in different ƒ server busy,
to be provided (handling of architectures)
failures, call semantics, etc.) ƒ data structures (need to be ƒ duplicated requests ...
ƒ we want a generic solution Execution Thread flattened and the
and not a one time hack reconstructed)
Message
©IKS, ETH Zürich. 5 ©IKS, ETH Zürich. 6

1. RPC as a Programming tool 2. Interoperability

† The notion of distributed service † Client/Server architectures are † When exchanging data † The concept of transforming the
invocation became a reality at based on Remote Procedure between clients and servers data being sent to an
the beginning of the 80’s when Calls (RPC) residing in different intermediate representation
procedural languages (mainly C) † Once we are working with environments (hardware or format and back has different
were dominant. remote procedures in mind, software), care must be taken (equivalent) names:
† In procedural languages, the there are several aspects that that the data is in the ƒ marshalling/un-marshalling
basic module is the procedure. are immediately determined: appropriate format: ƒ serializing/de-serializing
A procedure implements a ƒ The input and output ƒ byte order: differences † The non-standard intermediate
particular function or service parameters of the procedure between little endian and representation format is
that can be used anywhere call are used for exchanging big endian architectures typically system dependent.
within the program. data (high order bytes first or last For instance:
† It seemed natural to maintain ƒ Pointers cannot be passed as in basic data types)
this same notion when talking ƒ data structures: like trees, ƒ SUN RPC: XDR (External Data
parameters in RPC, opaque Representation)
about distribution: the client references are needed hash tables,
makes a procedure call to a instead so that the client multidimensional arrays, or † Having an intermediate
procedure that is implemented can use this reference to records need to be flattened representation format simplifies
by the server. refer to the same data (cast into a string so to the design, otherwise a node
† Since the client and server can structure or entity at the speak) before being sent will need to be able to
be in different machines, the server across different calls. † This is best done using an transform data to any possible
procedure call is remote. intermediate representation format
format
©IKS, ETH Zürich. 7 ©IKS, ETH Zürich. 8
Example (XDR in SUN RPC) 3. Binding
† Marshalling or serializing can be † SUN XDR follows a similar † A service is provided by a server † With a distributed binder, several
done by hand (although this is approach: located at a particular IP address general operations are possible:
not desirable) using (in C) sprintf ƒ messages are transformed into and listening to a given port ƒ REGISTER (Exporting an
and sscanf: a sequence of 4 byte objects, † Binding is the process of interface): A server can
each byte being in ASCII code mapping a service name to an register service names and the
Message= “Cesare” “ETHZ” “2006” ƒ it defines how to pack different address and port that can be corresponding port
data types into these objects, used for communication ƒ WITHDRAW: A server can
char *name=“Cesare”, place=“ETHZ”; which end of an object is the purposes withdraw a service
int year=2004; most significant, and which Binding can be done:
† ƒ LOOKUP (Importing an
sprintf(message, “%d %s %s %d %d”,
byte of an object comes first ƒ locally: the client must know interface): A client can ask the
strlen(name), name, strlen(place), place, ƒ the idea is to simplify the name (address) of the binder for the address and
year); computation at the expense of host of the server port of a given service
bandwidth ƒ distributed: there is a † There must also be a way to
Message after marshalling = 6 String length separate service (service locate the binder (predefined
“6 Cesare 4 ETHZ 2006”
C e s a location, name and directory location, environment variables,
String content services, etc.) in charge of configuration file, broadcasting to
Remember that the type and r e all nodes looking for the binder)
† mapping names and
number of parameters is known 4 String length addresses. This service must † Clients usually cache binding
in advance, we only need to E T H Z String content be reachable by all information (rebinding is
agree on the syntax ... 2 0 0 6 Number participants attempted on failures)

©IKS, ETH Zürich. 9 ©IKS, ETH Zürich. 10

4. Call semantics Defining Call semantics

What happens when a LOCAL † A client makes an RPC to a † At least-once: the procedure will
procedure is called? service at a given server. After a be executed if the server does
† The procedure always runs once, How many times time-out expires, the client may not fail, but it is possible that it
exactly. should this procedure run? decide to re-send the request. If is executed more than once.
What happens when a REMOTE after several tries there is no This may happen, for instance, if
procedure is called? success, what may have the client re-sends the request
Deposit(MyAccount, $99); happened depends on the call after a time-out. If the server is
† The procedure never runs because semantics: designed so that service calls are
the server is down. idempotent (produce the same
† The procedure does not run because outcome given the same input),
the client is disconnected from the † Maybe: no guarantees. The this might be acceptable.
network. procedure may have been
Reminder: executed (the response † At most-once: the procedure
† The procedure runs, but the client does message(s) was lost) or may will be executed either once or
not notice because the result is lost. it looks like not at all. Re-sending the
have not been executed (the
† The procedure runs, but the server a procedure call, request message(s) was lost). request will not result in the
crashes in the middle but the parameters are It is very difficult to write procedure executing several
† The procedure runs, twice, because the programs based on this type of times. The server must perform
sent back and forth best effort semantics since the some kind of duplicate
client has resent the request packet. detection and filtering and
† If all goes well, the procedure runs
on the network! programmer has to take care of
all possibilities reply retransmission
once.

©IKS, ETH Zürich. 11 ©IKS, ETH Zürich. 12

RPC Error semantics
Type of failure
Semantics Normal execution Network failure Server failure
Maybe Request sent: 1 Request sent: 0/1 Request sent: 1
Execution: 1 Execution: 0/1 Execution: 0/1
Result sent: 1 Result sent: 0/1 Result sent: 0/1
Result received: 1 Result received: 0/1 Result received: 0/1

At-Least-Once Request sent: 1 Request sent: 1/N Request sent: 1/N

Execution: 1 Execution: 1/N Execution: 0/N How RPC works
Result sent: 1 Result sent: 1/N Result sent: 0/N
Result received: 1 Result received: 1 Result received: 0/1

At-Most-Once Request sent: 1 Request sent: 1/N Request sent: 1/N

Execution: 1 Execution: 1 Execution: 0/1
Result sent: 1 Result sent: 1/N Result sent: 0/N
Result received: 1 Result received: 1 Result received: 0/1

©IKS, ETH Zürich. 13

Making it work in practice In more detail

† One cannot expect the Client Client Comm. Comm. Server Server
programmer to implement all CLIENT Client process Binder
code stub Module module stub code
these mechanisms every time a call to remote procedure
distributed application is Register service request
developed. Instead, they are RPC bind
CLIENT stub procedure ACK
provided by a so called RPC Look up request
system (a first example of low Bind
level middleware) Marshalling Look up response
Send Communication
† What does an RPC system do? send
module
ƒ Provides an interface RPC request
definition language (IDL) to
describe the services call
ƒ Generates all the additional Communication
SERVER stub procedure
code necessary to make a module
Unmarshalling
procedure call remote and to Return return
deal with all the Dispatcher
communication aspects (select
RPC response
ƒ Provides a binder in case it SERVER stub)
has a distributed name and remote procedure
directory service system Server process return

©IKS, ETH Zürich. 15 ©IKS, ETH Zürich. 16

IDL (Interface Definition Language) Putting it all together
† All RPC systems come with a † Given an IDL specification, the client process DCE server process
language that allows to interface compiler performs a development
environment
describe services in an abstract variety of tasks to generate the client
IDL
server
manner (independent of the stubs in a target programming code code
programming language used). language (like C):
This language has the generic 1. Generates the client stub IDL
name of IDL (e.g., the IDL of SUN procedure for each procedure sources
RPC is XDR) language specific language specific
signature in the interface. The call interface call interface
† The IDL allows to define each stub will be then compiled and
client stub server stub
service in terms of their names, linked with the client code IDL compiler
and input and output 2. Generates a server stub. It can
parameters (plus maybe other also create a server main, with the RPC API RPC API
relevant aspects). stub and the dispatcher compiled
RPC run time interface RPC run time
† An interface compiler is then and linked into it. This code can service library headers service library
used to generate the stubs for then be extended by the
clients and servers (rpcgen in developer by writing the
SUN RPC). It might also implementation of the
generate procedure headings procedures
that the programmer can then 3. It might generate a *.h file for RPC security cell distributed thread
use to fill out the details of the importing the interface and all protocols service service file service service
server-side implementation. the necessary constants and types DCE runtime environment
©IKS, ETH Zürich. 17 ©IKS, ETH Zürich. 18

RPC in pseudocode Programming RPC directly

//your client code //rpc server main loop † RPC usually provides different † The Simplified Interface (in SUN
result = function(parameters) void rpc_server() { levels of interaction to provide RPC) has only three calls:
register(“function”,address); different degrees of control over ƒ rpc_reg() registers a
the system: procedure as a remote
//client side stub while (true) { procedure and returns a
function(parameters) { socket s = accept(); //blocking Simplified Interface unique, system-wide
address a = bind(“function”); receive(s,id); identifier for the procedure
socket s = connect(a); if (id == “function”) Top Level ƒ rpc_call() given a procedure
send(s,”function”); dispatch_function(s); Intermediate Level identifier and a host, it
send(s,parameters); close(s); makes a call to that
Expert Level procedure
receive(s,result); //blocking } ƒ rpc_broadcast() is similar to
return result; } Bottom Level rpc_call() but broadcasts the
} message instead
//server side stub † The IDL compiler automatically
void dispatch_function(socket s) { † Each level adds more complexity generates the stubs calling the
to the interface and requires the
receive(s,parameters); programmer to take care of RPC library using defaults.
result = function(parameters); more aspects of a distributed † Direct access allow more control
send(s,result); system of transport protocols, security,
marshalling, binding,
} asynchronous procedures, etc.
©IKS, ETH Zürich. 19 ©IKS, ETH Zürich. 20
RPC Application Example RPC in perspective
ADVANTAGES DISADVANTAGES
SALES POINT CLIENT
IF no_customer_# Server 1 † RPC provided a mechanism to † RPC is not a standard, it is an
implement distributed idea that has been
THEN New_customer New_customer applications in a simple and implemented in many different

DBMS
ELSE Lookup_customer Lookup_customer Customer efficient manner ways (not necessarily
Check_inventory Delete_customer database compatible)
† RPC followed the programming
IF enough_supplies Update_customer techniques of the time † RPC allows designers to build
THEN Place_order (procedural languages) and fitted distributed systems but does
ELSE ... Server 2 quite well with the most typical not solve many of the problems
New_product programming languages (C), distribution creates. In that
thereby facilitating its adoption regard, it is only a low level

DBMS
INVENTORY CONTROL Lookup_product Products
CLIENT Delete_product by system designers construct
database
Lookup_product Update_product † RPC allowed the modular and † RPC was designed with only one
Check_inventory hierarchical design of large type of interaction in mind:
IF supplies_low Server 3 distributed systems: client/server. This reflected the
THEN ƒ client and server are separate hardware architectures at the
Place_order time when distribution meant
Place_order ƒ the server encapsulates and

DBMS
Cancel_order Inventory small terminals connected to a
Update_inventory
Update_inventory and order hides the details of the back mainframe. As hardware and
...
Check_inventory
database end systems (such as networks evolve, more flexibility
databases) was needed
©IKS, ETH Zürich. 21 ©IKS, ETH Zürich. 22

RPC system issues RPC and Concurrency

† RPC was one of the first tools † RPC can be used to build † A local procedure call happens within
that allowed the modular design systems with many layers of the same thread of control. Client Server
of distributed applications abstraction. † A remote procedure call involves at
† RPC implementations tend to be † However, every RPC call implies: least two different threads (one on
quite efficient in that they do not ƒ Several messages through the client and one on the server host)
add too much overhead. the network
However, a remote procedure is † The server may use two threads: the
always slower than a local ƒ At least one context switch dispatcher listens for requests and
procedure: (at the client when it places passes them to a worker thread for
the call, but there might be processing
ƒ should a remote procedure more)
be transparent (identical to a † The client may not block and use a
local procedure)? (yes: easy of ƒ Threads are typically used in listener thread to wait for the results
use; no: increase programmer the server to handle
awareness) concurrent requests
ƒ should location be † When a distributed application
transparent? (yes: flexibility is complex, deep RPC chains are
and fault tolerance; no: easier to be avoided

Dispatcher

Worker
design, less overhead)
ƒ should there be a centralized
name server (binder)?
Listener
©IKS, ETH Zürich. 23 ©IKS, ETH Zürich. 24
RPC Pitfalls DCE
† The Distributed Computing
Local CALL Local Local Client TCP Server Remote Environment is a standard Distributed Applications
Server implementation of RPC and a
P P P Stub IP Stub P distributed run-time environment
provided by the Open Software
† Although RPC strives to keep the † Calls may fail due to network Foundation (OSF). It provides: Distributed Time
remote call transparent, there are problems ƒ RPC File Service Service
a number of limitations † The server address must be ƒ Cell Directory: A sophisticated
† No Shared Memory between configured on the client, unless Name and Directory Service
client and server dynamic binding is used ƒ Time: for clock synchronization RPC
† Arguments and Results are passed † Nobody can snoop the across all nodes
by copy (not by reference). parameters of a local call ƒ Security: secure and
(unless you use a debugger or Cell Directory Security
† Difficult to exchange pointers and authenticated communication Service
you force a core dump…), but Service
complex data structures all parameters of every RPC are ƒ Distributed File: enables sharing
† Cannot pass a file opened on the visible on the network of files across a DCE
client as a parameter to the server environment DCE Thread Service
† The caller of a local procedure
(and viceversa) can be trusted because it is the ƒ Threads: support for threads
† Remote calls are orders of same program. Can the server and multiprocessor
magnitude slower than local ones, trust the client of a remote architectures Transport Service/ OS
do not call too often! procedure in the same way?
©IKS, ETH Zürich. 25 ©IKS, ETH Zürich. 26

DCE’s model and goals From RPC we go to ...

† Not intended as a final product † Microsoft DCOM is built on top Stored procedures Distributed environments
but as a basic platform to build of DCE RPC. † Two tier architectures are, in fact, † When designing distributed
more sophisticated middleware client/server systems. They need applications, there are a lot of
tools some sort of interface to allow crucial aspects common to all of
Distributed Applications clients to invoke the functionality them. RPC does not address any
† Its services are provided as the
most basic services needed in of the server. RPC is the ideal of these issues
any distributed system. Any interface for client/server † To support the design and
other functionality needs to be Encina Monitor interactions on a LAN deployment of distributed
implemented on top of it † To add flexibility to their servers, systems, programming and run
† DCE is not just an specification software vendors added to them time environments started to be
of a standard (e.g., CORBA) but Structured Peer to Reliable the possibility of programming created. These environments
File Peer Queuing procedures that will run inside provide, on top of RPC, much of
an implementation that acts as Service Comm Service
the standard. Since the API is the server and that could be the functionality needed to build
invoked through RPC and run a distributed application
the same across all platforms,
interoperability is always † This turned out to be very useful † The notion of distributed
Encina Encina Toolkit for databases where such environment is what gave rise to
guaranteed
procedures could be used to hide middleware.
† DCE is packaged in a modular the schema and the SQL † Web Services (with SOAP) are an
way so that services that are not OSF DCE programming from the clients. example of extending the notion
used do not need to be licensed The result was stored procedures, of RPC to call services located
a common mechanism found in across the Web.
all database systems
©IKS, ETH Zürich. 27 ©IKS, ETH Zürich. 28