DISTRIBUTED SYSTEMS

🔷 Characterization of Distributed Systems

🔹 1. Introduction to Distributed Systems

🧠 What is a Distributed System?
A Distributed System is a collection of independent computers (nodes) that appear to the
users as a single coherent system.
These computers communicate and coordinate with each other via a network, share
resources, and collaborate to complete tasks.
📌 In simple words: “Multiple systems, working together as one.”
✅ Key Properties:
 No shared memory – only communication through messages
 Nodes are autonomous but cooperate
 Failures are inevitable, but the system must keep running
🔹 2. Characteristics of Distributed Systems
These are the core features that define and shape the behavior of a distributed system:
Characteristic Description

Concurrency Multiple processes run simultaneously across the system.

There is no single time source. Systems must manage time

No Global Clock
independently.

Independent
Each node can fail independently, and the system must tolerate it.
Failures

The complexity is hidden from the user (location, access, failure,

Transparency
migration, etc.).

Scalability Can grow to support more users or resources without crashing.

Heterogeneity Combines different hardware, OS, programming languages, etc.

Openness Easily extendable and follows standard protocols and interfaces.

Ensures confidentiality, integrity, and access control in a decentralized

Security
environment.

🔹 3. Types of Transparency in Distributed Systems

Transparency makes the system look like a single unit to users:
Type of Transparency Meaning

Access Uniform way to access local and remote resources

Location Users don’t need to know the location of resources

Concurrency Allows multiple processes without conflict

Replication Multiple copies of a resource look like one

Failure System hides partial failures from users

Migration Resources can move without affecting users

🔹 4. Examples of Distributed Systems

Distributed systems are all around us! Some examples include:
✅ Real-World Examples:
System Type Description

The largest distributed system ever — billions of nodes

Internet
communicating worldwide

Accessing web pages involves a network of servers,

World Wide Web
DNS, and cache systems

Email Systems Distributed mail servers route emails between users

Cloud Computing (AWS, Azure, Offers computing, storage, and networking across
GCP) distributed data centers

Distributed Databases (e.g., Data is partitioned and replicated across several

MongoDB, Cassandra) machines

Game servers handle players distributed across the

Online Multiplayer Games
globe

Peer-to-Peer Systems (e.g., Each node acts as both client and server — sharing
BitTorrent) resources equally

🔷 Resource Sharing and the Web, Challenges in Distributed

Systems.

🔹 1. Resource Sharing in Distributed Systems

Resource Sharing refers to the ability of distributed systems to allow multiple users or
processes to access and utilize hardware, software, and data resources spread across
different locations — transparently and efficiently.
✅ Examples:
 Shared file systems (e.g., Dropbox, Google Drive)
 Distributed databases (e.g., Cassandra)
 Cloud-based computation (e.g., AWS Lambda)
 Shared printing or network resources
The goal is to maximize efficiency, reduce redundancy, and enable collaborative usage of
resources.

🔹 2. Role of the Web in Resource Sharing

The Web provides a unified platform for accessing and sharing resources across a distributed
network. Through HTTP protocols, web browsers, and web services/APIs, users can access
remote files, applications, or computing power regardless of where they physically exist.
🔗 Technologies Involved:
 HTTP/HTTPS: Communication over the internet
 RESTful APIs / SOAP services: Programmatic resource sharing
 Web servers and browsers: Interfaces for distributed interaction
The web acts like a digital post office, delivering requests and resources between machines,
users, and services spread across the globe.

🔹 3. Challenges in Distributed Systems

Distributed systems, while powerful, face many inherent challenges:
Challenge Description

Heterogeneity Different hardware, OS, networks, and languages

Scalability System must support growth in users/resources

Fault Tolerance Must operate despite node failures

Concurrency Multiple users access shared resources simultaneously

Security Ensure data privacy, authentication, and authorization

Transparency Hide complexity from users (access, location, migration)

Latency Communication delay due to network transmission

Resource Management Efficient allocation and scheduling of tasks

🔹 4. Data Migration
Data Migration refers to transferring data from one machine/location to another in a
distributed setup.
✅ Purposes:
 Balancing storage load
 Backup and replication
 Moving data closer to users
 Upgrading systems
⚠️Challenges:
 Maintaining data integrity and consistency
 Minimizing downtime
 Secure transmission of sensitive data
🔹 5. Computation Migration
Computation Migration involves moving code or executing processes from one machine
to another. This helps in load distribution, failure recovery, and improving performance.
✅ Why Migrate Computation?
 Perform heavy computation on more powerful nodes
 Move tasks closer to the data
 Reduce response time
 Adapt to system failures
🔄 Types:
1. Strong Migration – Moves code and current execution state
2. Weak Migration – Moves code only; restarts execution from beginning
⚠️Challenges:
 Capturing execution state (in strong migration)
 Platform compatibility
 Communication overhead
 Security of executing code remotely

🔷 1. Architectural Model in Distributed Systems

The architectural model defines how components of a distributed system interact and are
organized. It describes the structure and relationship between components like clients,
servers, and peers.
🔹 Purpose:
 To understand how distributed systems are constructed and how components
communicate and coordinate.
 Helps in designing systems that are scalable, reliable, and maintainable.
🔹 Key Components:
1. Clients – Request services from servers.
2. Servers – Provide services to clients.
3. Peers – Act as both clients and servers (in Peer-to-Peer systems).
4. Middleware – Software layer that manages communication, coordination, and data
sharing.
🔹 Types of Architectural Models:
1. Client-Server Model
 The client-server model is a centralized system where the client asks for something
and the server provides it. It works like a question-and-answer process — the client
sends a request, the server does the work, and then sends back a response. This is
called the request-response model.

 It can be achieved by using TCP/IP, HTTP protocols on the

transport layer.
 This is mainly used in web services, cloud computing,
database management systems etc.

2. Layered Architecture
 Functions divided into layers: Presentation, Business Logic, Data.
 Layered Architecture in distributed systems organizes the system into hierarchical
layers, each with specific functions and responsibilities. This design pattern helps
manage complexity and promotes separation of concerns.
 In a layered architecture, the system is divided into distinct layers, where each layer
provides specific services and interacts only with adjacent layers.
 This separation helps in managing and scaling the system more effectively.
3. Peer-to-Peer (P2P) Architecture
 No fixed client or server.
  The peer-to-peer model is a decentralized system where all computers (called
peers) are equal. Each peer can ask for services and also give services to others. It is
highly flexible and scalable because peers can join or leave anytime.
 There is no central server — all peers talk to each other directly and share
resources like files or data by following certain rules. Peers search and connect to
each other whenever they need something.
 Example: Torrent file sharing (BitTorrent).

4. Multi-tier Architecture
 Extends client-server into more layers: Presentation tier, Application tier, and Data
tier.
 Common in web applications.
1. Presentation Tier:
The presentation tier, also known as the user interface tier, is responsible for presenting
information to users and accepting user inputs. Its main purpose is to handle user interactions
and display data in a human-readable format. This tier provides the interface through which
users interact with the application.

2. Application Tier:

The application tier, also referred to as the business logic tier or middle tier, contains the core
logic and functionality of the application. It processes user requests, implements business
rules, performs computations, and coordinates the application's overall behavior. This tier acts
as an intermediary between the presentation tier and the data tier.

3. Data Tier:

The data tier, also known as the persistence tier or backend tier, is responsible for managing
data storage, retrieval, and manipulation. It stores the application's data in a structured format,
making it accessible to other tiers as needed. This tier ensures data integrity, security, and
efficiency in data operations.
5. Hybrid Architecture
 Combination of the above models.
 Example: P2P for resource sharing + client-server for control.
🔹 Architectural Concerns:
 Scalability – System’s ability to grow.
 Fault tolerance – System’s resilience to failure.
 Security – Authentication, encryption, access control.
 Transparency – Hiding complexity from users (e.g., location, access).

🔷 2. Fundamental Model in Distributed Systems

The fundamental model focuses on underlying issues in a distributed system such as
communication, failure, and security. It provides a formal basis to reason about system
behavior.
🔹 Purpose:
 To understand basic concepts and challenges in distributed environments.
 To analyze system behavior under failure, attack, or delay.
🔹 Types of Fundamental Models:
1. Interaction Model
 Describes communication behavior between components.
 Deals with latency, message loss, and clock synchronization.
Types:
 Synchronous Systems – Known bounds on processing, transmission, and clock drift.
 Asynchronous Systems – No assumptions on timing.
 Partially Synchronous – Assumptions hold only under certain conditions.
2. Failure Model
 Describes possible failure types and their effects on the system.
Types of Failures:
 Crash Failures – A component stops unexpectedly.
 Omission Failures – Message is lost (send/receive).
 Timing Failures – Message not delivered on time.
 Arbitrary (Byzantine) Failures – Incorrect or malicious behavior.
3. Security Model
 Describes threats and protection mechanisms.
Common Threats:
 Eavesdropping – Unauthorized data access.
 Masquerading – Pretending to be another process.
 Message Tampering – Altering messages.
 Denial of Service (DoS) – Blocking resources.
Security Mechanisms:
 Authentication – Verifying identity.
 Encryption – Protecting data confidentiality.
 Authorization – Access control.
 Integrity Checks – Ensuring data consistency.

Networking and Internetworking in Distributed Systems

🔷 1. Networking in Distributed Systems

✅ Definition:
Networking refers to the interconnection of multiple computing devices (nodes) that
communicate and coordinate through a shared communication medium to form a distributed
system.
✅ Purpose in Distributed Systems:
 To enable communication among distributed processes on different machines.
 To support resource sharing, coordination, data exchange, and remote invocation.
 Acts as the foundation for all operations in distributed computing.

🔹 Key Concepts in Networking:

1. Network Types:
 LAN (Local Area Network): Connects nodes in a small area (e.g., office, lab).
 MAN (Metropolitan Area Network): Spans a city or a large campus.
 WAN (Wide Area Network): Covers long distances, connecting cities or countries.
2. Communication Models:
  Unicast: One-to-one communication.
 Multicast: One-to-many (selected) communication.
 Broadcast: One-to-all nodes on a network.
 Anycast: One-to-one-of-many (chooses the nearest).
3. Communication Protocols:
 TCP (Transmission Control Protocol): Reliable, connection-oriented.
 UDP (User Datagram Protocol): Fast, connectionless, no guaranteed delivery.
 IP (Internet Protocol): Handles addressing and routing.
 HTTP/HTTPS: Used in web-based distributed applications.
4. Message Passing Mechanisms:
 Synchronous communication: Sender waits for the receiver to acknowledge.
 Asynchronous communication: Sender continues execution after sending the
message.
 Techniques include sockets, streams, message queues, and RPC.

🔹 Role of Networking in Distributed Systems:

 Provides the infrastructure for data transfer between processes on different
machines.
 Facilitates client-server and peer-to-peer communication.
 Supports remote invocation and event notification systems.
 Crucial for implementing transparency, fault tolerance, and scalability.

🔷 2. Internetworking in Distributed Systems

✅ Definition:
Internetworking is the process of connecting multiple different types of networks (LANs,
WANs, etc.) to form a single large logical network, often using the Internet.

🔹 Importance of Internetworking:
 Enables distributed systems to span across heterogeneous networks and platforms.
 Supports global communication and data sharing over the internet.
 Allows systems to scale beyond a single network boundary.
🔹 Key Components and Concepts:
1. Routers:
 Devices that forward data packets between different networks.
 Use IP addresses and routing tables to determine the best path.
2. Gateways:
 Act as bridges between networks using different protocols.
 For example, connecting a TCP/IP network with a Bluetooth or ZigBee network.
3. IP Addressing:
 Every device in an internetwork is assigned a unique IP address.
 Ensures correct delivery of messages across networks.
4. DNS (Domain Name System):
 Translates human-readable names (like www.google.com) into IP addresses.
 Supports accessibility in large-scale distributed systems.
5. NAT (Network Address Translation):
 Allows private IP addresses to access the public internet through a router.
 Supports address management and security.
6. Firewalls and VPNs:
 Firewalls control access and protect internal networks.
 VPNs allow secure remote access over public internets.

🔹 Internetworking Protocols:
 IP for addressing and routing.
 ICMP for diagnostics.
 BGP (Border Gateway Protocol) for routing between autonomous systems.
 ARP (Address Resolution Protocol) for resolving IP to MAC addresses.

🔎 Real-life Example:
A cloud-based email system like Gmail uses:
 Networking to connect your device to a local access point.
  Internetworking to route your email through multiple networks and data centers
spread across the world.

Interprocess Communication (IPC) in Distributed Systems

🔷 What is Interprocess Communication (IPC)?

In distributed systems, Interprocess Communication (IPC) refers to the methods and
mechanisms by which independent processes running on different machines coordinate,
share data, and communicate with each other. Since these processes do not share memory,
message passing becomes the primary mechanism of communication.

🔷 Why IPC is Essential in Distributed Systems?

 Enables processes on different systems to collaborate and share resources.
 Supports client-server interaction, remote method invocation, and distributed
transaction processing.
 Helps maintain consistency, synchronization, and data exchange between
processes.

✅ Key Characteristics of IPC in Distributed Systems

Feature Description

Unlike traditional systems, distributed processes use network-based

No shared memory
communication.

Location Processes communicate without needing to know each other's

transparency physical location.

Heterogeneity
IPC works across different platforms, OS, and hardware.
support

Fault tolerance IPC must handle failures in networks, systems, and processes.

🔷 Main IPC Mechanisms

1. Message Passing
 Basic form of IPC where processes send and receive messages.
 Implemented using sockets, pipes, or middleware.
 Can be:
 o Synchronous: Sender waits until the receiver gets the message.
o Asynchronous: Sender continues without waiting.
🔹 Example:
Socket.send("Hello")
Socket.receive("Hi there")

2. Sockets
 Provide a communication endpoint for sending/receiving data.
 Built on TCP/IP or UDP/IP protocols.
 Common in languages like Java, Python, C.
🔹 Types:
 Stream Sockets (TCP): Reliable, ordered, connection-based.
 Datagram Sockets (UDP): Faster, no guarantee of delivery/order.

3. Remote Procedure Call (RPC)

 Allows a program to call a procedure on a remote machine as if it were local.
 Handles the complexity of networking behind the scenes.
 Involves:
o Stubs: Local procedure that communicates with the remote procedure.
o Marshalling: Converts arguments into a transportable format.
o Unmarshalling: Converts received data back to usable format.
🔹 RPC Communication Steps:
1. Client calls stub (proxy function).
2. Stub marshals parameters and sends to server.
3. Server executes procedure.
4. Results sent back to client.

4. Remote Method Invocation (RMI)

 Java-specific implementation of RPC for object-based communication.
 Supports object-oriented features like inheritance, polymorphism remotely.
  Used in enterprise applications and Java EE.

5. Message Queues
 Use intermediate buffer queues to store messages temporarily.
 Messages can be retrieved asynchronously.
 Supports decoupling between sender and receiver.
 Useful in event-driven or microservice architectures.

🔷 Supporting Concepts in IPC

🔹 Marshalling and Unmarshalling
 Marshalling: Process of packing method parameters into a standard format for
transmission.
 Unmarshalling: Unpacking received data back into usable values.
🔹 Naming and Addressing
 Each process in a distributed system has a unique identifier (like IP:port).
 Naming services (e.g., DNS, directory services) help resolve process names to
addresses.
🔹 Binding
 Static Binding: Communication endpoints are fixed at compile time.
 Dynamic Binding: Resolved during runtime, more flexible.

🔷 Communication Patterns
Pattern Description Example

One-to-One (Unicast) One sender to one receiver RPC call

One-to-Many (Multicast) One sender to multiple receivers Event notification

One-to-All (Broadcast) Sent to all nodes Update propagation

Many-to-One Multiple senders to a single receiver Logging system

🔷 Challenges in IPC for Distributed Systems

1. Latency and Bandwidth Limitations
o Network delays may affect responsiveness.
 2. Partial Failures
o One part of the system may fail while others work.
3. Heterogeneity
o Involves different hardware, OS, and programming languages.
4. Security
o Requires authentication, encryption to protect communication.
5. Message Ordering
o Ensuring messages arrive in correct order (e.g., FIFO, causal ordering).

🔷 Real-World Examples of IPC in Distributed Systems

Mechanism Tool / Example Use Case

Client-server
Sockets Python Sockets / Java NIO
applications

RPC gRPC (Google), ONC-RPC Microservices

Distributed
RMI Java RMI Java
applications

Asynchronous
Messaging RabbitMQ, Kafka event
processing

Cloud and
REST APIs Web services mobile
backends

📘 Distributed Objects and Remote Invocation –

Introduction

🔷 What Are Distributed Objects?

A Distributed Object is an object that resides on a remote machine but can be accessed and
manipulated just like a local object through a defined interface. The object’s location, state,
and operations are abstracted from the client, enabling transparent interaction across a
distributed system.
🟦 Key Features:
  Can be located anywhere on a network.
 Communication is handled behind the scenes.
 Users/programs can invoke methods remotely.
 Encapsulate both data and behavior.
🟦 Examples:
 A bank account object located on a remote server.
 A shopping cart object in an e-commerce system.
 A remote file handler in a cloud storage system.

🔷 What Is Remote Invocation?

Remote Invocation refers to the process of calling a method or function on a distributed
object that resides on another computer in the network. It's the core mechanism that allows
client applications to interact with distributed objects.

🔷 Local vs Remote Invocation

Feature Local Invocation Remote Invocation

Location Same machine Different machines across the network

Communication method Direct function call Message passing via network protocols

Speed Fast Slower (network latency, serialization)

Failure handling Less complex Requires fault tolerance mechanisms

Transparency Fully transparent Partial – some aspects like delays are visible

✅ How Remote Invocation Works (Conceptual Steps)

1. Client makes a request to invoke a method on a remote object.
2. A stub (proxy) is used on the client side to forward the request.
3. The request is marshalled (converted into a transportable format).
4. The request travels over the network to the remote server.
5. On the server side, a skeleton receives the request.
6. The skeleton unmarshals the message and invokes the method on the actual object.
7. The response is sent back to the client in the same way.
🔷 Important Terms in Remote Invocation
Term Explanation

Stub A proxy on the client side that represents the remote object.

Server-side component that receives method calls and

Skeleton
interacts with the actual object.

Packing method arguments into a byte stream for network

Marshalling
transmission.

Converting received byte stream back into actual

Unmarshalling
arguments/values.

IDL (Interface Definition Used to define object interfaces in a language-neutral way (in
Language) CORBA, for example).

🔷 Types of Remote Invocation Mechanisms

1. Remote Procedure Call (RPC)
 Procedure-based interface (functions).
 No object-oriented features.
 Language-neutral (used in C/C++ systems).
 Stateless and simpler.
2. Remote Method Invocation (RMI)
 Object-based mechanism (Java-specific).
 Supports inheritance, interfaces, and polymorphism.
 Client can pass objects as parameters or receive objects.
3. CORBA (Common Object Request Broker Architecture)
 Standard by OMG.
 Language-independent and platform-independent.
 Uses IDL to define interfaces.

🔷 Goals and Benefits of Remote Invocation

 Transparency: User doesn't need to know where the object resides.
 Scalability: Services can be distributed across multiple nodes.
 Reusability: Remote objects can be accessed by different applications.
  Modularity: Clear separation between client and server logic.

🔷 Limitations and Challenges

Challenge Description

Latency Network delays make remote calls slower than local ones.

Partial failures Remote objects might crash, or network may fail.

Security issues Risk of data interception or unauthorized access.

Object references Passing references across machines is complex.

Versioning Keeping object interfaces consistent across updates.

🔷 Use Cases of Distributed Objects

 Banking systems: Remote account or transaction objects.
 Online retail systems: Remote inventory or shopping cart objects.
 Cloud storage: Remote file objects.
 Gaming: Multiplayer game state management through remote game objects.

📘 Topic: Communication Between Distributed Objects

🔷 Introduction
In a distributed system, objects are often located on different machines, and these objects
need to interact and communicate just like local objects do in object-oriented systems. This
communication, however, is more complex due to the network, platform, and language
boundaries.
Hence, communication between distributed objects enables method calls on remote objects
across networks, and is implemented using Remote Method Invocation (RMI), Remote
Procedure Calls (RPC), and object request brokers (like CORBA).

✅ Goals of Distributed Object Communication

 Allow an object on one machine to invoke methods on another object residing on a
different machine.
 Maintain abstraction — i.e., hide the complexity of network communication.
 Provide interoperability, scalability, and fault-tolerant communication.
🔷 Basic Architecture
🔹 The communication involves several key components:
Component Description

Client Object The object that initiates a remote method call.

Stub (Proxy) A local representative of the remote object; provides same interface.

Requestor Component responsible for sending invocation messages.

Server-side component that receives the request and invokes the actual
Skeleton
method.

Dispatcher Selects the correct method and invokes it on the server object.

Remote Object The target object located remotely.

🔷 Step-by-Step Communication Flow

1. Client makes a call to a method on the stub (proxy object).
2. The stub marshals the method call information (method name, parameters).
3. The marshalled data is sent over the network using a communication protocol.
4. On the server side, the skeleton receives the message, unmarshals it, and dispatches
it to the target remote object.
5. The method executes on the remote object.
6. The result is marshalled and sent back to the client.
7. The client stub receives and unmarshals the response, returning it to the caller.

🔷 Marshalling and Unmarshalling

 Marshalling: Converting method arguments into a byte stream suitable for network
transmission.
 Unmarshalling: Reconstructing the byte stream back into original data types.
This process is automatic in many frameworks (like Java RMI or CORBA), but must handle
complex data structures, object references, and versioning.

🔷 Types of Object Communication

1. Synchronous Communication
  Client waits for the server to respond.
 Easier to implement but can cause delays.
2. Asynchronous Communication
 Client sends a request and continues processing.
 More complex, used in event-driven or scalable systems.

🔷 Object Communication Models

Model Description Example

Request-Reply Client sends a request, waits for a reply Java RMI

Event-based Server sends notifications or updates JMS, Pub/Sub

Message Passing Message queues decouple senders and receivers RabbitMQ, Kafka

Object Migration Entire object moves between systems Agent-based systems

🔷 Common Technologies for Object Communication

Technology Description

Java RMI Java-to-Java object communication using interfaces and serialization.

Platform- and language-independent object communication using ORBs and

CORBA
IDL.

DCOM Microsoft's technology for distributed COM objects.

gRPC Google's modern, high-performance RPC framework using Protocol Buffers.

🔷 Challenges in Distributed Object Communication

Challenge Explanation

Network Latency Remote calls are slower than local method calls.

Partial Failures Either client or server may crash during communication.

Security Data must be protected during transmission (encryption, authentication).

Heterogeneity Differences in OS, languages, or hardware can cause incompatibilities.

Maintaining references to remote objects and managing garbage

Object References
collection.
🔷 Example: Java RMI Flow
1. Define Remote Interface with extends Remote.
2. Implement the Interface on the server side.
3. Create Stub and Skeleton using rmic tool.
4. Register remote object with RMI registry.
5. Client uses Naming.lookup() to get the stub.
6. Client calls the method as if it were local.

🔷 Use Cases of Distributed Object Communication

 Banking systems: Remote transaction processing.
 E-commerce: Product and order management across services.
 Gaming: Synchronization of player actions.
 Cloud platforms: Microservices invoking one another.

📘 Remote Procedure Call (RPC) in Distributed Systems

🔷 What is RPC?
Remote Procedure Call (RPC) is a powerful concept in distributed systems that allows a
program to execute a procedure (function) on a remote machine as if it were a local call.
The complexities of networking—like sending data over TCP/IP, message encoding, and
decoding—are hidden from the user.
📌 In Simple Words:
RPC lets you call a function on another computer as easily as calling one in your own code.

🔷 Why Use RPC?

 To simplify communication between processes on different machines.
 To abstract network operations like socket programming.
 To support client-server architectures easily.

✅ How RPC Works (Step-by-Step)

Let’s break down how an RPC is executed between a client and server:
1. Client Calls Procedure
The client calls a local stub (proxy for the remote function), passing parameters.
2. Client Stub Marshals Data
Stub converts parameters into a byte stream (called marshalling).
3. Client OS Sends Request
The OS sends the data over the network to the server.
4. Server Stub Unmarshals Request
On the server side, the stub unpacks the data (unmarshalling).
5. Server Executes Procedure
The actual procedure is called with the received parameters.
6. Server Sends Response
Results are sent back the same way (marshalled → sent → unmarshalled).
7. Client Receives Result
The result is passed to the calling program by the stub.

🔷 RPC Architecture
Here are the main components involved:
Component Description

Client Program that calls the remote function.

Client Stub Acts as a local interface, marshals the call and sends it.

Server Stub Unmarshals the request and invokes the actual function.

Transport Protocol Usually TCP or UDP, ensures message delivery.

Server Provides the actual implementation of the procedure.

🔷 Key Concepts in RPC

🟦 Marshalling / Unmarshalling
 Marshalling: Converts parameters to a standard format for transmission.
 Unmarshalling: Reconstructs the original data from the transmitted stream.
🟦 Binding
 Static Binding: Server is known at compile time.
  Dynamic Binding: Server is looked up at runtime (more flexible).
🟦 Transparency
 The idea is that the caller should not need to know if the procedure is remote or local.

🔷 Types of RPC
Type Description

Caller waits for the result

Synchronous RPC
(blocking call).

Caller continues execution (non-

Asynchronous RPC
blocking).

One-way RPC No result expected.

🔷 Advantages of RPC
 Simplicity: Easy to use and understand (like calling local functions).
 Modularity: Separation of client and server code.
 Abstraction: Hides low-level network details.
 Language Support: Widely supported in many programming languages.

🔷 Limitations of RPC
Issue Explanation

Latency Every remote call involves network overhead.

Partial Failures Server or network might fail independently of client.

Lack of Object RPC is procedural; does not support OOP features like
Orientation polymorphism.

Tight Coupling Both client and server must share the same interface (IDL).

🔷 Examples and Implementations of RPC

Implementation Description

ONC RPC (Open Network Computing

Used in Unix-like systems.
RPC)

Java RMI Java-based RPC with object support.

Implementation Description

High-performance RPC using HTTP/2 and

gRPC (by Google)
Protocol Buffers.

Text-based RPCs using XML/JSON over

XML-RPC / JSON-RPC
HTTP.

🔷 Use Case Example

Imagine a distributed banking system:
 The client app calls transferFunds(accountA, accountB, amount).
 This function is actually implemented on a remote server.
 RPC makes it possible to trigger this function over the network, receive the result,
and continue.

📘 Topic: Events and Notifications in Distributed Systems

🔷 What Are Events and Notifications?

In a distributed system, events represent significant state changes or actions (like file
updated, new user connected, data received), and notifications are messages or alerts sent to
interested parties (clients, services, or processes) to inform them that an event has occurred.
This mechanism supports decoupled, asynchronous communication between distributed
components.

✅ Why Are They Important?

 Enable real-time responsiveness to changes in the system.
 Allow components to react independently without tight coupling.
 Useful in scalable, event-driven, and service-based architectures.

🔷 Examples of Events in Distributed Systems

Event Type Example

File Event File created/modified in distributed storage.

Resource Event CPU/memory usage threshold crossed.

User Event A user logs in or out of a system.

Event Type Example

Message Event A message arrives in a queue.

Sensor Event Temperature exceeds threshold in IoT.

🔷 What Is a Notification?
A notification is a message sent to interested parties when an event occurs. It may include:
 Type of event.
 Timestamp.
 Source of the event.
 Relevant data or context.

🔷 Event-Notification Architecture
The Publisher-Subscriber Model is commonly used:
🧩 Components:
Component Role

Event Source (Publisher) Generates events.

Event Service (Middleware) Manages subscriptions and event delivery.

Event Listener (Subscriber) Receives notifications and handles them.

🔷 How It Works – Step by Step

1. Publisher generates an event (e.g., data updated).
2. Event Service identifies all subscribed listeners for that type of event.
3. Notification messages are sent to all listeners asynchronously.
4. Subscribers process the notification and perform necessary actions.

🔷 Types of Notifications
Type Description

Push Notification Server sends updates to clients.

Pull Notification Clients periodically check (poll) for updates.

Type Description

Broadcast Notification Notification is sent to all participants.

Multicast Notification Sent to a selected group of subscribers.

🔷 Models for Event Communication

1. Synchronous Notification
 The event source waits for acknowledgment from receivers.
 Simple, but blocks execution.
2. Asynchronous Notification
 Event is delivered and the publisher continues without waiting.
 Preferred in high-performance systems.

🔷 Use Cases
Use Case Event Notification

File Sync System File modified Notify clients to update

IoT System Sensor threshold crossed Send alert to dashboard

E-commerce New order placed Notify warehouse system

Distributed DB Data replicated Inform other nodes

🔷 Benefits
 Loose coupling between components.
 Improved scalability — new subscribers can join dynamically.
 Real-time responsiveness.
 Efficient resource usage — only react when needed.

🔷 Challenges
Challenge Description

Reliability Notification may be lost if the network fails.

Ordering Events may be received out of order.

Challenge Description

Duplicate Events Subscribers might receive the same notification multiple times.

Security Notifications can be intercepted or faked if not secured.

📘 Case Study: Java RMI in Distributed Systems

🔷 What is Java RMI?

Java Remote Method Invocation (RMI) is a Java-specific technology that allows an object
running in one Java Virtual Machine (JVM) to invoke methods on an object in another
JVM, possibly on a different physical machine.
Java RMI makes it possible for Java programs to communicate and invoke methods
remotely, just as if they were local method calls.

✅ Goals of Java RMI

 Enable object-oriented remote communication.
 Maintain the Java object model in a distributed environment.
 Allow distributed objects to be used transparently.

🔷 Components of Java RMI

Component Description

Remote Interface Declares the methods that can be invoked remotely.

Remote Object
Provides actual implementation of the remote interface.
(Implementation)

Stub Acts as a client-side proxy to invoke remote methods.

Server-side proxy that dispatches calls to the actual remote

Skeleton (pre-Java 1.2)
object.

RMI Registry A naming service to register and locate remote objects.

RMI Server Hosts the remote object and listens for remote invocations.

Looks up remote object in registry and invokes its

RMI Client
methods.
Java RMI Architecture

🔷 Java RMI Features

Feature Explanation

Object-Oriented Maintains full support for Java's object model.

Pass by Value/Reference Supports passing objects between JVMs.

Built-in Security Can use Java security manager and policies.

Garbage Collection Distributed garbage collection supported.

🔷 Advantages of Java RMI

 Pure Java-based, hence platform independent.
 Allows true object sharing across networks.
 Simplifies distributed application development.
 Supports polymorphism and object serialization.

🔷 Limitations of Java RMI

Limitation Reason

Cannot communicate with non-Java

Java-only
applications.

Tightly coupled Client and server must share interfaces.

Requires same version Class compatibility must be ensured.

Not suitable for web apps Not REST-friendly or firewall-friendly.

🔷 Real-World Use Cases of Java RMI

 Remote admin tools.
 Java-based banking or ERP software.
 File sharing services within Java apps.
 Legacy Java EE systems using distributed EJB components.