This document provides an overview of remote procedure calls (RPC) including: - RPC uses the client/server model where a client makes a request to a server program located on another computer. The client is suspended until the server returns results. - RPC implementations generate client and server stub code that marshall/unmarshall arguments and results to handle remote communication transparently. - Key aspects of RPC include the client/server binding, lack of shared memory between systems, and ability to handle independent failures on remote systems. - The document discusses RPC communication models and implementations including lightweight RPC to improve performance of communication between protection domains on the same machine. It provides a case study on the Distributed Computing Environment (DCE)

1. DOS[ Distributed Operating System ]
(Remote Processing Call)
RPC
Prepared By : Avishek Sarkar
Enrollment No : 130650107020
Roll No : 21

2. CONTENTS
 Introduction of RPC.
 RPC Model.
 Points of RPC.
=> Server/Client Relationship(Binding)
=> No assumption of Shared Memory.
=> Independent Failure.
=> Security.
 Difference of Client & Server of RPC.
 Transparency of RPC.
 Implementation of RPC (Mechanism of RPC).
 Client & Server in RPC.
 Communication of RPC.
=> Persistence and Synchronicity in Communication (1).
=> Persistence and Synchronicity in Communication (2).
 Client and Server Binding.
 Lightweight Remote Processing Call (LRPC).
 CASE STUDY

3. INTRODUCTION OF RPC
Remote Procedure Call (RPC) is a protocol that one program can use to request a
service from a program located in another computer in a network without having
to understand network details. (A procedure call is also sometimes known as
a function call or a subroutine call.) RPC uses the client/server model. The
requesting program is a client and the service-providing program is the server.
Like a regular or local procedure call, an RPC is a synchronous operation
requiring the requesting program to be suspended until the results of the remote
procedure are returned. However, the use of lightweight processes or threads
that share the same address space allows multiple RPCs to be performed
concurrently.

4. INTRODUCTION OF RPC
Fundamental idea: –
1. Server process exports an interface of procedures or functions that can be called by
client programs.
2. similar to library API, class definitions, etc.
Clients make local procedure/function calls :-
1. As if directly linked with the server process
2. Under the covers, procedure/function call is converted into a message exchange with
remote server process

5. THE RPC MODEL

6. Points of RPC
1) Server/Client relationship (binding)
While a local procedure call depends on a static relationship between the calling and the
called procedure, the RPC paradigm requires a more dynamic behavior. As with a local
procedure call, the RPC establishes this relationship through binding between the calling
procedure (client) and the called procedure (server). However, in the RPC case a binding
usually depends on a communications link between the client and server RPC run-time
systems. A client establishes a binding over a specific protocol sequence to a specific host
system and endpoint.

7. 2) No assumption of shared memory
Unlike a local procedure call, which commonly uses the call-by-reference
passing mechanism for input/output parameters, RPCs with input/output
parameters have copy-in, copy-out semantics due to the differing address
spaces of calling and called procedures.
Points of RPC

8. 3) Independent failure
Beyond execution errors that arise from the procedure call itself, an RPC
introduces additional failure cases due to execution on physically separate
machines. Remoteness introduces issues such as remote system crash,
communications links, naming and binding issues, security problems, and
protocol incompatibilities.
Points of RPC

9. 4) Security
Executing procedure calls across physical machine boundaries has
additional security implications. Client and server must establish a
security context based on the underlying security protocols, and they
require additional attributes for authorizing access.
Points of RPC

10. Difference of Client & Server Of RPC
 Client-side stub
 Looks like local server function
 Same interface as local function
 Bundles arguments into a
message, sends to server-side
stub
 Waits for reply, un-bundles
results
 returns
 Server-side stub
 Looks like local client function to
server
 Listens on a socket for message
from client stub
 Un-bundles arguments to local
variables
 Makes a local function call to
server
 Bundles result into reply
message to client stub

11. Transparency of RPC
Sun remote ``procedure call'' is different from a local procedure call. Some systems, such as the Xerox
Cedar language, try to support transparent RPC which looks and behaves like an ordinary procedure call.
Such RPC differs from Sun RPC in two main ways:
Since a remote procedure call looks exactly like a local procedure call, it does not explicitly indicate the
location of the remote machine. The remote machine is determined by a special binding phase, which
occurs before the call is made.
Programmers do not explicitly Marshall parameters or unmarshall results. The marshalling and
unmarshalling (XDR) routines are generated from the declarations of procedures invoked remotely. For
this reason, systems that support such RPC are sometimes also called RPC generators.

12. Implementation of RPC (Mechanism of RPC)
RPC Architecture

13. Implementation of RPC (Mechanism of RPC)
 How does the client know the procedure (names) it can call and which
parameters it should provide from the server?
 Server interface definition
– RPC interface specifies those characteristics of the procedures provided by
a server that are visible to the clients.
– The characteristics includes: names of the procedures and type of
parameters.
– Each parameter is defined as input or output.

14. Implementation of RPC (Mechanism of RPC)
 How does the server react the request of the client? From
which port? How to select the procedure? How to interpret the
arguments?
 Dispatching, Unmarshalling, communication with client:
– A despatcher is provided. It receives the call request message from
the client and uses the procedure identifier in the message to select
one of the server stub procedures and passes on the arguments.

15. Implementation of RPC (Mechanism of RPC)
 How does the client receive the reply?
 The stub procedure of the client marshals the result arguments
and returns (local call return). Note that the original remote
procedure call was transformed into a (local) call to the stub
procedure.

16. Client and Server in RPC
client
stub
proc.
Communication
module
Local
return
Local
call
Client computer Server computer
server
stub
proc.
client
service
procedure
Receive
reply
Send
request
Unmarshal
results
Marshal
arguments
Receive
request
Send
reply
Select procedure
Unmarshal
arguments
Marshal
results
Execute procedure

17. Communication Of RPC
Persistence and Synchronicity in Communication (1)

18. Communication Of RPC
B ) Persistent Synchronous Communication
Persistence and Synchronicity in Communication (2)
A ) Persistent Asynchronous Communication

19. The Client/Server Binding is a simple, light-weight, Remote Procedure Call (RPC) mechanism, for use with 30 clients or
less, that enables you to implement a client/server architecture without having to worry about communications
programming.
The Client/Server Binding is included as part of Server Express for use in applications which do not require an extensive,
fault-tolerant middleware solution.
You should ensure that the capabilities and performance provided by the Client/Server Binding are adequate for your
business needs. For many applications, this is the case and the Client/Server Binding offers a solution which is both easy
to implement and extremely cost-effective to deploy.
The Client/Server Binding removes the requirement for you to include communications code in your application by
providing two modules called client and server. These are generic modules which can be used to drive any application.
Client & Server Binding

20. Lightweight Remote Procedure Call (LRPC) is a communication facility designed and optimized for
communication between protection domains on the same machine. In contemporary small-kernel
operating systems, existing RPC systems incur an unnecessarily high cost when used for the type of
communication that predominates between protection domains on the same machine. This cost leads
system designers to coalesce weakly related subsystems into the same protection domain, trading
safety for performance. By reducing the overhead of same-machine communication, LRPC encourages
both safety and performance. LRPC combines the control transfer and communication model of
capability systems with the programming semantics and large-grained protection model of RPC. LRPC
achieves a factor-of-three performance improvement over more traditional approaches based on
independent threads exchanging messages, reducing the cost of same-machine communication to
nearly the lower bound imposed by conventional hardware. LRPC has been integrated into the Taos
operating system of the DEC SRC Firefly multiprocessor workstation.
Lightweight Remote Processing Call (RPC)

21. CASE STUDY
Distributed Computing System(DCE) & Remote Processing Call(RPC)
DCE/RPC, short for "Distributed Computing Environment / Remote
Procedure Calls", is the remote procedure call system developed for
the Distributed Computing Environment(DCE). This system allows
programmers to write distributed software as if it were all working on
the same computer, without having to worry about the underlying
network code.

22. ThankYou