Indirect Communication
Indirect communication: communication between entities in a
distributed system via an intermediary, with no direct
coupling between the sender and the receiver/s
Remote invocation is based on direct coupling between senders and
receivers, making systems rigid and difficult to change
indirect communication used when change is anticipated: e.g. mobile
environments with users coming and going
disadvantages:
performance overhead due to extra indirection
more difficult to manage due to lack of space/time coupling
Space and Time Uncoupling
space uncoupling: sender doesn’t know the identity of the
receiver/s
participants can be replaced, updated, replicated, migrated
time uncoupling: sender and receiver don’t need to exist
at the same time
useful in volatile environments where participants come and go
implies persistence in communication channel: messages must be stored
NB different to asynchronous communication: asynchronous comms don’t
imply that the receiver has an independent lifetime
Uncoupling Type Description Example Benefit
Sender doesn’t know
Space Uncoupling Publish-subscribe Decouples services
receiver(s)
Sender and receiver
Message queues Tolerates offline
Time Uncoupling don’t need to run
with storage components
simultaneously
Non-blocking send, Improves
Asynchronous
but receiver must be Non-blocking socket responsiveness, but
Only
active not persistence
Time-coupled Time-uncoupled
Direct Communication
Message Storing
Space coupling (message passing,
System
remote invocation)
Most indirect
communication
Space uncoupling Broadcast(IP multicast)
paradigms (Group
Communication)
group model
A group model in a distributed system provides a framework for how
processes communicate and collaborate as a unit.
Group Membership: Defining how processes join, leave, and are identified
within a group.
Communication: Specifying the mechanisms for sending and receiving
messages within the group, such as multicast or broadcast.
Ordering: Establishing how messages are delivered to group members
(e.g., FIFO, causal, or total order).
Fault Tolerance: Addressing how the group behaves when some members
fail.
Group Membership
Group communication systems
can be classified as either closed
or open.
Only members of the closed
group can send messages to the
group.
Users who are not group
members can send messages to
each member separately.
Non-members in the open group
can send messages to the group.
processes join, leave, and are identified within a
group.
Group communication
Group communication refers to sending messages to a set of
processes (a group) rather than just a single recipient.
space uncoupled service: sender doesn’t know receivers identities.
Multiplayer games, live chat, video streams
Types of Group Communication
Type Description
Broadcast Message is sent to all nodes in the system
Multicast Message is sent to a specific group of nodes
Message is sent to one member of a group (e.g., nearest
Anycast
or least busy)
Message sent to one specific node (not group comm, but
Unicast
for contrast)
FIFO Ordering
FIFO Ordering, also known as First-Come-First-Served, ensures that
messages sent from one process to another are received in the order they
were sent. This is akin to standing in line at a store; the first person in line
is the first to be served.
Example: Imagine two processes, P1 and P2. If P1 sends messages M1
and then M2 to P2, FIFO ordering guarantees that P2 will receive M1
before M2, regardless of the actual delivery times of the messages.
FIFO ordering does not guarantee any specific ordering between
messages from different sources. For instance, if another process P3
sends messages M3 and M4 to P2, P2 might receive these in any order
relative to M1 and M2.
Causal Ordering
Causal Ordering is more complex and caters to the causal
relationships between events. It ensures that if one message
causally influences another, the influenced message should not be
processed before the influencing message.
Example: Continuing from the previous example, suppose M1 sent
from P1 to P2 triggers P2 to send message M2 to P3. Causal
ordering ensures that P3 does not process M2 before processing
M1, maintaining the causality of the events.
Total ordering
All messages are delivered to all participants in the exact same
order, no matter who sent them.
Every process sees the same global order of messages.
If m1, m2, m3 are sent by different processes, everyone might
see:
Process 1: m1, m2, m3
Process 2: m1, m2, m3
Process 3: m1, m2, m3
Publish Subscribe Model
In this model, publishers produce messages that are then
consumed by subscribers. Key points of the Pub/Sub model include:
Publishers: Entities that generate and send messages.
Subscribers: Entities that receive and consume messages.
Topics: Channels or categories to which messages are published.
Message Brokers: Intermediaries that manage the routing of
messages between publishers and subscribers.
Publisher
The Publisher is responsible for creating and
sending messages to the Pub/Sub system.
Publishers categorize messages into topics or
channels based on their content.
They do not need to know the identity of the
subscribers.
Subscriber
The Subscriber is a recipient of messages in the
Pub/Sub system. Subscribers express interest in
receiving messages from specific topics.
They do not need to know the identity of the
publishers. Subscribers receive messages from
topics to which they are subscribed.
Topic
A Topic is a named channel or category to which messages are
published.
Publishers send messages to specific topics, and subscribers
can subscribe to one or more topics to receive messages of
interest.
Topics help categorize messages and enable targeted
message delivery to interested subscribers.
Message Broker
The Message Broker is an intermediary component that
manages the routing of messages between publishers and
subscribers.
It receives messages from publishers and forwards them to
subscribers based on their subscriptions.
The Message Broker ensures that messages are delivered to
the correct subscribers and can provide additional features
such as message persistence, scalability, and reliability.
Message
A Message is the unit of data exchanged between
publishers and subscribers in the Pub/Sub system.
Messages can contain any type of data, such as
text, JSON, or binary data.
Publishers create messages and send them to the
Pub/Sub system, and subscribers receive and
process these messages.
Subscription
A Subscription represents a connection between a subscriber
and a topic.
Subscriptions define which messages a subscriber will receive
based on the topics to which it is subscribed.
Subscriptions can have different configurations, such as
message delivery guarantees (e.g., at-most-once, at-least-
once) and acknowledgment mechanisms.
A real-life example of Pub/Sub architecture can be seen in the
operation of a social media platform like Twitter.
Message queues
Message Producer: Messages are created and sent to the message
queue by the message producer. Any program or part of a system
that produces data for sharing can be considered this.
Message Queue: Until the message consumers consume them, the
messages are stored and managed by a data structure or service
called the message queue. It serves as a mediator or buffer
between consumers and producers.
Message Consumer: Messages in the message queue must be
retrieved and processed by the message consumer.
Messages from the queue can be read concurrently by several
users.
Message Broker (Optional): In some message queue systems, a
message broker acts as an intermediary between producers and
consumers, providing additional functionality like message routing,
filtering, and message transformation.
A simple example of a message queue is an email inbox. When you
send an email, it is placed in the recipient's inbox.
The recipient can then read the email at their convenience.
This email inbox acts as a buffer between the sender and the
recipient, decoupling them from each other.
How Message Queues Work?
Step 1: Sending Messages: The message producer creates a
message and sends it to the message queue. The message
typically contains data or instructions that need to be processed or
communicated.
Step 2: Queuing Messages: The message queue stores the
message temporarily, making available for one or more consumers.
Messages are typically stored in a first-in, first out (FIFO) order.
Step 3: Consuming Messages: Message consumers retrieve
messages from the queue when they are ready to process them.
They can do this at their own pace, which enables asynchronous
communication.
Step 4: Acknowledgment (Optional): In some message queue
systems, consumers can send acknowledgments back to the
queue, indicating that they have successfully processed a
message. This is essential for ensuring message delivery and
preventing message loss.
