DISTRIBUTED

OPERATING SYSTEMS

MCS-041
Block-3
Unit-2(b)
 Introduction

• Remote Procedure Call (RPC) is a high-level model for client-sever

communication.

• It provides the programmers with a familiar mechanism for building

distributed systems.

• Examples: File service, Authentication service.

 Introduction

 Why we need Remote Procedure Call (RPC)?

– The client needs a easy way to call the procedures of the server to get

some services.

– RPC enables clients to communicate with servers by calling procedures

in a similar way to the conventional use of procedure calls in high-level

languages.

– RPC is modeled on the local procedure call, but the called procedure is

executed in a different process and usually a different computer.

 Introduction
• How to operate RPC?

– When a process on machine A calls a procedure on machine B, the

calling process on A is suspended, and the execution of the called
procedure takes place on B.

– Information can be transported from the caller to the callee in the

parameters and can come back in the procedure result.

– No message passing or I/O at all is visible to the programmer.

 Introduction
• The RPC model

client server
Call procedure request
and wait for reply Receive request and
start process execution

Send reply and wait for

reply
next execution
Resume
execution
Blocking state Executing state
 Characteristics
• The called procedure is in another process which may reside in another
machine.

• The processes do not share address space.

– Passing of parameters by reference and passing pointer values are not

allowed.

– Parameters are passed by values.

• The called remote procedure executes within the environment of the server
process.

– The called procedure does not have access to the calling procedure's
environment.
 Features

• Simple call syntax

• Familiar semantics

• Well defined interface

• Ease of use

• Efficient

• Can communicate between processes on the same machine or different

machines
 Limitations

• Parameters passed by values only and pointer values are not allowed.

• Speed: remote procedure calling (and return) time (i.e., overheads) can be

significantly (1 - 3 orders of magnitude) slower than that for local procedure.

– This may affect real-time design and the programmer should be aware of

its impact.
 Limitations

• Failure: RPC is more vulnerable to failure (since it involves communication

system, another machine and another process).

– The programmer should be aware of the call semantics, i.e. programs

that make use of RPC must have the capability of handling errors that

cannot occur in local procedure calls.

 Design Issues
• Exception handling

– Necessary because of possibility of network and nodes failures;

– RPC uses return value to indicate errors;

• Transparency

– Syntactic  achievable, exactly the same syntax as a local procedure

call;

– Semantic  impossible because of RPC limitation: failure (similar but not

exactly the same);
 Design Issues
• Delivery guarantees

– Retry request message: whether to retransmit the request message until

either a reply or the server is assumed to have failed;

– Duplicate filtering : when retransmission are used, whether to filter out

duplicates at the server;

– Retransmission of replies: whether to keep a history of reply messages

to enable lost replies to be retransmitted without re-executing the server
operations.
 RPC Mechanism
Client computer Server computer
service
procedure
Local Local Execute procedure
client
return call
server
Unmarshal Marshal
stub results
client arguments
Unmarshal Marshal proc.
stub
results arguments
proc. Select procedure

Receive Send Communication Receive Send

reply request module request reply
 RPC Mechanism (Summary)

1. The client provides the arguments and calls the client stub in the normal
way.

2. The client stub builds (marshals) a message (call request) and traps to OS
& network kernel.

3. The kernel sends the message to the remote kernel.

4. The remote kernel receives the message and gives it to the server
dispatcher.

5. The dispatcher selects the appropriate server stub.

6. The server stub unpacks (unmarshals) the parameters and call the
corresponding server procedure.
 RPC Mechanism (Summary)
7. The server procedure does the work and returns the result to the server

stub.

8. The server stub packs (marshals) it in a message (call return) and traps it to

OS & network kernel.

9. The remote (receiver) kernel sends the message to the client kernel.

10. The client kernel gives the message to the client stub.

11. The client stub unpacks (unmarshals) the result and returns to client.
 RPC Implementation
• Three main tasks:

– Interface processing: integrate the RPC mechanism with client and

server programs in conventional programming languages.

– Communication handling: transmitting and receiving request and reply

messages.

– Binding: locating an appropriate server for a particular service.

 RPC Implementation
• Interface Processing

– Marshalling and unmarshalling of arguments;

– Dispatching of request messages to the appropriate procedure in the

server;

– Interface compiler processes interface definitions written in an interface

definition language (msg.x);

– Generate a client stub procedure (msg_clnt.c);

– Generate a server stub procedure (msg_svc.c);

 RPC Implementation

– Use the signatures of the procedures in the interface to generate

marshalling and unmarshalling operations (msg_xdr.c);

– Generate procedure headings for each procedure in the service from the
interface definition (msg.h);

• Communication handling

– TCP, UDP communication

– Socket programming
 RPC Implementation
• Binding

– It specifies a mapping from a name to a particular object usually

identified by a communication ID.

– Binding is important because

• An interface definition specifies a textual service name for use by

clients and servers.

• Clients that request message must be addressed to a server port.

 RPC Implementation

– Binder: a separate service that maintains a table containing mappings

from service names to server ports.

– All other services depend on the binder service.

– Binder interface used by server

• Register (String serviceName, Port serverPort, int version)
• Withdraw (String serviceName, Port serverPort, int version)

– Binder interface used by client

• PortLookUp (String serviceName, int version)
 Other middleware Technologies

Other middleware technologies that allow the distribution of processing across

multiple processors and platforms are:

 Object Request Broker(ORB)

 Distributed Computing Environment (DCE)

 Message-Oriented Middleware (MOM)

 COM/DCOM

 Transaction Processing Monitor Technology

 3-Tier S/W Architecture.