Overview till now

We will take forward from where we left in the previous Blog post, we have seen till now that HTTP protocol is quite good to handle for whether you want to send data or receive data, but what we could exactly see from the examples was that it was very short-lived, only till the request is not completed or failed. This short-liveliness of the connection, created a problem for small IOT devices. We will discuss it with an example,

Suppose we have a Nodemcu or Esp32, as a client device for a Home Automation system, controlling the relay to turn on/off lights, now how do I design the system, such that it can be operated from anywhere around the world through a mobile application, provided the Nodemcu has wifi connectivity all the time. If HTTP is used here, then the architecture would be like the following,

The architecture discussed above is also known as client side long polling, in which server just serves API to get or post data. This architecture works for sending and receiving data from anywhere, but is very inefficient as there are requests every n seconds, the server can get loaded up, the cost of using the servers will be too high, therefore it is not used in industry, but should be known.

Another architecture is based on server side long polling in which, the server keeps the request open until new data is available, which when is available sent as the response, and new request is generated. Image below explains the operation,

There are drawbacks with server side long polling as well, when is a long polling user connected or disconnected? If you check for this at a given moment of time... what would be the reliable amount of time you should wait to double check, to ensure it is disconnected or connected?, so presence is an important issue with long polling as the connection may get lost. Another drawback is they are non persistent, since a new connection is created each time.