Assignment 03

Issues in RPC

CO4353 – Distributed Systems

Name : Prabodhana LTRJ

RPC (Remote Procedure Call) is a strong technology for building client-server systems that are distributed.
It works by extending standard local procedure calling so that the called procedure does not have to be in
the same address space as the calling procedure. The two operations could be on the same system, or they
could be on distinct systems connected via a network.

Below, I have discussed some Issues in RPC and how they can be resolved.

 Differences in data representation on the client and server machines. As a example, for representation
of 32-bit integers, some systems (known as big-endian) use the high memory address to store the most
significant byte while other systems (known as little-endian) store the least significant bit in high
memory address. Although both systems have 32-bit integer patterns, the way they represent is
different. Therefore, the way that data is represented is different. In case of RPC, we deal with system
located in different places which is connected via networks. These systems may have different kind of
data representation. If a system send data to an another system which represent data in different way,
there will be an error. In order to resolve this issue, RPC systems define a machine-independent
representation of data. That means, the data generated by a system, it is converted into machine
independent representation. That means is the data is converted in such way that the data does not
depend of the machine anymore but it can be used in any kind of machine. One such representation is
known as external data representation (XDR). On client side, parameter marshalling involves
converting the machine dependent data into XDR before they are sent to the server. On server side, the
XDR data are unmarshalled and converted to the machine dependent representation for the server.
 RPCs can fail, or be duplicated and executed more than once, as a result of common network errors.
Since RPCs works system connected via networks, network error are highly affected to systems. To
solve these type of issues, the operating system must ensure that messages are acted on exactly once,
rather than at most once. Most local procedure calls have the exactly once functionality, but it is more
difficult to implement. For example, when client is making procedure call to the server, server will
receive the call, in normal circumstances if we assume that no errors occurred, then server gets the call
and execute the call. But from the client side it keeps sending the message again and again. So server
checks that whether this message is already address. If it finds that the message is already executed,
then the message is ignored. But this method is not efficient. And also there can be a chance where
these message will never be executed if it uses at most once functionality. In order to overcome this
issue, we used system of acknowledgements. That means we have to follow the system of
acknowledgements where the client sends request to the server and the server has to process the request
and after it has process it, server must send acknowledgement back to the client saying that the request
has been fulfilled. So once the client received to acknowledgement, client understand that request is
executed and it does not send same request again. But if the client does not get the acknowledgement
it keeps sending request again and again to the server until it gets the acknowledgement. This is much
 better and efficient way to tackle this problem. Therefore, even though RPCs can fail due to network
error, by following this method we make sure that the request has been executed exactly once.
 With standard procedure calls, some form of binding takes place during link, load, or execution time
so that a procedure call’s name is replaces by the memory address of the procedure call. The RPC
systems require similar binding which client and server have complete information about each other.
(client need to know every port in server and their functionalities and sever need to know every port in
the client and their functionalities also). But neither system shares this information with each other
since they do not share memory. To address this problem there are two solutions. The first way is the
binding information may be predetermined, in the form of fixed port addresses. This means address of
the port is fixed. Therefore, they will not be changed. At compile time, an RPC call has a fixed port
number associated with it. Once a program is complied, the server cannot change the port number of
the requested service. But this method is not very flexible since port numbers has to be fixed. Although
we needed to change the port number, we cannot do it. To overcome this limitation, we could use
another method. In this method, binding can be done dynamically by a rendezvous mechanism.
Typically, an operating system provides a rendezvous daemon on a fixed RPC port. A client then sends
a message containing the name of the RPC to the rendezvous daemon requesting the port address of
the RPC it needs to execute. The port number is returned, and the RPC calls can be sent to that port
until the process terminates.
 RPC runtime: The RPC run-time system is a library of routines and a set of services that handle the
RPC mechanism's network communications. Client-side and server-side run-time systems code
handles binding, establishes communications over the proper protocol, passes call data between the
client and server, and handles communications problems during an RPC call.
 Use of stub: The stub's purpose is to give the programmer-written application code some transparency.
On the client side, the stub acts as a conduit between the client's local procedure call and the run-time
system, marshaling and unmarshaling data, initiating the RPC run-time protocol, and performing some
of the binding stages if requested. On the server side, the stub serves as a comparable interface between
the run-time system and the server's local manager processes.