S.
NO RPC RMI
1. RPC is a library and OS dependent platform. Whereas RMI is a java platform.
RMI supports object-oriented
2. RPC supports procedural programming.
programming.
3. RPC is less efficient in comparison of RMI. While RMI is more efficient than RPC.
4. RPC creates more overhead. While it creates less overhead than RPC.
The parameters which are passed in RPC While in RMI, objects are passed as
5.
are ordinary or normal data. parameter.
6. RPC is the older version of RMI. While it is the successor version of RPC.
There is high Provision of ease of While there is low Provision of ease of
7.
programming in RPC. programming in RMI.
8. RPC does not provide any security. While it provides client level security.
While it’s development cost is fair or
9. It’s development cost is huge.
reasonable.
There is a huge problem of versioning in While there is possible versioning using
10.
RPC. RDMI.
multiple codes are needed for simple multiple codes are not needed for simple
11.
application in RPC. application in RMI.
Can be complex due to low-level
12. Generally simpler to use and implement
implementation
Feature DOS NOS Middleware
User View Single system Multiple systems Multiple systems (simplified)
Platform Independence Medium Low High
Heterogeneity Medium Low High
1) What is Remote procedure call? Explain how transparency is achieved in RPC
RPC
Remote Procedure Call (RPC) is a powerful technique for constructing distributed, client-
server based applications.
It is based on extending the conventional local procedure calling so that the called procedure
does not exist in the same address space as the calling procedure.
The two processes may be on the same system, or they may be on different systems with a
network connecting them.
Remote Procedure Call (RPC) is a type of technology used in computing to enable a program
to request a service from software located on another computer in a network without needing
to understand the network’s details.
RPC abstracts the complexities of the network by allowing the developer to think in terms of
function calls rather than network details, facilitating the process of making a piece of
software distributed across different systems.
RPC works by allowing one program (a client) to directly call procedures (functions) on
another machine (the server).
The client makes a procedure call that appears to be local but is run on a remote machine.
When an RPC is made, the calling arguments are packaged and transmitted across the
network to the server.
The server unpacks the arguments, performs the desired procedure, and sends the results back
to the client.
Working of a RPC
1. A client invokes a client stub procedure, passing parameters in the usual way. The client
stub resides within the client’s own address space.
2. The client stub marshalls(pack) the parameters into a message. Marshalling includes
converting the representation of the parameters into a standard format, and copying each
parameter into the message.
3. The client stub passes the message to the transport layer, which sends it to the remote
server machine. On the server, the transport layer passes the message to a server stub,
which demarshalls(unpack) the parameters and calls the desired server routine using the
regular procedure call mechanism.
4. When the server procedure completes, it returns to the server stub (e.g., via a normal
procedure call return), which marshalls the return values into a message.
5. The server stub then hands the message to the transport layer. The transport layer sends the
result message back to the client transport layer, which hands the message back to the client
stub.
6. The client stub demarshalls the return parameters and execution returns to the caller.
Tranperency:
The most difficult aspect of designing an RPC facility is ensuring that it is transparent.
There are two kinds of transparencies that must be used:
Syntactic transparency: The syntax of a remote process and a call to a local procedure
should be the same.
Semantic transparency: A remote procedure call and a local procedure call have the
same semantics.
Syntactic transparency is not a problem, but semantic transparency is difficult to
achieve due to variations between remote and local procedure calls. Following are the
variations between Remote Procedure Calls and Local Procedure Calls:
i. Remote Procedure Calls have disjoint address space i.e. different address space,
unlike Local Procedure Calls.
ii. Remote Procedure Calls are more prone to failures due to possible processor failure or
communication issues of a network than Local Procedure Calls.
iii. Because of the communication network, remote procedure calls take longer than local
procedure calls.
How Transparency can be achieved in RPC:
RPC’s main goal is to make a remote procedure call appear transparent. The calling
process should have no idea that the called procedure is running on a different
computer. In a similar way, RPC achieves transparency.
When the read is used as a remote procedure, a client stub version of the reading is
added to the library. The calling sequence is used to call it.
The parameters are encapsulated in a message, which is then transmitted to the server.
The server’s operating system forwards the message to the server stub, which calls
receive and rejects incoming messages when it arrives at the server.
The server unpacks parameters and calls the server procedure, completes its task, and
delivers the result to the caller in the usual manner of packing and sending the result
to the client stub.
When the client gets a message from the server, the client’s operating system
recognizes it as being addressed to the client process. When the caller has control after
the call to read all it knows is that its data is available.
It is completely unaware that the task was performed remotely rather than on the local
operating system. Transparency is gained in this manner.
The Syntax Transparency can be achieved of RPC but total Semantic Transparency is
impossible to achieve because of the variations in the procedure calls (local and
remote).
2) Issues in designing distributed system
