Internet of Things Communication Models (IoT)

Learn the Internet of Things communication models (IoT) such as Client-Server, Publisher-Subscriber, Push-Pull, and Exclusive Pair.

Contents

When you are using the Internet of Things (IoT), the very first reason why we use it is communication speed for data transfer. This is because seamless data transfer at high speeds is essential for getting and passing data between every system.

Then only, the operator can control a plant sitting in any corner of the world. For this, it is required that the operator needs to know how communication rules work in IoT.

In the language of IoT, they are called as communication models. The user must understand how communication happens in IoT before using the actual system.

Internet of Things Communication Models

In this post, we will see the types of communication models used in IoT.

Client – Server (Request – Response)

As the name defines, the two parties here are defined as client and server. In the Client-Server model, a client is the one who requests data from the server. Once the request is received by the server, it will process it and accordingly respond by sharing data with the client. The response from the server is then received by the client.

This is the most used type of communication model that exists in even basic automation levels like PLC. A PLC will be the client that requests data from a VFD for frequency data. The VFD will be the server in this case, as it has the data and just needs to pass it to anyone who requests it.

Once the VFD responds by sharing data with the PLC, the PLC will then process it and use its logic accordingly. In this mode, as we have understood, both parties know each other’s identities because they deal separately between them.

Publisher – Subscriber

This is a more advanced type of model used in IoT. Consider a YouTube channel. The video publisher has published the video on YouTube but does not know which users have subscribed to the channel. The channel is just distributing video to YouTube and in return, YouTube allows the user to subscribe to the channel. This is a simple example of a publisher-subscriber model.

In this, the publisher distributes data and there is a broker in between which handles this data. The broker will provide data to the users who demand it. The users here are termed as subscribers. The publisher does not know who is the subscriber. It has just passed data and the broker has distributed it to subscribers.

It enables data exchange between various components of a system without the components being aware of each other’s identity. What matters to them is data. So, this model is widely used for distribution-type systems like sending notifications to users, working with multiple data sources, broadcasting, etc.

Push – Pull

This model is similar to the publisher-subscriber model. Let us see this model by extending the same discussed earlier. The publisher here is the pusher and the subscriber here is the puller. The publisher will push the data and the subscriber will pull the data. The main difference is that of the intermediate handling.

In the earlier case where the broker was the system, here a queue system is used in between. The queue will take pushed data and simply pass the data to consumers who are pulling it. It is a distributed one too, but limited in terms of distribution networks and speed.

The push-pull model works linearly and controls the rate of data transfer whenever the push or pull speed varies. This queue is that thing which is majorly responsible for handling data between pushers and pullers.

Exclusive Pair

This is an extension of the client-server model or response request model. As opposed to the previous one where the response was given based on request, the model here is fully open. It means the communication is full duplex.

Both the client and server open their connections and data exchange happens continuously. It ends when the client closes the connection and the server has to accept it.

This means that once the request has been sent initially and the response has been sent, the connection becomes open and then there is no need to send requests. The server keeps a record of what data has been exchanged.

If you liked this article, then please subscribe to our YouTube Channel for Instrumentation, Electrical, PLC, and SCADA video tutorials.

You can also follow us on Facebook and Twitter to receive daily updates.

Read Next: