Introduction to Distributed Systems Characterization of Distributed Systems–Distributed Architectural Models–Remote Invocation–Request-Reply Protocols –Remote Procedure Call Remote Method Invocation–Group Communication

1. What is a Distributed System?
A distributed system is a collection of autonomous computer
linked by a computer network and equipped with distributed
system software.
Communication Network
Distributed System Software
Data

2. Working of DS
DS software enables computer to coordinate their activities to
share the resources of software, hardware and data.
Distributed Application
Middle Ware Services
Local
OS
Local
OS
Local
OS
Network
Machine A Machine B Machine C

3. ROLE OF DISTRIBUTED SYSTEM SOFTWARE
• The main roles and functions of distributed system software include:
1. Resource sharing
2. Communication
3. Scalability
4. Fault tolerance
5. Consistency and coordination
6. Load balancing
7. Security
8. Transparency
9. Performance monitoring
10.Synchronization and concurrency control

4. Characterization of Distributed systems
• Resource Sharing: It is the ability to use any Hardware, Software, or
Data anywhere in the System.
• Openness: It is concerned with Extensions and improvements in the
system (i.e., How openly the software is developed and shared with
others).
• Concurrency: It is naturally present in Distributed Systems, that deal
with the same activity or functionality that can be performed by separate
users who are in remote locations. Every local system has its independent
Operating Systems and Resources.

5. Characterization of Distributed systems
• Scalability: It increases the scale of the system as a number of
processors communicate with more users by accommodating to
improve the responsiveness of the system.
• Fault tolerance: It cares about the reliability of the system if there is
a failure in Hardware or Software, the system continues to operate
properly without degrading the performance the system.
• Transparency: It hides the complexity of the Distributed Systems to
the Users and Application programs as there should be privacy in every
system.

6. Characterization of Distributed systems
• Heterogeneity: Networks, computer hardware, operating systems,
programming languages, and developer implementations can all vary
and differ among dispersed system components.

7. Distributed Architectural Models

8. I. ARCHITECTURAL MODELS
• Architectural model describes responsibilities distributed between system components
and how are these components placed.
A distributed System(DS) is one in which
(i)Hardware and software components, located at remote networked computers,
coordinate and communicate their actions only by passing messages. Any distance
may separate computers in the network.
(ii)Sharing of resources is the main motivation of distributed systems. Resources may
be managed by servers and accessed by clients, or its users as single virtual machine
and runs its own OS.

9. a) Client-server model
• The system is structured as a set of processes, called servers, that
offer services to the users, called clients.
• The client-server model is usually based on a simple request/reply
protocol implemented with send/receive primitives or using remote
procedure calls (RPC) or remote method invocation (RMI):
• The client sends a request (invocation) message to the server asking
for some service;
• The server does the work and returns a result (e.g. the data
requested) or an error code if the work could not be performed.

10. Client - server model

11. b) Peer-to-peer
All processes (objects) play similar role.
•Processes (objects) interact without particular distinction between
clients and servers.
•The pattern of communication depends on the particular application.
•A large number of data objects are shared; any individual computer
holds only a small part of the application database.
•Processing and communication loads for access to objects are
distributed across many computers and access links.
•This is the most general and flexible model.
•It distributes shared resources widely -> share computing and
communication loads.

12. Peer-to-peer

13. II. INTERACTION MODEL
• Interaction model are for handling time i. e. for process execution,
message delivery, clock drifts etc.
• Synchronous distributed systems
• Main features:
• Lower and upper bounds on execution time of processes can be set.
• Transmitted messages are received within a known bounded time.
• Drift rates between local clocks have a known bound.

14. INTERACTION MODEL
• Main features:
• Lower and upper bounds on execution time of processes can be set.
• Transmitted messages are received within a known bounded time.
• Drift rates between local clocks have a known bound.
• Important consequences:
1.In a synchronous distributed system there is a notion of global physical
time(with a known relative precision depending on the drift rate).
2.Only synchronous distributed systems have a predictable behavior in
terms of timing. Only such systems can be used for hard real-time
applications.
3.In a synchronous distributed system, it is possible and safe to use
timeouts in order to detect failures of a process or communication link.

15. • It is difficult and costly to implement synchronous distributed systems.
• Asynchronous distributed systems
• Many distributed systems (including those on the Internet) are asynchronous.
• No bound on process execution time (nothing can be assumed about speed, load,
and reliability of computers).
• No bound on message transmission delays (nothing can be assumed about speed,
load, and reliability of interconnections)
• No bounds on drift rates between local clocks.
• Important consequences:
1.In an asynchronous distributed system there is no global physical time. Reasoning
can be only in terms of logical time (see lecture on time and state).
2.Asynchronous distributed systems are unpredictable in terms of timing.
3.No timeouts can be used.
• Asynchronous systems are widely and successfully used in practice.

16. iii. Fault Models
1.Node Failures:
1.Crash Failure: A node abruptly stops functioning and remains inactive.
2.Omission Failure: A node fails to send or receive messages.
2.Communication Failures:
1.Link Failure: The communication link between two nodes becomes unavailable.
2.Delayed Messages: Messages take longer than expected to reach their
destination.
3.Duplicate Messages: A message is received multiple times due to network
issues.
3.Clock Synchronization Issues:
1.Clock Drift: Local clocks of nodes run at different rates, leading to time
inconsistencies.
2.Clock Skew: The time difference between clocks of different nodes.
4.Network Partition:
1.Network Partition: The network becomes divided into separate subnetworks,
preventing communication between nodes on different sides of the partition.

17. iii. Fault Models
5. Software Failures:
1.Software Bug: A programming error leads to incorrect behavior or crashes.
2.Deadlock: A set of processes or nodes are waiting for resources that are never
released.
6. Hardware Failures:
1.Disk Failure: A storage device becomes inaccessible or corrupted.
2.Memory Corruption: A portion of memory becomes corrupted, leading to data
loss or system crashes.
7. Power Failures:
1.Power Outage: The entire system or specific components lose power abruptly.
8. External Failures:
1.Environmental Factors: Environmental conditions such as temperature,
humidity, and electromagnetic interference can lead to failures.

18. iii. Fault Models
• Defining a fault model helps in designing fault-tolerant strategies to
ensure that a distributed system continues to operate even in the
presence of these failures.
• These strategies can include replication, redundancy, error
detection and correction codes, consensus algorithms, and
more.
• Different distributed systems might have varying fault tolerance
requirements based on factors like criticality, scalability,
performance, and cost.

19. Remote Invocation

20. REMOTE INVOCATION
Request-Reply Communication:
 Most primitive; minor improvement over underlying IPC primitives.
 2-way exchange of messages as in client-server computing.
 RPC, RMI: mechanisms enabling a client to invoke a procedure/method from the server via
communication between client and server.
Remote Procedure Call (RPC):
 Extension of conventional procedural programming model.
 Allow client programs to transparently call procedures in server programs running in separate processes,
and in separate machines from the client.
Remote Method Invocation (RMI):
 Extension of conventional object-oriented programming model
 Allows objects in different processes to communicate i.e. An object in one JVM is able to invoke
methods in an object in another JVM.
 Extension of local method invocation: allows object in one process to invoke methods of an object living
in another process.

21. 1. REQUEST-REPLY PROTOCOL

22. REQUEST-REPLY PROTOCOL
• Most Common Exchange Protocol for Remote Invocation

23. REQUEST-REPLY PROTOCOL
Operations
doOperation(): send request to remote object, and returns the reply received
getRequest(): acquire client request at server port
sendReply(): sends reply message from server to client
Design issues
Timeouts: what to do when a request times out? How many retries?
Duplicate messages: how to discard?
E.g., recognise successive messages with the same request id and filter them
Lost replies: dependent on idempotency of server operations
History: do servers need to send replies without re-execution? then history needs to be maintained

24. Exchange protocols
Different flavours of exchange protocols:
Request (R): no value to be returned from remote operation
o client needs no confirmation operation has been executed
o e.g. sensor producing large amounts of data: may be acceptable for some loss
Request-reply (RR): useful for most client-server exchanges. Reply regarded as
acknowledgement of request
o subsequent request can be considered acknowledgement of the previous reply
Request-reply-acknowledge (RRA): acknowledgement of reply contains request id,
allowing server to discard entry from history

25. i. Request Protocol(r)

26. i. Request Protocol(r)
• The Request Protocol is also known as the R protocol.
• It is used in Remote Procedure Call (RPC) when a request is made from the
calling procedure to the called procedure. After execution of the request, a
called procedure has nothing to return and there is no confirmation required
of the execution of a procedure.
• Because there is no acknowledgement or reply message, only one message is
sent from client to server

27. ii. Request/Reply Protocol(RR)

28. ii. Request/Reply Protocol(RR)
It works well for systems that involve simple RPCs.
• This protocol has a concept base of using implicit acknowledgements instead of explicit
acknowledgements.
• To deal with failure handling e.g., lost messages, the timeout transmission technique is used with
RR protocol.
• If a client does not get a response message within the predetermined timeout period, it retransmits
the request message.
• Exactly-once semantics is provided by servers as responses get held in reply cache that helps in
filtering the duplicated request messages and reply messages are retransmitted without processing
the request again.
• If there is no mechanism for filtering duplicate messages then at least-call semantics is used by RR
protocol in combination with timeout transmission.

29. iii. The Request/Reply/Acknowledgement-
Reply Protocol(RRA)

30. iii. The Request/Reply/Acknowledgement-
Reply Protocol(RRA)
• This protocol is also known as the RRA protocol (request/reply/acknowledge-reply).
• Exactly-once semantics is provided by RR protocol which refers to the responses getting
held in reply cache of servers resulting in loss of replies that have not been delivered.
• The RRA (Request/Reply/Acknowledgement-Reply) Protocol is used to get rid of the
drawbacks of the RR (Request/Reply) Protocol.
• In this protocol, the client acknowledges the receiving of reply messages and when the server
gets back the acknowledgement from the client then only deletes the information from its cache.
• Because the reply acknowledgement message may be lost at times, the RRA protocol requires
unique ordered message identities. This keeps track of the acknowledgement series that has been
sent.

31. REMOTE PROCEDURE CALL (RPC)

32. Remote Procedure Call
• Remote Procedure Call (RPC) is a communication technology that
is used by one program to make a request to another program for
utilizing its service on a network without even knowing the
network’s details.
• A function call or a subroutine call are other terms for a
procedure call.
• It is based on the client-server concept.
• The client is the program that makes the request, and the server
is the program that gives the service.
• An RPC, like a local procedure call, is based on the synchronous
operation that requires the requesting application to be
stopped until the remote process returns its results.

33. Working Procedure for RPC Model

34. Working Procedure for RPC Model
• The process arguments are placed in a precise location by
the caller when the procedure needs to be called.
• Control at that point passed to the body of the method, which
is having a series of instructions.
• The procedure body is run in a recently created execution
environment that has duplicates of the calling instruction’s
arguments.
• At the end, after the completion of the operation, the calling
point gets back the control, which returns a result.

35. Working Procedure for RPC Model
• The call to a procedure is possible only for those procedures that are not within the
caller’s address space because both processes (caller and callee) have distinct
address space and the access is restricted to the caller’s environment’s data and
variables from the remote procedure.
• The caller and callee processes in the RPC communicate to exchange information
via the message-passing scheme.
• The first task from the server-side is to extract the procedure’s parameters
when a request message arrives, then the result, send a reply message, and
finally wait for the next call message.
• Only one process is enabled at a certain point in time.
• The caller is not always required to be blocked.
• The asynchronous mechanism could be employed in the RPC that permits the client
to work even if the server has not responded yet.
• In order to handle incoming requests, the server might create a thread that frees
the server for handling consequent requests.

36. Types of RPC
• Three types of RPC are:
1. Callback RPC
2. Broadcast RPC
3. Batch-mode RPC

37. 1. CALLBACK RPC
• A P2P (Peer-to-Peer)paradigm opts between participating
processes.
• In this way, a process provides both client and server
functions which are quite helpful.
• Callback RPC’s features include:
• The problems encountered with interactive applications that
are handled remotely.
• It provides a server for clients to use.
• Due to the callback mechanism, the client process is delayed.
• Deadlocks need to be managed in callbacks.
• It promotes a Peer-to-Peer (P2P) paradigm among the
processes involved.

38. 2. BROADCAST RPC
• A client’s request that is broadcast all through the network
and handled by all servers that possess the method for
handling that request is known as a broadcast RPC.
• Broadcast RPC’s features include:
• You have an option of selecting whether or not the client’s
request message have to be broadcast.
• It also gives you the option of declaring broadcast ports.
• It helps in shrinking physical network load.

39. BATCH-MODE RPC
• Batch-mode RPC helps to queue, separate RPC requests, in a
transmission buffer, on the client-side, and then send them
on a network in one batch to the server.
• Batch-mode RPC’s features include:
• It reduces the overhead of requesting the server by sending
them all at once using the network.
• It is used for applications that require low call rates.
• It necessitates the use of a reliable transmission protocol.

40. • Remote Procedure Calls have disjoint address space i.e.
different address space, unlike Local Procedure Calls.
• Remote Procedure Calls are more prone to failures due to
possible processor failure or communication issues of a
network than Local Procedure Calls.
• Because of the communication network, remote procedure
calls take longer than local procedure calls.
Local Procedure Call Vs Remote Procedure Call

41. REMOTE METHOD
INVOCATION

42. REMOTE METHOD INVOCATION
• The RMI (Remote Method Invocation) is an API that
provides a mechanism to create distributed application in
java.
• The RMI allows an object to invoke methods on an object
running in another JVM.
• The RMI provides remote communication between the
applications using two objects stub and skeleton.

43. stub
• The stub is an object, acts as a gateway for the client side.
• All the outgoing requests are routed through it.
• It resides at the client side and represents the remote object.
• When the caller invokes method on the stub object, it does
the following tasks:
1. It initiates a connection with remote Virtual Machine (JVM),
2. It writes and transmits (marshals) the parameters to the remote
Virtual Machine (JVM),
3. It waits for the result,
4. It reads (un-marshals) the return value or exception, and
5. It finally, returns the value to the caller.

44. SKELETON
• The skeleton is an object, acts as a gateway for the server
side object. All the incoming requests are routed through it.
• When the skeleton receives the incoming request, it does the
following tasks:
1. It reads the parameter for the remote method
2. It invokes the method on the actual remote object, and
3. It writes and transmits (marshals) the result to the
caller.

45. Working OF rmi

46. The remote invocation process typically involves the following
steps:
1.Client Program: The client program initiates the remote
invocation. It contains the code that calls the remote procedure
as if it were a local function call.
2.RPC Stub (Client Stub): The client program uses a local
procedure called an RPC stub, or client stub. The stub is
responsible for packaging the parameters of the procedure call
into a message and sending it over the network to the remote
server.
3.Network Communication: The message containing the
procedure call information is transmitted over the network to the
remote server.
4.Server Program: On the remote server, there is a corresponding
server program that listens for incoming RPC requests.

47. 5.RPC Skeleton (Server Stub): The server program uses a local
procedure called an RPC skeleton, or server stub. The skeleton
unpacks the received message, extracts the procedure call details,
and executes the procedure with the provided parameters.
6.Procedure Execution: The server executes the requested
procedure using the provided parameters and generates a result.
7.Result Transmission: The server's result is sent back to the client
over the network.
8.Client Processing: The client's RPC stub receives the result,
extracts the returned value, and returns it to the client program,
which continues its execution as if the remote procedure call had
been a local function call.

48. GROUP COMMUNICATION

49. Group Communication
• Communication between two processes in a distributed system is
required to exchange various data, such as code or a file, between the
processes.
• When one source process tries to communicate with multiple processes
at once, it is called Group Communication.
• A group is a collection of interconnected processes with abstraction.
• This abstraction is to hide the message passing so that the
communication looks like a normal procedure call.
• Group communication also helps the processes from different hosts to
work together and perform operations in a synchronized manner,
therefore increases the overall performance of the system.

50. types

51. Unicast Communication
• When the host process tries to communicate with a single process in a
distributed system at the same time.
• Although, same information may be passed to multiple processes.
• This works best for two processes communicating as only it has to treat
a specific process only.
• However, it leads to overheads as it has to find exact process and then
exchange information/data.

52. Multicast Communication
• When the host process tries to communicate with a designated group
of processes in a distributed system at the same time.
• This technique is mainly used to find a way to address problem of a
high workload on host system and redundant information from process
in system.
• Multitasking can significantly decrease time taken for message
handling.

53. Broadcast Communication
• When the host process tries to communicate with every process in a
distributed system at same time.
• Broadcast communication comes in handy when a common stream of
information is to be delivered to each and every process in most efficient
manner possible.
• Since it does not require any processing whatsoever, communication is very
fast in comparison to other modes of communication.
• However, it does not support a large number of processes and cannot treat a
specific process individually.

54. Essential features
• Atomicity (all-or-nothing): when a message is sent to a group, it will either arrive correctly at all
members of the group or at none of them.
• Ordering
• FIFO ordering: Messages originating from a given sender are delivered in the order they have been
sent, to all members of the group.
Px
P4
P3
P2
P1
m4, m2, m3, m1
m2, m4, m1, m3
m2, m1, m4, m3
m4, m3, m2, m1
send m3; Py
send
m1;
send
m2;
send
m4;

55. Essential features
• Total-ordering: When several messages, from different senders, are
sent to a group, the messages reach all the members of the group in
the same order.
Px
P4
P3
P2
P1
m2, m1, m4, m3
m2, m1, m4, m3
m2, m1, m4, m3
m2, m1, m4, m3
send m3; Py
send
m1;
send
m2;
send
m4;