1

Remote Procedure Call

2

RPC: Remote Procedure Call

• “To allow programs to call procedures located on other machines.”

• Effectively removing the need for the DS programmer to worry about all the details of network programming (i.e., no more sockets).

3

How RPC Works: Part 1

• As far as the programmer is concerned, a “remote” procedure call looks and works identically to a “local” procedure call.

• In this way, transparency is achieved.

• Before looking a RPC in action, let’s consider a conventional “local” procedure call (LPC).

4

Local Procedures

Application

Main Body

Procedure

Procedure

5

Remote Procedures

Main Body

Procedure

Procedure

Application

Client ServerNetwork

6

Conventional Local Procedure Call

a) Parameter passing in a local procedure call: the stack before the call to read.

b) The stack while the called procedure is active.

7

How RPC Works: Part 2

• The procedure is “split” into two parts:1. The CLIENT “stub” – implements the

interface on the local machine through which the remote functionality can be invoked.

2. The SERVER “stub” – implements the actual functionality, i.e., does the real work!

• Parameters are “marshaled” by the client prior to transmission to the server.

8

Client and Server Stubs

Principle of RPC between a client and server program.

9

The 10 Steps of a RPC

1. Client procedure calls client stub in normal way

2. Client stub builds message, calls local OS

3. Client's OS sends message to remote OS

4. Remote OS gives message to server stub

5. Server stub unpacks parameters, calls server

6. Server does work, returns result to the stub

7. Server stub packs it in message, calls local OS

8. Server's OS sends message to client's OS

9. Client's OS gives message to client stub

10. Stub unpacks result, returns to client

10

Passing Value Parameters (1)

Steps involved in doing remote computation through RPC.

11

Interface Definition Language (IDL)

• RPCs typically require development of custom protocol interfaces to be effective.

• Protocol interfaces are described by means of an Interface Definition Language (IDL).

• IDLs are “language-neutral” – they do not presuppose the use of any one programming language.

• That said, most IDLs look a lot like C …

12

Interface Definition• /* arith.idl */

• [

• uuid(C9B5A380-295B-61C0-A51B-38502A0ECDF9)

• ]

• interface arith

• {– const float pi = 3.14

– void sum_num([in] int a, [in] int b, [out] int *c);

}

• idl arith.idl : arith.h, arith_cstub.o, arith_sstub.o

13

Interface Definition (Cont.)• client.c

– #include “arith.h”– Main()– {– ……– }

• server.c– #include “arith.h”– Main()– {– ……– }

• gcc –o server server.c arith_sstub.o –ldce• gcc –o client client.c arith_cstub.o –ldce

14

Writing a Client and a Server

The steps in writing a client and a server in RPC.

2-14

15

Failure Situations• Locating the Server

– Hard coded into client’s code– Client broadcasts– Dynamic Binding

• Server registers itself to along with the services it offers with a registry server

• Clients can query it and find out…• Server crashes• Client crashes

– Orphan– Log entry – extermination– Broadcasting id – reincarnation– Server kills all orphans – expiration

16

RPC Problems• Global Variables (not visible to servers)• Pointers (integer / linked list)• Inherently Synchronous (ARPC)• RPC works really well if all the machines are homogeneous.• Complications arise when two machines use different character

sets, e.g., EBCDIC or ASCII.• Byte-ordering is also a problem:

– Intel machines are “big-endian”.– Sun Sparc’s are “little-endian”.

• Extra mechanisms are required to be built into the RPC mechanism to provide for these types of situations – this adds complexity.

17

Passing Value Parameters (2)

a) Original message on the Pentium.b) The message after receipt on the SPARC.c) The message after being inverted. The little numbers in boxes indicate the address of each byte.

18

RMI: Remote Method Invocation

• “Remote objects” can be thought of as an expansion of the RPC mechanism (to support OO systems).

• An important aspect of objects is the definition of a well-defined interface to “hidden” functionality.

• Method calls support state changes within the object through the defined interface.

• An object may offer multiple interfaces.• An interface may be implemented by multiple objects.• Within a DS, the object interface resides on one

machine, and the object implementation resides on another.

19

The Distributed Object

• Organization of a remote object with client-side “proxy”.

• The “proxy” can be thought of as the “client stub”.

• The “skeleton” can be thought of as the “server stub”.

2-16

20

Example: Java RMI• In Java, distributed objects are integrated into the

language proper.• This affords a very high degree of distribution

transparency (with exceptions, where it makes sense, perhaps to improve efficiency).

• Java does not support RPC, only distributed objects.• The distributed object’s state is stored on the server,

with interfaces made available to remote clients (via distributed object proxies).

• To build the DS application, the programmer simply implements the client proxy as a class, and the server skeleton as another class.

21

DCE: An Example RPC

• The Open Group’s standard RPC mechanism.

• In addition to RPC, DCE provides:– Distributed File Service.– Directory Service (name lookups).– Security Service.– Distributed Time Service.

22

DCE: “Binding” a Client to a Server

Client-to-server binding in DCE.A “directory service” provides a way for the client to look-up

server.

2-15