ASSIGNMENT 2

Distributed Systems
CO4353

NAME : G.R.L CHANDRASEKERA

INDEX NO : 16 / ENG / 019

REGISTRATION NO : EN 82648
RPC (Remote Procedure Call) is a powerful technology for creating distributed client-server
systems. By extending standard local procedure calling, it makes it possible for the called
procedure to be located outside of the calling procedure's address space. The two operations
might take place on the same system or on different systems connected by a network.

Common network errors can cause RPCs to be duplicated and executed more than once, fail,
or both. Network errors have a significant impact on systems because RPCs operate on systems
that are connected via networks. The operating system must make sure that messages are
responded to exactly once rather than just once in order to address problems of this nature. The
exact once functionality is present in the majority of local procedure calls, but it is more
challenging to implement. For instance, when a client calls a server to execute a procedure, the
server will typically answer the call and execute the request as long as no errors are present.
However, the client side keeps sending the message repeatedly. Thus, the server determines
whether this message has already been addressed. If it discovers that the message has already
been executed, it is ignored. However, this approach is ineffective. Additionally, there's a
chance that these messages won't ever be sent if they only use one functionality. We used an
acknowledgements system to get around this problem. This means that we must adhere to the
acknowledgements system, in which the client submits a request to the server, which then
processes it before returning an acknowledgement to the client indicating that the request has
been satisfied. Therefore, once the client receives the acknowledgement, the client understands
that the request has been fulfilled and stops sending the same request. However, if the client
does not receive the acknowledgement, it keeps sending requests to the server repeatedly until
it does. This is a much more effective and superior approach to solving the issue. Therefore,
by using this method, even though RPCs can fail as a result of a network error, we ensure that
the request has been processed exactly once.

Differences between how data is displayed on client and server machines. As an illustration,
some systems store the most significant byte in high memory address when representing 32-bit
integers, whereas other systems store the least significant bit there. Both systems use 32-bit
integer patterns, but their representational strategies differ. As a result, the data is represented
differently. In the case of RPC, we deal with systems that are dispersed across the globe and
connected by networks. Different types of data representation may be used by these systems.
There will be a mistake if a system sends data to another system that represents the data
differently. RPC systems define a machine-independent representation of data to address this

1
problem. In other words, a system's data is transformed into a machine-independent
representation. This means that the data has been transformed so that it is usable with any type
of machine and is no longer dependent on any specific machine. External data representation
is one such representation (XDR). Prior to being sent to the server, the client-side process of
parameter marshalling involves converting machine-dependent data into XDR. The XDR data
are un-marshalled and changed to the machine dependent representation for the server on the
server side.
Use of Stub: The stub's goal is to add some transparency to the programmer-written application
code. The client-side stub serves as a link between the local procedure call made by the client
and the run-time system, marshaling and un-marshaling data, starting the RPC run-time
protocol, and, if necessary, carrying out some of the binding stages. The stub acts as a
comparable interface on the server side between the local manager processes and the run-time
system.
RPC run time: The library of routines and collection of services that manage the network
communications for the RPC mechanism make up the RPC run-time system. Run-time systems
code on both the client and the server handles binding, establishes communications using the
appropriate protocol, passes call data between the client and the server, and manages
communication issues during an RPC call.
Standard procedure calls involve some sort of binding that happens during link, load, or
execution time to replace the name of the procedure call with the address of the call's memory
location. Similar binding is needed in RPC systems so that the client and server are fully aware
of one another. However, because they do not share memory, neither system shares this data
with the other. There are two ways to solve this issue. The first method is to predetermine the
binding information in the form of fixed port addresses. This indicates that the port's address
is fixed. They won't be altered as a result. An RPC call has a fixed port number assigned to it
at compile time. The server cannot alter the port number of the requested service once a
program has been compile. However, because port numbers must be fixed, this method is not
very flexible. Although it was necessary, we are unable to change the port number. We could
employ a different approach to get around this restriction. This approach allows for dynamic
binding via a rendezvous mechanism. A rendezvous daemon is typically offered by an
operating system on a fixed RPC port. Then, a client sends a message to the rendezvous daemon
with the name of the RPC it needs to run, asking for the port number. RPC calls can be made
to that port up until the process is finished using the port number that is returned.