KING KHALID UNIVERSITY

Department of Computer
Science College of
Computer Science

Parallel and Distributed Computing– 482-CCS-3

Dr. Mohammad Nadeem Ahmed

Chapter 4: Communication: Layer protocols, middleware protocols,

types of communication, conventional procedure call, client and server
stubs, remote procedure calls (RPC), passing value parameters,
parameter specification and stub generation, asynchronous RPC, writing
and binding a client and a server, Berkeley sockets, the message-passing
interface message brokers, IBM’s WebSphere message-queuing system,
channels message transfer, data stream and streams and quality of
service (QoS).
 Communication
Interprocess communication is at the heart of all distributed systems. It makes no sense to
study distributed systems without carefully examining the ways that processes on different
machines can exchange information. Communication in distributed systems has traditionally
always been based on low-level message passing as offered by the underlying network. we start
by discussing the rules that communicating processes must adhere to, known as protocols, and
concentrate on structuring those protocols in the form of layers. We then look at three widely-
used models for communication: Remote Procedure Call (RPC), Message-Oriented Middleware
(MOM), and data streaming. We also discuss the general problem of sending data to multiple
receivers, called multicasting.

Layer protocols

The typical message appears on the network. Due to the absence of shared memory, all
communication in distributed systems is based on sending and receiving (low level) messages.
When
process P wants to communicate with process Q, it first builds a message in its own address
space. Then it executes a system call that causes the operating system to send the message
over the network to Q.

Figure 1: Layers, interfaces, and protocols in the OSI model

To make it easier to deal with the numerous levels and issues involved in communication, the
International Standards Organization (ISO) developed a reference model that clearly identifies
the various levels involved, gives them standard names, and points out which level should do
which job. This model is called the Open Systems Interconnection Reference Model [Day and
Zimmerman, 1983] usually abbreviated as ISO OSI or sometimes just the OSI model.
Client and Server Stubs

It should be emphasized that the protocols that were developed as part of the OSI model were
never widely used and are essentially dead. However, the underlying model itself has proved to
be quite useful for understanding computer networks

Figure 2:- A typical message as it appears on the network.

1)Application layer :- providing services to user, Essentially, everything else: e-mail protocols,
Web access protocols, file-transfer protocols, HyperText Transfer Protocol (HTTP) and so on.
Provide user interface to user, like all browser(chrome,safari,IE)
For transferring data provide different protocol- HTTP(for accessing webpage),FTP( for file
transfer to computer from different system),SMPT(if user wants to send email), all protocol is
used to securely transfer the data

2)Presentation layer Prescribes how data is represented in a way that is independent

of the hosts on which communicating applications are running. responsible for transalation,
compression and encryption.
a) Data Reformation (character encoding and conversions), sender and receiver
character encoding scheme can be different
 b) Data Encryption: - using encryption algorithm data is transferred in such format that
during the transmission if data is hacked than also it cannot be decrypted.

Data Compression: - to compress the data so that size can be reduced, so that in less time more
amount of data can be transferred.

3)Session layer Provides support for sessions between applications. Responsible for dialogue
control and synchronization
a) Create and manage session :- To establish session between two computer , here one system
request for session creation and another system after approving the details approved and session
is maintained, and maintain the session till user does not logout from the session.
Eg:- Cookies, URL rewriting etc
b) Add Check Points: - during data transmission adding check points so that is software crash or
error comes so that again all data will not be send again, rather than from the point where data
communication stopped.

c) Session termination: - once data transmission is completed session terminates.

4) Transport layer Mainly contains protocols for directly supporting applications,

such as those that establish reliable communication, or support real-time streaming of data.
Responsible of message from one process to another.
TCP (Transmission Control Protocol) is connection oriented
UDP (Universal Datagram Protocol)is connection less

In connection-oriented model first connection is established than communication starts.

In connection less, model connection is not established just sent a message.
Example: - suppose in a computer you are accessing YouTube and in the same time accessing
WhatsApp, how computer know which bits is of whatsapp or YouTube , Transport layer Identify
these bits with the help of Port Number, Total we have (65535 ports), and every application is
using a different ports number .
Transport layer using source and destination ports number and IP address confirms which data
belongs to which application.
a) Converts data to segments (also converts data to segments for fast data transmission)

b) Flow control (if mismatch in transmission rate it will control the speed, so that no data loss will
be there)
c) Error control (If any error it will control)

5) Network layer Contains the protocols for routing a message through a computer network,
as well as protocols for handling congestion. Here data delivers in the form of packets.
This layer which receives the data in form of segments now converts this to packets. Now this
packets after crossing different networks needs to reach to the destination, and between these
networks we have different paths , Network layer from these paths select the most quick(
shortest path) using router, router using IP address transfer the data to the destination address(
Once source assign the IP address to packets, the IP address will changes until packets received
by destination)

6) Data link layer Provides the means to detect and possibly correct transmission errors, as
well as protocols to keep a sender and receiver in the same pace. Data is transferred in the form
of frames.
This layer divides the packets received from network layer into the frames.
From one packet how, many frames will be there is decided based on the types of hardware is
used in transferring the data (Mostly we use NIC, Network Interface card, where we use to plugin
the internet cable),.

• MAC address to transfer data.

• Switch and hub is also a part of this layer
• Here we have system to system communication
• Sender send the acknowledgement message after receiving the message
• Here also data flow control is done so that data will not be lost, if any error than
retransmission is done.

7) Physical layer Deals with standardizing how two computers are connected
and how 0s and 1s are represented. Responsible for movements of individual bits (0 & 1) from
one node to next based on which communication (medium ) is used.

For Example: -
➢ If Medium is Wire, then physical layers transfer data through electrical signals will be
transferred.
➢ If medium is wireless, like WIFI than data will be transferred in the form of radio waves.
➢ In Fiber optics data will be transferred in the form of light Pulses.
 • Bits 1 or 0 will be represented in which signal so that receiver will also represent the same
is also decided here
• Life time of bits is also decided here.(in nano seconds), means in communication medium
after how much time the bits will be expired.
• Data rate , means how much data will be send every second is also decided here.
• Will check the direction of flow of data (either unidirectional or bidirectional)

Middleware Protocols
Middleware is an application that logically lives (mostly) in the OSI application layer, but which
contains many general-purpose protocols that warrant their own layers, independent of other,
more specific applications. Let us briefly look at some examples.
The Domain Name System (DNS) [Liu and Albitz, 2006] is a distributed service that is used to look
up a network address associated with a name, such as the address of a so-called domain name
like [Link]. In terms of the OSI reference model, DNS is an application and
therefore is logically placed in the application layer. However, it should be quite obvious that DNS
is offering a general-purpose, application-independent service. Arguably, it forms part of the
middleware.

for example an electronic mail system. In principle, the core of the mail delivery system can be
seen as a middleware communication service
Middleware is invented to provide common services and protocols that can be used by many
different applications
➢ A rich set of communication protocols
➢ (Un)marshaling of data, necessary for integrated systems
 ➢ Naming protocols, to allow easy sharing of resources
➢ Security protocols for secure communication
➢ Scaling mechanisms, such as for replication and caching

Fig: - An adapted layering scheme

Types of Communication

we concentrate on high-level middleware communication services. Before doing so, there are
other general criteria for distinguishing (middleware) communication. To understand the various
alternatives in communication that middleware can offer to applications, we
view the middleware as an additional service in client-server computing, as shown in Figure 4.4.
Consider, for example an electronic mail system. In principle, the core of the mail delivery system
can be seen as a middleware communication service. Each host runs a user agent allowing users
to compose, send, and receive e-mail. A sending user agent passes such mail to the mail delivery
system, expecting it, in turn, to eventually deliver the mail to the intended recipient. Likewise,
the user agent at the receiver’s side connects to the mail delivery system to see whether any mail
has come in. If so, the messages are transferred to the user agent so that they can be displayed
and
read by the user.
Figure 4.4: Viewing middleware as an intermediate (distributed) service in
application-level communication.

An electronic mail system is a typical example in which communication is persistent. With

persistent communication, a message that has been submitted for transmission is stored by the
communication middleware as long as it takes to deliver it to the receiver. In this case, the
middleware will store the message at one or several of the storage facilities shown in As a
consequence, it is not necessary for the sending application to continue execution after
submitting the message. Likewise, the receiving application need not be executing when the
message is submitted.
An electronic mail system is a typical example in which communication is persistent
Transient communication: - Transient communication refers to a type of communication
where the sender and receiver exchange messages without establishing a persistent connection.
In transient communication, messages are typically sent and received asynchronously, and there
may not be a continuous channel open between the communicating parties.
Now, let's walk through a scenario of transient communication within this distributed system:

Order Placement: When a customer places an order on the e-commerce website, the frontend sends an
HTTP request to the Order Service with details of the order.

Transient Message to Inventory Service: Upon receiving the order, the Order Service needs to check the
availability of products in the inventory before confirming the order. It sends a transient message (e.g., a
message queue or a publish-subscribe message) to the Inventory Service requesting to check the stock
levels of the ordered items.

Inventory Service Processing: The Inventory Service receives the message, queries its database to check
the availability of products, and sends a response message back to the Order Service with the result (e.g.,
"sufficient stock available" or "out of stock").

Order Processing: Based on the response from the Inventory Service, the Order Service proceeds with
order processing. If the products are available, it updates the order status and sends a transient message
to the Notification Service to notify the customer about the order confirmation.
Notification to Customer: The Notification Service receives the message, prepares and sends a notification
(e.g., an email) to the customer informing them that their order has been successfully placed.

Persistent communication: - Persistent communication refers to a type of communication

where the sender and receiver maintain a continuous connection for the exchange of messages
over an extended period. In persistent communication, the connection remains open for the
duration of the interaction, allowing real-time or near-real-time communication between the
parties involved.
Example:- email, stock trading application

Synchronous Communication: - This transmission is the full-duplex type. Between sender

and receiver, synchronization is compulsory. In Synchronous transmission, there is no time-gap
present between data.

Example:
• Chat Rooms
• Telephonic Conversations
• Video Conferencing

Asynchronous Communication: - data is sent in form of byte or character. This

transmission is the half-duplex type transmission. In this transmission start bits and stop bits
are added with data. It does not require synchronization.

Examples: -
• Email
• Forums
• Letters

Client and Server Stubs

A stub is a program that acts as a temporary replacement for a remote service or object.

Client and server stubs are components commonly used in distributed computing environments
to facilitate communication between clients and servers.

Client Stub
➢ A client stub, also known as a client proxy or client-side proxy, is a local representation of
a remote service or object.
➢ It acts as a proxy for the client application to interact with the remote service, hiding the
details of network communication and marshaling/unmarshaling of data.
➢ The client stub provides methods or functions that correspond to the operations exposed
by the remote service.
 ➢ When the client application invokes a method on the client stub, the stub handles the
communication with the remote server, including sending the request over the network
and receiving the response.
➢ From the client's perspective, interacting with the client stub feels like calling methods on
a local object, even though the operations are executed remotely.

Server Stub: -
➢ A server stub, also known as a server skeleton or server-side skeleton, is the counterpart
to the client stub on the server side.
➢ It receives incoming requests from clients and forwards them to the actual
implementation of the remote service.
➢ The server stub performs tasks such as unmarshaling the incoming requests, invoking the
corresponding methods on the server-side implementation, and marshaling the response
back to the client.
➢ Like the client stub, the server stub abstracts away the details of network communication,
allowing the server-side implementation to focus on business logic.
➢ The server stub is often generated automatically from the interface definition or service
contract, ensuring consistency between the client and server components

client and server stubs are used to handle the communication between the client and the server.
The client stub acts as a proxy for the client. It intercepts any requests made by the client, formats
them into a format that the server can understand, and sends them to the server. The server stub
acts as a proxy for the server. It receives the requests from the client, and passes them on to the
appropriate function or procedure on the server. It also receives any responses from the server
and sends them back to the client. In this way, client and server stubs allow for the client and
server to communicate seamlessly and transparently, as if they were in the same process. This
allows for the client and server to be implemented in different languages, running on different
platforms, and even located on different machines.

RPC

A software communication protocol that one program can use to request a service from a program located in
another computer on a network without having to understand the network's details.

The proposal was to allow programs to call procedures located on other machines. When a process on machine A
calls a procedure on machine B, the calling process on A is suspended, and execution of the called procedure takes
place on B. Information can be transported from the caller to
the callee in the parameters and can come back in the procedure result. No message passing at all is visible to the
programmer. This method is known as remote procedure call, or often just RPC.

The idea behind RPC is to make a remote procedure call look as much as possible like a local one. In other words,
we want RPC to be transparent—the calling procedure should not be aware that the called procedure is executing
on a different machine or vice versa
RPC uses Client Server Model

The following steps take place during a RPC :

1. The client procedure calls the client stub in the normal way.
2. The client stub builds a message and calls the local operating system
3. The client’s OS sends the message to the remote OS.
4. The remote OS gives the message to the server stub.
5. The server stub unpacks the parameter(s) and calls the server.
6. The server does the work and returns the result to the stub.
7. The server stub packs the result in a message and calls its local OS.
8. The server’s OS sends the message to the client’s OS.
9. The client’s OS gives the message to the client stub.
10. The stub unpacks the result and returns it to the client.
 Difference between RPC and RMI

RPC RMI

1. RPC is a library and OS dependent platform. Whereas it is a java platform.

2. RPC supports procedural programming. RMI supports object-oriented 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 are While in RMI, objects are passed as
5.
ordinary or normal data. parameter.

6. RPC does not provide any security. While it provides client level security.

While it’s development cost is fair or

7. It’s development cost is huge.
reasonable.

There is multiple codes are needed for While there is multiple codes are not needed
8.
simple application in RPC. for simple application in RMI.

Can be complex due to low-level

9. Generally simpler to use and implement
implementation

Passing Value Parameters

The function of the client stub is to take its parameters, pack them into a message, and send them to the server
stub. While this sounds straightforward, it is not quite as simple as it at first appears.
Packing parameters into a message is called parameter marshaling. Returning to our append operation, we thus
need to ensure that its two parameters (data and dbList) are sent over the network and correctly interpreted by
the server.

There’s more than just wrapping parameters into a message

 ● Client and server machines may have different data representations (think of byte ordering)
● Wrapping a parameter means transforming a value into a sequence of bytes
● Client and server have to agree on the same encoding:
● How are basic data values represented (integers, floats, characters)
● How are complex data values represented (arrays, unions)

Some assumptions
● Copy in/copy out semantics: while procedure is executed, nothing can be assumed about parameter
values.
● All data that is to be operated on is passed by parameters. Excludes passing references to (global)
data

parameter specification and stub generation

A stub is a piece of code that translates parameters sent between the client and server during a remote procedure
call in distributed computing. An RPC’s main purpose is to allow a local computer (client) to call procedures on
another computer remotely (server) because the client and server utilize distinct address spaces. That is the reason
parameters used in a function (procedure) call must be translated; otherwise, the values of those parameters
would be useless because pointers to parameters in one computer memory would point to different data on the
other computer.
In most cases, stub libraries are installed on both the client and the server. Client stubs transform (marshaling)
parameters used in function calls and then reconvert the result returned by the server when the function is
completed. On the other side, client arguments are reconverted by server stubs, and results are converted back
after function execution.

Stub Generation:

Stubs can be created in two different ways:

Manual Generation of Stub: In the manual generation of stubs, the RPC implementer
provides a collection of translation functions from which a user can create their own
stubs using this way. This method is easy to use and can handle a wide range of
argument types.

Automatic Generation of Stub: In the automatic generation of stubs, client and server
interfaces are defined using Interface Definition Language (IDL). An interface
specification, for example, contains information indicating whether each argument is
input, output, or both; only input arguments must be passed from client to server, while
only output elements must be copied from server to client. This is the most popular way
of generating stubs.

● Import an Interface: A client program that calls procedures from an interface is

said to import the interface.
● Export an Interface: A server program that implements a procedure in an
interface is said to export the interface.
● Interface Definition Language (IDL): When building a distributed application, a
programmer first creates an interface definition in IDL, then writes the client
program that imports the interface and the server program that exports it. An IDL
compiler is used to process the interface definition and generate components
that may be coupled with client and server programs without requiring any
changes to existing compilers. The compiler generates the required marshaling
and unmarshalling operations in each stub procedure and a header file that
supports the data types in the interface specification from an interface for each
procedure in the interface. Both the client and server programs contain the
header file, and the client stub procedures are compiled and linked with the
client program, while the server stub procedures are compiled and linked with
 the server program. An IDL compiler can be programmed to interpret interface
definitions for a variety of languages, allowing clients and servers written in
different languages to communicate via Remote Procedure Calls (RPC)

Asynchronous RPC

To support situations in which there is simply no result to return to the client, RPC
systems may provide facilities for what are called asynchronous RPCs

Try to get rid of the strict request-reply behavior, but let the client continue without
waiting for an answer from the server

With asynchronous RPCs, the server, in principle, immediately sends a reply back to the
client the moment the RPC request is received, after which it locally calls the requested
procedure. The reply acts as an acknowledgment to the client that the server is going to
process the RPC. The client will continue without further blocking as soon as it has
received the server’s acknowledgment

writing and binding a client and a server

To allow a client to call a server, it is necessary that the server has been registered and is
prepared to accept incoming calls. Registration of a server makes it possible for a client
to locate the server and bind to it.

Finding the location of the server is done in two steps:

1. Locate the server’s machine.

2. Locate the server (i.e., the correct process) on that machine

The second step is somewhat subtle. Basically, what it comes down to is that to
communicate with a server, the client needs to know a port on the server’s machine to
which it can send messages. A port is used by the server’s operating system to
distinguish incoming messages for different processes. In DCE, a table of (server,port)
pairs is maintained on each server machine by a process called the DCE daemon. Before
it becomes available for incoming requests, the server must ask the operating system
for a port. It then registers this port with the DCE daemon. The DCE daemon records this
information (including which protocols the server speaks) in the port table for future
use. The server also registers with the directory service by providing it the network
address of the server’s machine and a name under which the server can be looked up.

Message-Passing Interface (MPI)

The message passing interface (MPI) is a standardized means of exchanging messages

between multiple computers running a parallel program across distributed memory.

MPI is designed for parallel applications and as such is tailored to transient

communication

The following list includes some basic key MPI concepts and commands:

Comm. These are communicator objects that connect groups of processes in MPI.
Communicator commands give a contained process an independent identifier, arranging
it as an ordered topology. For example, a command for a base communicator includes
MPI_COMM_WORLD.

· Color. This assigns a color to a process, and all processes with the same color are
located in the same communicator. A command related to color includes
MPE_Make_color_array, which changes the available colors.

· Key. The rank or order of a process in the communicator is based on a key. If two
processes are given the same key, the order is based on the process's rank in the
communicator.

· Newcomm. This is a command for creating a new communicator.

MPI_COMM_DUP is an example command to create a duplicate of a comm with the
same fixed attributes.

· Derived data types. MPI functions need a specification to what type of data is sent
between processes. MPI_INT, MPI_CHAR and MPI_DOUBLE aid in predefining the
constants.

· Point-to-point. This sends a message between two specific processes. MPI_Send

and MPI_Recv are two common blocking methods for point-to-point messages. Blocking
refers to having the sending and receiving processes wait until a complete message has
been correctly sent and received to send and complete a message.

· Collective basics. These are collective functions that need communication among
all processes in a process group. MPI_Bcast is an example of such, which sends data
from one node to all processes in a process group.

· One-sided. This term is typically used referring to a form of communications

operations, including MPI_Put, MPI_Get and MPI_Accumulate. They refer specifically to
being a writing to memory, reading from memory and reducing operation on the same
memory across tasks.
 Message broker

A message broker acts as an application-level gateway in a message-queuing system. Its

main purpose is to convert incoming messages so that they can be understood by the
destination application.

► Transforms incoming messages to target format

► Very often acts as an application gateway
► May provide subject-based routing capabilities (i.e., publish-subscribe capabilities

IBM’s WebSphere message-queuing system

Message Queuing allows applications to communicate by sending messages to each

other. The Message Queue provides temporary message storage when the destination
program is busy or not connected.
A Message Queue provides an asynchronous communications protocol, which is a
system that puts a message onto a Message Queue and does not require an immediate
response to continuing processing. Email is probably the best example of asynchronous
communication. When an email is sent, the sender continues to process other things
without needing an immediate response from the receiver. This way of handling
messages decouples the producer from the consumer so that they do not need to
interact with the message queue at the same time.

Other’s Example of Message Queue:- Apache Kafka, RabbitMQ, and LavinMQ,

Different styles of message queuing

● Point-to-point
● Publish/Subscribe

Data Stream

Data streaming is the continuous flow of data as it's generated, enabling real-time
processing and analysis for immediate insights.
with every industry reliant on real-time data, today, data streaming platforms like
Confluent power everything from multiplayer games, real-time fraud detection, and
social media feeds, to stock trading platforms and GPS tracking.

Examples
real-time stock trades,
up-to-the-minute retail inventory management,
social media feeds,
multiplayer games
For example, when a passenger calls Lyft, real-time streams of data join together to
create a seamless user experience. Through this data, the application pieces together
real-time location tracking, traffic stats, pricing, and real-time traffic data to
simultaneously match the rider with the best possible driver, calculate pricing, and
estimate time to destination based on both real-time and historical data.

Quality of service (QoS)

Quality of service (QoS) refers to any technology that manages data traffic to reduce
packet loss, latency and jitter on a network. QoS controls and manages network
resources by setting priorities for specific types of data on the network.

QoS is important because:-

● Enterprises need to provide stable services for employees and customers to use.
● Quality of service determines quality of experience (QoE).
● If the services an organization provides are not reliable, customer and employee
relationships may be put at risk.