DSs Lecture Note

Chapter Four
Communication

4.1. Introduction
Objective of this chapter is to investigate communication paradigms of distributed systems that is how
distributed entities like objects or services are interact to each other at a higher level of abstraction. In
primarily, we’ll examine the remote invocation paradigms such as Request Reply Protocols (RRP),
Remote Procedure Calls (RPC) and Remote-Method Invocations (RMI).
Request-Reply Protocols (RRP)
Represent a pattern on top of message passing and support the two-way exchange of messages as
encountered in client-server computing. In particular, such protocols provide relatively low-level support
for requesting the execution of a remote operation, and also provide direct support for RPC and RMI.
Remote-Procedure Calls (RPC)
The earliest and perhaps the best-known example of a programmer-friendly model, was the extension of
the conventional procedure call model to distributed systems. This model allows client programs to call
procedures of server program transparently, in which the server programs are running in separate
processes and might be reside in a different computer.
Remote-Method Invocations (RMI)
An object-based programming model that allow objects in different processes to communicate with one
another by means of remote method invocation. RMI is an extension of local method invocation that
allows an object living in one process to invoke the methods of an object living in another process.
Figure 4.1 shows the above three means of interactions (RRP, RPC and RMI) are an integral parts of the
middleware layer protocols. So that distributed applications based on these protocols have to be
implemented on top of a network protocol, as several layers.

Figure 4.1: Communication Models Implemented as Several Layers

BireZman (bireuog@gmail.com) UOG, Computer Science Department 1

 DSs Lecture Note

4.2. Request-Reply Protocol Communication, in a Client/Server Model

Client/Server model is a system structured into two groups of processes (objects), that is the clients and
the servers that deliver services to clients. Figure 4.2 is an example of request-reply protocol between
client and server processes, in which they include some sequential operations.

Figure 4.2: Request-Reply Protocol in Client/Server Model

public byte[] doOperation (RemoteRef s, int operationId, byte[]

arguments);

This doOperation() is a client side method that sends request message to the
remote server and waits for reply message (result).
It has also arguments to be passed which specify the remote server, the operation to be
invoked and the parameters/values for that operation.
public byte[] getRequest ();

This getRequest()method is part of the server process which is used to acquire

client’s request via the server port.
public void sendReply (byte[] reply, InetAddress clientHost, int
clientPort);

This sendReply()is a server side method that sends the processed result as reply
message to the client processes at its Internet address and port.
Generally, the Client sends request to server_reference and receive reply. Then Server receives
the request from client-reference, executes the requested operation and sends the reply to
client_reference.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 2

 DSs Lecture Note

4.2.1. TCP and UDP Layers

Figure 4.3 depicts Request-Reply protocols which is implemented based on the network protocol, for
example the Internet TCP (Transport Control Protocol) or UDP (User Datagram Protocol).

Figure 4.3: TCP and UDP Layers

Both TCP and UDP are transport protocols, they are implemented on top of the IP (Internet Protocol).
TCP is a reliable protocol which implements additional mechanisms on top of IP to meet
reliability guarantees.
UDP is a protocol that does not guarantee reliable transmission; it offers no guarantee of
delivery.
4.2.2. The Hyper-Text Transfer Protocol (HTTP)
Hyper-Text Transfer Protocol (HTTP) is an example of a Request-Reply protocol, it’s used by web
browser clients to make requests to web servers and then receive replies.
HTTP is implemented over TCP and in the original version of the protocol each client/server interaction
consists of the following steps: -
Step 1: First the client makes a request then the server accepts a connection at default server
port or at a port specified in the URL.
Step 2: The client sends a message to the server.
Step 3: The server sends a reply message to the client.
Step 4: The connection is closed.
4.3. Remote Procedure Call (RPC)
A remote procedure call (RPC) is an interprocess communication that allows a computer program to
cause a subroutine or procedure to execute in another address space, commonly on another computer
on a shared network, without the programmer explicitly coding the details for this remote interaction.
RPC is initiated by the client, which sends a request message to a known remote server to execute a
specified procedure with supplied parameters. The remote server sends a response to the client, and
the application continues its process. While the server is processing the call, the client is blocked (it
waits until the server has finished processing before resuming execution), unless the client sends an
asynchronous request to the server.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 3

 DSs Lecture Note

An important difference between RPCs and local calls is that remote calls can fail because of
unpredictable network problems, also callers generally must deal with such failures without knowing
whether the remote procedure was actually invoked. Idempotent procedures (those that have no
additional effects if called more than once) are easily handled, but enough difficulties remain that code
to call remote procedures is often confined to carefully written low-level subsystems.
The concept of RPC represents a major intellectual breakthrough in distributed computing, with the goal
of making the programming of distributed systems look similar, if not identical, to conventional
programming, that is to achieve a high level of distribution transparency.
4.3.1. RPC and Distribution Transparency
The originators of RPC aimed to make remote procedure calls as much like local procedure calls as
possible, with no distinction in syntax between a local and a remote procedure call. All the necessary
calls to marshalling and message-passing procedures were hidden from the programmer making the call.
Although request messages are retransmitted after a timeout, this is transparent to the caller to make
the semantics of remote procedure calls like that of local procedure calls.
More precisely RPC strives to offer at least location and access transparency, hiding the physical location
of the (potentially) remote procedure and also accessing local and remote procedures in the same way.
Therefore; the goal of RPC is make distributed computing look like centralized computing for the
programmer. This mean that RPC is transparent and the calling object (procedure) is not aware that the
called one is executing on a different machine, and vice versa.
4.3.2. Sequential Events of RPC Implementation
1. The client calls the client stub. The call is a local procedure call with parameters pushed on to
the stack in the normal way.
2. The client stub packs the parameters into a message and makes a system call to send the
message. The process of packing the parameters is called marshalling.
3. The client's local operating system sends the message from the client machine to the server
machine.
4. The local server’s local operating system passes the incoming packets to the server stub.
5. The server stub unpacks the parameters from the message. The process of unpacking
parameters from incoming messages is called unmarshalling.
6. Then, the server stub calls the server procedure.
7. Thereafter, the reply traces the same steps in the reverse direction.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 4

 DSs Lecture Note

Figure 4.5: RPC Implementation

Figure 4.5 is illustrated as follows: -
 The client that accesses a service includes one stub procedure for each procedure in the
service interface. The stub procedure behaves like a local procedure to the client, but instead
of executing the call it marshals the procedure identifier and the arguments into a request
message then it sends via its communication module to the server. When the reply message
arrives, the client stub also unmarshals results.

 The server process contains a dispatcher together with one server stub procedure and one
service procedure for each procedure in the service interface. The dispatcher selects one of
the server stub procedures according to the procedure identifier in the request message. The
server stub procedure then unmarshals the arguments in the request message, calls the
corresponding service procedure and marshals the returned values for the reply message.
The service procedures implement the procedures in the service interface.

 The client and server stub procedures and the dispatcher can be generated automatically by
an interface compiler from the interface definition of the service.
4.4. Remote Method Invocation (RMI)
RMI allows applications to call object methods located remotely, so they can share resources distributed
across the network and able processes to be loaded across systems. Unlike other systems like RPC, for
remote executions which requires only simple data types or defined structures be passed to and from
methods, the RMI allows any Java object type to be used, even if the client or server has never
encountered it before. RMI lets both client and server to dynamically load new object types as required.
The Java RMI is a mechanism that allows one to invoke a method on an object that exists in another
address space. The other address space could be on the same machine or a different one. This RMI
mechanism is basically an object-oriented RPC mechanism.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 5

 DSs Lecture Note

RMI is closely related to RPC but extended into the world of distributed objects, that is in RMI a calling
object can invoke a method in a potentially remote object. As with RPC, the underlying details are
generally hidden from the user.
In general, the following differences lead to added expressiveness when it comes to the programming
of complex distributed applications and services.
The programmer is able to use the full expressive power of object-oriented programming in
the development of distributed systems software including the use of objects, classes and
inheritance. It can also employ other related object- oriented design methodologies and
associated tools.
Building on the concept of object identity in object-oriented systems, all objects in an RMI based
system have unique object references (whether they are local or remote). Such object references
can also be passed as parameters and offering significantly richer parameter-passing semantics
than in RPC.
The issue of parameter passing is particularly important in distributed systems. RMI allows the
programmer to pass parameters not only by value, as I/O parameters, but also by object
reference. Passing references is particularly attractive if the underlying parameter is large or
complex. The remote end, on receiving an object reference, can then access this object using
remote method invocation, instead of having to transmit the object value across the network.

Figure 4.6: RMI Implementations

BireZman (bireuog@gmail.com) UOG, Computer Science Department 6

 DSs Lecture Note

4.4.1. RMI Components

Figure 4.6 is used to illustrate the RMI implementation, but who are the major players in this process?
i) Objects: - They are in the first hand, for example Object-A asks for a service and Object-B
delivers the service.
ii) Proxy for Object-B: - If an Object-A holds a remote reference to a (remote) Object-B, there
exists a proxy object for B on the machine which hosts A. The proxy is created when the remote
object reference is used for the first time. For each method in B there exists a corresponding
method in the proxy.
The proxy is the local representative of the remote object, the remote invocation
from A to B is initially handled like a local one from A to the proxy for B.
At invocation, the corresponding proxy method marshals the arguments and builds
the message to be sent, as a request, to the server.
After reception of the reply, the proxy unmarshals the received message and sends
the results, in an answer, to the invoker.
iii) Skeleton for Object-B: - On the server side there exists a skeleton object corresponding to a
class if an object of that class can be accessed by RMI. so that for each method in B there exists
a corresponding method in the skeleton.
The skeleton receives the request message, unmarshals it and invokes the
corresponding method in the remote object, then it waits for the result. After
receiving the result skeleton marshals it into the message to be sent as a reply.
A part of the skeleton is also called dispatcher. The dispatcher receives a request
from the communication module, identifies the invoked method and directs the
request to the corresponding method of the skeleton.
iv) Communication Module: - Its and integral part of the client and server, which is responsible to
carry out the message exchanges by implementing the request/reply protocol needed to
execute the remote invocation.
The particular messages exchanged and the way errors are handled, depends on the
RMI semantics which is implemented.
v) Remote Reference Module: - This one performs translations between local and remote object
references. The correspondence between them is recorded in a remote object table.
Remote object references are initially obtained by a client from a so called binder
that is part of the global name service (not part of the remote reference module).
Here servers register their remote objects and clients look up after services.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 7

 DSs Lecture Note

Therefore; given the specification of the server interface and the standard representations, an
interface compiler can generate the classes for proxies and skeletons
Object-A and Object-B belong to the application.
Remote reference module and communication module belong to the middleware.
The proxy for B and the skeleton for B represent the so called RMI software. They are situated
at the border between middleware and application and usually can be generated automatically
with help of available tools that are delivered together with the middleware software.
4.4.2. RMI Communication Steps
As stated above, the RMI implementation performs series of communications (between the client and
server objects) and they are summarized as follows: -
1. The calling sequence in the client object activates the method in the proxy corresponding to the
invoked method in B.
2. The method in the proxy packs the arguments into a message (marshalling) and forwards it to
the communication module.
3. Based on the remote reference obtained from the remote reference module, the
communication module initiates the request/reply protocol over the network.
4. The communication module on the server’s machine receives the request. Based on the local
reference received from the remote reference module the corresponding method in the
skeleton for B is activated.
5. The skeleton method extracts the arguments from the received message (unmarshalling) and
activates the corresponding method in the server object B.
6. After receiving the results from B, the method in the skeleton packs them into the message to
be sent back (marshalling) and forwards this message to the communication module.
7. The communication module sends the reply, through the network, to the client’s machine.
8. The communication module receives the reply and forwards it to the corresponding method in
the proxy.
9. The proxy method extracts the results from the received message (unmarshalling) and
forwards.

BireZman (bireuog@gmail.com) UOG, Computer Science Department 8