Request/Reply Communication

Yiwei Wu
Outline
 Introduction
 What is RPC?
 How it works?
 RPC Models
 Transparency Issues
 Implementation
 XML-RPC
 Reference
Introduction [1,2,4,7]
 Request/Reply Communication
 The Request/Reply (R/R) communications method is a
very common technique for one application to request
the services of another.
 Most widely used request/reply communication
model is Remote Procedure Call (RPC)
 It is used both by operating systems and applications
 NFS is implemented as a set of RPCs
 DCOM, CORBA, Java RMI, XML-RPC, etc., are all
basically just RPC
What Is RPC [3]
 It is based on extending the notion of conventional, or
local procedure calling, so that the called procedure
need not exist in the same address space as the calling
procedure.
 By using RPC, programmers of distributed applications
avoid the details of the interface with the network. The
transport independence of RPC isolates the application
from the physical and logical elements of the data
communications mechanism and allows the application
to use a variety of transports.
How it works [3]
 The client makes a
procedure call that sends a
request to the server and
waits. The thread is blocked
from processing until either
a reply is received, or it
times out.
 When the request arrives,
the server calls a dispatch
routine that performs the
requested service, and sends
the reply to the client.
RPC Models [4]
 There are several variations on the standard RPC
“synchronous request/response” model
 Each model provides greater flexibility, at the cost
of less transparency
 Certain RPC toolkits support all the different
models
 E.g. ONC RPC
RPC Models – Cont’d
RPC Models – Cont’d
Transparency Issues [4,5,6]
 RPC has a number of limitations that must be
understood to use the model effectively
 Most of the limitations center around transparency
 Transforming a simple local procedure call into
system calls, data conversions, and network
communications increases the chance of something
going wrong
 i.e., it reduces the transparency of distribution
Transparency Issues – Cont’d
 Key Aspects of RPC Transparency
 Parameter passing
 Data representation
 Binding
 Transport protocol
 Exception handling
 Call semantics
 Security
 Performance
Parameter Passing [4,5,6]
 Functions in an application that runs in a single
process may collaborate via parameters and/or
global variables
 Functions in an application that runs in multiple
processes on the same host may collaborate via
message passing and/or non-distributed shared
memory
 However, passing parameters is typically the only
way that RPC-based clients and servers share
information
Parameter Passing – Cont’d
 Parameters that are passed by value are fairly
simple to handle
 The client stub copies the value from the client and
packages into a network message
 Parameters passed by reference are much harder
 e.g., in C when the address of a variable is passed
 Or more generally, handling pointer-based data
structures
 e.g., pointers, lists, trees, stacks, graphs, etc.
Parameter Passing – Cont’d
 Typical solutions include:
 Have the RPC protocol only allow the client to pass
arguments by value
 Use a presentation data format where the user specially
defines what the input arguments are and what the
return values are
 e.g., Sun's XDR routines
 RPC facilities typically provide an “interface definition
language" to handle this
 e.g., CORBA or DCE IDL
Data Representation [4]
 RPC client and server may have different hardware
architectures and therefore may have different data
representations (i.e., the method used to store data).
 RPC systems intended for heterogeneous
environments must be sensitive to byte ordering
differences
 They typically provide tools for automatically
performing data conversion (e.g., rpcgen or idl)
Data Representation – Cont’d
 Examples:
 Sun RPC (XDR)
 Imposes “canonical" big-endian byte-ordering
 Minimum size of any field is 32 bits
 Xerox Courier
 Uses big-endian
 Minimum size of any field is 16 bits
 DCE RPC (NDR)
 Supports multiple presentation layer formats
 Allows the sender to use its own internal format, if it is supported
 The receiver then converts this to the appropriate format, if
different from the sender's format
Binding [4]
 Binding is the process of connecting the client to the
server
 The server, when it starts up, exports its interface
 Identifies itself to a network name server
 Tells RPC runtime its alive and ready to accept calls
 The client, before issuing any calls, imports the server
 RPC runtime uses the name server to find the location of a
server and establish a connection
 The import and export operations are explicit in the
server and client programs
 Breakdown of transparency
Transport Protocol [4,6]
 Some RPC implementations use only a single transport
layer protocol
 Others allow protocol section either implicitly or explicitly
 Some examples:
 Sun RPC
 Earlier versions support only UDP, TCP
 Recent versions are “transport independent"
 DCE RPC
 Runs over many, many protocol stacks
 And other mechanisms that aren't stacks
 e.g., shared memory
 Xerox Courier
 SPP
Exception Handling [4]
 With a local procedure call there are a limited number of things that
can go wrong, both with the call/return sequence and with the
operations
 e.g., invalid memory reference, divide by zero, etc.
 With RPC, the possibility of something going wrong increases, e.g.,
 The actual remote server procedure itself generate an error
 The client stub or server stub can encounter network problems or
machine crashes
 Two types of error codes are necessary to handle two types of
problems
 Communication infrastructure failures
 Service failures
 Another exception condition is a request by the client to stop the
server during a computation
Call Semantics [4]
 When a local procedure is called, there is never any
question as to how many times the procedure
executed
 With a remote procedure, however, if you do not
get a response after a certain interval, clients may
not know how many times the remote procedure
was executed
Call Semantics – Cont’d
 There are three different forms of RPC call semantics:
 Exactly once (same as local IPC)
 Hard/impossible to achieve, because of server crashes or network
failures
 At most once
 If normal return to caller occurs, the remote procedure was executed
one time
 If an error return is made, it is uncertain if remote procedure was
executed one time or not at all
 At least once
 Typical for idempotent procedures, client stub keeps retransmitting
its request until a valid response arrives
 If client must send its request more than once, there is a possibility
that the remote procedure was executed more than once
Security [4]
 Typically, applications making local procedure
calls do not have to worry about maintaining the
integrity or security of the caller/callee
 i.e., calls are typically made in the same address space
 Remote security is handled via distributed
authentication protocols
 e.g., request/reply messages have not been tampered
with (integrity), their contents are not revealed
( confidentiality) , and the same message has not
appeared more than once ( originality )
Performance [4]
 Usually the performance loss from using RPC is an
order of magnitude or more, compared with
making a local procedure call due to
 Protocol processing
 Context switching
 Data copying
 Network latency
 Congestion
Performance – Cont’d
 Another important aspect of performance is how
the server handles multiple simultaneous requests
from clients
 Iterative -- server handles in the same process
 May reduce throughput and increase latency
 Concurrent -- server forks a new process or thread to
handle each request
 May require subtle synchronization, programming, and
debugging techniques to work successfully
 Thread solutions may be non-portable
Implementation – XML-RPC [7,8,9]
 XML-RPC is a simple, portable way to make
remote procedure calls over HTTP.
 It can be used with Perl, Java, Python, C, C++,
PHP and many other programming languages.
 Implementations are available for Unix, Windows
and the Macintosh.
XML-RPC [8]
XML-RPC [8]
 XML-RPC call is conducted between two parties:
 A client to send RPC request
 A server to process RPC request and send back the
return value to the client
 Server’s address is in a standard URL
 The data is composed by a HTTP header and a
XML body
XML-RPC [7]
An example of a typical XML-RPC request would be:

<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>40</i4></value>
</param>
</params>
</methodCall>
XML-RPC [7]
An example of a typical XML-RPC response would be:

<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><string>South Dakota</string></value>
</param>
</params>
</methodResponse>
Reference
1. Abraham Silberschatz, Peter B. Galvin, Greg Gagne, “Operation System
Concepts (6th)”, John Wiley & Sons, Inc.
2. Randy chow, Theodore Johnson, “Distributed operating system and
algorithms”
3. http://www.cs.cf.ac.uk/Dave/C/node33.html
4. Douglas C. Schmidt, “Overview of Remote Procedure Calls (RPC)”,
Washington University, St. Louis,
www.cs.wustl.edu/~schmidt/PDF/rpc4.pdf
5. http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx
6. http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?
topic=/com.ibm.db2.udb.doc/ad/c0010962.htm
7. http://en.wikipedia.org/wiki/XML-RPC
8. http://www.xmlrpc.com/
9. http://tldp.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-intro.html
Thank
You