Client-server vs publish-subscribe models in IOT Protocols - Performance Comparison
We want to understand how the work done by IoT communication models grows as more devices join.
Which model handles more devices efficiently as the network grows?
Analyze the message handling in client-server and publish-subscribe models.
// Client-server model
for each client in clients:
server.receive(client.message)
server.send(client.response)
// Publish-subscribe model
for each message in topics:
for each subscriber in message.subscribers:
broker.forward(message, subscriber)
This code shows how messages are processed in each model: client-server handles each client directly, publish-subscribe forwards messages to all subscribers.
- Primary operation: In client-server, server processes each client once.
- How many times: Once per client (n times).
- Primary operation: In publish-subscribe, broker forwards each message to all subscribers.
- How many times: For each message, to all subscribers (n x m times).
As devices increase, work grows differently:
| Input Size (clients or subscribers) | Client-Server Operations | Publish-Subscribe Operations |
|---|---|---|
| 10 | 10 | 100 (10 messages x 10 subscribers) |
| 100 | 100 | 10,000 (100 x 100) |
| 1000 | 1000 | 1,000,000 (1000 x 1000) |
Client-server grows linearly with clients. Publish-subscribe grows much faster because it sends to all subscribers for each message.
Time Complexity: O(n) for client-server, O(n x m) for publish-subscribe
This means client-server work grows directly with number of clients, while publish-subscribe grows with both messages and subscribers.
[X] Wrong: "Publish-subscribe always handles messages as fast as client-server because it uses a broker."
[OK] Correct: The broker must forward each message to every subscriber, which can multiply work a lot as subscribers grow.
Understanding how these models scale helps you explain system choices clearly and shows you think about real-world device growth.
"What if the publish-subscribe model used topic filters to reduce subscribers per message? How would that affect time complexity?"
Practice
Solution
Step 1: Understand client-server communication
In client-server, one device (client) sends a request and another (server) replies directly.Step 2: Compare with other models
Publish-subscribe uses a shared space, not direct requests and replies.Final Answer:
One device requests data, and another device responds directly. -> Option AQuick Check:
Client-server = direct request-response [OK]
- Confusing publish-subscribe with client-server
- Thinking client-server allows many-to-many messaging
- Assuming client-server has no direct responses
Solution
Step 1: Identify publish-subscribe key elements
Publish-subscribe uses a broker where devices publish messages and subscribers receive them.Step 2: Eliminate incorrect options
Client-server uses direct request-response between devices, direct connections have no intermediaries, and server-only broadcasts lack subscriber reception.Final Answer:
Devices publish messages to a broker; subscribers receive messages. -> Option CQuick Check:
Publish-subscribe = publish to broker, subscribe to messages [OK]
- Mixing client-server request-response with publish-subscribe
- Ignoring the broker role in publish-subscribe
- Assuming direct device-to-device messaging in publish-subscribe
Solution
Step 1: Analyze the scenario
The sensor publishes data to a broker, and multiple devices subscribe to receive it.Step 2: Match scenario to model
This matches the publish-subscribe model where publishers send messages to a broker and subscribers receive them.Final Answer:
Publish-subscribe -> Option AQuick Check:
Publishing to broker with multiple subscribers = publish-subscribe [OK]
- Choosing client-server for many-to-many communication
- Confusing broadcast with publish-subscribe
- Ignoring the broker role
Solution
Step 1: Identify the error in the statement
The statement describes publish-subscribe behavior but calls it client-server.Step 2: Clarify client-server model
Client-server uses direct requests and responses without a broker.Final Answer:
Client-server does not use a broker for message distribution. -> Option DQuick Check:
Broker use = publish-subscribe, not client-server [OK]
- Mixing up client-server and publish-subscribe roles
- Assuming client-server uses brokers
- Thinking client-server is many-to-many
Solution
Step 1: Analyze system requirements
The system needs many sensors sending data to many monitors, with dynamic device changes.Step 2: Match requirements to models
Publish-subscribe supports many-to-many messaging and dynamic subscribers via a broker.Step 3: Eliminate other options
Client-server is one-to-one, peer-to-peer lacks central management, broadcast sends to all without filtering.Final Answer:
Publish-subscribe, because it allows many-to-many communication via a broker. -> Option BQuick Check:
Dynamic many-to-many = publish-subscribe [OK]
- Choosing client-server for many-to-many needs
- Ignoring dynamic device management
- Confusing broadcast with publish-subscribe
Ready to prove it?
Pass the test and this pattern moves unknown
