IoT Communication Models: Request-Response, Pub-Sub, Push-Pull, and Exclusive Pair
Introduction: How Do IoT Devices Talk to Each Other?
In an IoT system, thousands of smart devices need to exchange data with cloud servers, mobile apps, and control systems.
Because different IoT tasks have different needs — some need fast live updates while others need to save battery — designers use Four Core Communication Models:
The Four IoT Communication Models
1. Request - Response
Client asks for data; server answers and closes the connection. Simple and stateless.
2. Publish - Subscribe
Publishers send data to a Topic on a Broker; Subscribers automatically receive it.
3. Push - Pull
Producers push messages into a Queue; Consumers pull and process them at their own speed.
4. Exclusive Pair
A persistent, two-way (full-duplex) open channel between two devices.
1. Request - Response Model
- How it Works: The client sends an explicit request packet to the server. The server reads the request, finds or computes the data, and sends back an acknowledgment or reply.
- Key Points:
- Stateless: Each request is completely independent. The server does not remember past requests.
- Client-Driven: Only the client can initiate communication. The server cannot send data until asked.
- Protocols Used: HTTP / HTTPS, standard REST APIs.
- Real-Life Example: You open a weather app on your mobile. The app sends
GET /temperatureto the weather station server, and the server replies with200 OK: {"temp": "32°C"}.
2. Publish - Subscribe (Pub-Sub) Model
The Publish-Subscribe model is the most widely used pattern in modern IoT because devices do not need to know each other directly:
- Publishers: Devices that produce data (e.g., a temperature sensor). They simply publish data to a named category called a Topic (e.g.
home/living_room/temp). They do not know who is reading the data! - Subscribers: Apps or devices that want the data (e.g., your smartphone app or AC controller). They subscribe to that topic.
- Broker: The central server that sits in the middle. It takes incoming messages from publishers and automatically forwards them to all subscribers of that topic.
Publish-Subscribe Architecture (MQTT Pattern)
Publisher (Sensor)
Publishes to Topic:
Publishes to Topic:
home/temp➔ Central Broker (Server)
Routes message to subscribers ➔
Routes message to subscribers ➔
Subscribers
AC Unit & Phone App
AC Unit & Phone App
- Why is Pub-Sub Great for IoT?
- Decoupled: If the temperature sensor’s battery dies, your phone app does not crash — it just waits for the next message.
- High Scalability: One sensor reading can be sent to 10,000 users at the same time through the broker.
- Protocols Used: MQTT, AMQP, XMPP.
3. Push - Pull Model
- How it Works:
- Devices that generate data (Producers) push messages into a central Message Queue (FIFO Buffer).
- Worker servers (Consumers) pull messages from the queue one by one and process them.
- Why Use Queues? (Time Decoupling):
- Suppose a cloud analytics server becomes slow or restarts for maintenance. Sensors can keep pushing their readings into the queue.
- No data is lost! When the server wakes back up, it pulls all waiting messages from the queue and catches up.
- Technologies Used: RabbitMQ, Apache Kafka, Amazon SQS.
4. Exclusive Pair Model
- How it Works:
- A client connects to the server and sets up a dedicated, persistent channel.
- The connection stays open continuously until one side decides to close it.
- Both client and server can send messages to each other at the exact same time (Full-Duplex).
- Key Points:
- Minimal overhead because there is no need to repeat connection handshakes.
- Low latency (instant data transfer).
- Protocols Used: WebSockets.
- Real-Life Example: Controlling a drone in real time — the remote controller sends joystick steering commands while the drone simultaneously streams live camera video back over the exact same open connection.
5. Summary Comparison Table
| Model | How it Works | Decoupling | Common Protocols | Best Used For |
|---|---|---|---|---|
| Request - Response | Client asks; Server answers | Low (tightly coupled) | HTTP / REST | Checking account balance, changing settings |
| Publish - Subscribe | Messages sent to Topics via a central Broker | High (space & time) | MQTT, AMQP | Battery-powered sensors, smart homes, notifications |
| Push - Pull | Messages stored in a FIFO Queue | High (time buffer) | RabbitMQ, Kafka | Big data pipelines, traffic log processing |
| Exclusive Pair | Permanent open two-way channel | Low (tightly connected) | WebSockets | Live drone control, real-time gaming, audio/video feeds |
💡 DAVV Exam Preparation Tips
5-Mark Question: “Explain the Publish-Subscribe (Pub-Sub) communication model with a neat diagram. Mention the roles of Publisher, Subscriber, and Broker.”
- Definition: A messaging pattern where data producers (publishers) and consumers (subscribers) do not talk directly; they communicate through a central server called a Broker.
- 3 Roles:
- Publisher: Generates data and sends it to a Topic.
- Broker: Central server that routes messages to matching subscribers.
- Subscriber: Receives updates on topics it subscribed to.
- Draw the flow diagram: Publisher ➔ Broker ➔ Subscribers.
- Mention that MQTT is the most popular Pub-Sub protocol in IoT.
10-Mark Question: “Describe the four fundamental IoT communication models: Request-Response, Publish-Subscribe, Push-Pull, and Exclusive Pair. Compare them across decoupling, overhead, and practical IoT use cases.”
- Explain all 4 models step-by-step with simple examples.
- Highlight why Publish-Subscribe is ideal for battery-operated IoT sensors (saves power, decouples sender and receiver).
- Explain Push-Pull with message queues (Kafka / RabbitMQ) for batch buffering.
- Draw the 5-column comparison table cleanly.