Yiwei Wu

Request/Reply Communication

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.html4. 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-RPC8. http://www.xmlrpc.com/9. http://tldp.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-

intro.html

Thank You