Communication Models in IoT
IoT enables people and devices to connect anytime, anywhere, with anything, through any network and service. There are four main communication models in IoT:
- Request & Response Model
- Publish–Subscribe Model (Pub–Sub)
- Push–Pull Model
- Exclusive Pair Model
REQUEST–RESPONSE MODEL
- Communication occurs between Client and Server.
- Client sends request to the server whenever required.
- Server processes the request, fetches data from its resources, prepares a response, and sends it to the client.
- This model is stateless – each request-response is independent.
- Example: HTTP (client browser sends HTTP request, server responds).
- Other Example: CoAP (Constrained Application Protocol).
PUBLISH–SUBSCRIBE MODEL
- Entities: Publisher, Broker, and Consumer.
- Publishers send messages to topics managed by the broker.
- Broker receives data from publishers and delivers it to all subscribed consumers.
- Consumers subscribe to specific topics from the broker.
- Publishers and consumers are not directly aware of each other.
- Examples: MQTT, AMQP, DDS.
PUSH–PULL MODEL
- Entities: Publisher, Queues, and Consumer.
- Publishers push messages into queues.
- Consumers pull messages from queues.
- Queues act as buffers when producer and consumer speeds do not match.
- Publishers and consumers are independent of each other.
EXCLUSIVE PAIR MODEL
- A bi-directional, full-duplex communication model.
- A dedicated connection is established between client and server.
- Both can send messages until the connection is closed.
- The model is stateful – connection details are maintained.
- Example: WebSockets.
IoT Communication APIs
An API is an interface for programs to interact with other applications. In IoT, APIs connect devices to the Internet or other network components.
REST-based API
- Follows Representational State Transfer (REST) principles.
- Uses URIs to represent resources (e.g.,
example.com/api/tasks). - Clients access resources via HTTP methods: GET, PUT, POST, DELETE.
- Communication uses JSON or XML payloads in requests and responses.
Advantages:
- Simple to design and implement.
- Flexible for various applications.
- Supports caching for performance.
- Stateless – scalable and distributable.
Disadvantages:
- No real-time communication.
- More overhead compared to WebSockets.
- Can be complex for large distributed systems.
WebSockets-based API
- Enables bi-directional and full-duplex communication.
- Based on Exclusive Pair Model – once connection is established, messages flow continuously until closed.
- No need to repeatedly open/close connections for each message.
Advantages:
- Real-time communication.
- More efficient for continuous updates.
- Scalable – supports many simultaneous connections.
- Lower overhead compared to REST APIs.
Disadvantages:
- More complex to implement.
- Needs strong security measures.
- Not supported by all browsers.
Refer