Publish-subscribe architecture in IOT Protocols - Full Explanation

Introduction

Imagine trying to share news with many friends without calling each one individually. The publish-subscribe architecture solves this by letting senders and receivers communicate through a middleman, making message sharing easier and more flexible.

Explanation

Publishers

Publishers are the sources that create and send messages. They do not need to know who will receive the messages or how many will get them. Their job is simply to publish information to a common channel.

Publishers send messages without needing to know the receivers.

Subscribers

Subscribers express interest in certain types of messages by subscribing to specific topics. They receive only the messages that match their interests, without knowing who sent them. This allows them to get relevant updates easily.

Subscribers receive messages based on their chosen topics.

Broker

The broker acts as a middleman between publishers and subscribers. It receives messages from publishers and forwards them to the right subscribers based on the topics. This central role simplifies communication and manages message delivery.

The broker routes messages from publishers to the correct subscribers.

Topics

Topics are named channels or categories that organize messages. Publishers send messages to topics, and subscribers listen to topics they care about. This system keeps messages organized and targeted.

Topics organize messages so subscribers get only what they want.

Real World Analogy

Think of a magazine publisher who prints different magazines on various subjects. Readers subscribe to the magazines they like, and the publisher sends each magazine only to those readers. The post office acts like the broker, delivering the right magazines to the right subscribers.

Publishers → Magazine publisher printing magazines

Subscribers → Readers subscribing to specific magazines

Broker → Post office delivering magazines to readers

Topics → Different magazine subjects or categories

Diagram

Diagram

┌────────────┐       ┌─────────┐       ┌─────────────┐
│ Publisher 1│──────▶│         │       │ Subscriber 1│
└────────────┘       │         │       └─────────────┘
                     │ Broker  │──────▶
┌────────────┐       │         │       ┌─────────────┐
│ Publisher 2│──────▶│         │       │ Subscriber 2│
└────────────┘       └─────────┘       └─────────────┘

Topics: Weather, News, Sports

This diagram shows publishers sending messages to a broker, which then forwards them to subscribers based on topics.

Key Facts

Publisher → A component that sends messages to a topic without knowing the receivers.

Subscriber → A component that receives messages by subscribing to specific topics.

Broker → A server that routes messages from publishers to subscribers based on topics.

Topic → A named channel that organizes messages for selective delivery.

Decoupling → Publish-subscribe architecture separates senders and receivers so they do not depend on each other.

Common Confusions

Publishers must know who the subscribers are.

Publishers must know who the subscribers are. Publishers send messages to topics without knowing or managing subscribers; the broker handles delivery.

Subscribers receive all messages from all publishers.

Subscribers receive all messages from all publishers. Subscribers only receive messages from topics they subscribe to, not all messages.

The broker stores messages permanently.

The broker stores messages permanently. Most brokers forward messages immediately and do not store them permanently unless configured for persistence.

Summary

Publish-subscribe architecture uses a broker to connect message senders (publishers) and receivers (subscribers) without direct links.

Messages are organized by topics, allowing subscribers to receive only what interests them.

This design simplifies communication and supports flexible, scalable message distribution.

Practice

1. What is the main role of a broker in a publish-subscribe architecture?

easy

A. To receive messages from publishers and forward them to subscribers

B. To directly connect publishers and subscribers

C. To store all messages permanently

D. To encrypt messages between devices

Solution

1. Step 1: Understand the broker's function

   The broker acts as a middleman that receives messages from publishers.

2. Step 2: Identify message forwarding role

   The broker forwards these messages to subscribers interested in specific topics.

3. Final Answer:

   To receive messages from publishers and forward them to subscribers -> Option A

4. Quick Check:

   Broker forwards messages [OK]

Hint: Broker forwards messages, it doesn't connect devices directly [OK]

Common Mistakes:

• Thinking broker connects devices directly
• Assuming broker stores messages permanently
• Confusing broker with encryption service

2. Which of the following is the correct way to describe a topic in publish-subscribe?

easy

A. A label used to organize messages for subscribers

B. A direct connection between two devices

C. A security protocol for message encryption

D. A device that publishes messages

Solution

1. Step 1: Define what a topic is

   A topic is a label or category that organizes messages so subscribers receive only relevant ones.

2. Step 2: Eliminate incorrect options

   Topics are not connections, security protocols, or devices.

3. Final Answer:

   A label used to organize messages for subscribers -> Option A

4. Quick Check:

   Topic organizes messages [OK]

Hint: Topics organize messages, not devices or connections [OK]

Common Mistakes:

• Confusing topics with device connections
• Thinking topics are security features
• Mixing up topics with publishers

3. Given this scenario: A device publishes messages to topic home/temperature. Which device will receive the messages?

medium

A. All devices on the network

B. Any device subscribed to home/humidity

C. Any device subscribed to home/temperature

D. Only the publishing device

Solution

1. Step 1: Identify the topic published to

   The device publishes to home/temperature.

2. Step 2: Determine which subscribers get the message

   Only devices subscribed to home/temperature receive the messages.

3. Final Answer:

   Any device subscribed to home/temperature -> Option C

4. Quick Check:

   Subscribers to topic get messages [OK]

Hint: Subscribers to the exact topic get messages [OK]

Common Mistakes:

• Assuming all devices get messages
• Thinking publishing device receives its own messages
• Confusing similar topic names

4. A subscriber is not receiving messages from the broker. Which of these is a likely cause?

medium

A. Publisher is sending messages to the subscriber directly

B. Subscriber is publishing messages instead of subscribing

C. Broker is encrypting messages incorrectly

D. Subscriber is not subscribed to the correct topic

Solution

1. Step 1: Check subscription correctness

   If the subscriber is not subscribed to the right topic, it won't get messages.

2. Step 2: Rule out other causes

   Publishers don't send messages directly; encryption issues or wrong roles are less common causes here.

3. Final Answer:

   Subscriber is not subscribed to the correct topic -> Option D

4. Quick Check:

   Correct topic subscription needed [OK]

Hint: Check subscriber's topic subscription first [OK]

Common Mistakes:

• Thinking publisher sends messages directly
• Blaming encryption without evidence
• Confusing subscriber and publisher roles

5. In a large IoT system using publish-subscribe, how can you ensure that only devices in the 'factory/floor1' area receive temperature alerts without affecting others?

hard

A. Publish all alerts to factory/temperature and let devices filter messages locally

B. Publish temperature alerts to topic factory/floor1/temperature and have devices subscribe to it

C. Send alerts directly to each device's IP address

D. Use a single topic temperature for all devices

Solution

1. Step 1: Use topic hierarchy for targeted messaging

   Publishing to factory/floor1/temperature targets only devices subscribed to that specific area.

2. Step 2: Avoid broad topics or direct device addressing

   Broad topics or direct IP messaging reduce scalability and flexibility.

3. Final Answer:

   Publish temperature alerts to topic factory/floor1/temperature and have devices subscribe to it -> Option B

4. Quick Check:

   Use specific topics for targeted delivery [OK]

Hint: Use detailed topic paths for precise message delivery [OK]

Common Mistakes:

• Using broad topics causing unwanted message delivery
• Trying direct device IP messaging in pub-sub
• Ignoring topic hierarchy benefits