You are planning an IoT Device. Now, is it implemented as a client or server? In many cases the device can take on both roles, but one will be dominant. This is an important design decision that should be taken early.
The device as client
Reasons/advantages are:
- A typical system has a cloud-server with many clients (PCs, smartphones etc). These are not shown in the figure.
Data flows from the IoT-devices to the cloud-server, where clients may fetch it (often aggregated or pre-analysed). If the IoT-devices are also clients to the cloud-server, the cloud-server remains a server, no-matter whether it is in contact with a desktop PC or a device. This makes the cloud-server simpler. The arrows in the figure go from client to server. It is the client that initiates the contact, thus deciding when and what. - All IoT-devices can use the standard URL of the cloud-server in the above scenario. Alternatively they can use it’s static IP-address. Servers are not likely to change IP-address.
- If the IoT-device is behind a NAT, it is difficult for it to act as a server. The NAT must be configured for this, unless special “hole-punching” techniques are used. By maintaining the IoT-devices as clients, the problem is avoided.
- You save battery if the IoT-device sleeps most of the time. This does not go well with the server-role. It is easy to wake up a device with a local signal/timer. We do see “Wake-on-Wireless” technologies, but this typically still requires more power, as the radio-receiver must be on.
- Some network-technologies, like Sigfox, are designed so that the they simply send the signal without handshake and go to sleep again. Not easy to reverse.
- Some devices are constantly on the move – e.g. “asset tracking” devices. They may at times be without radio contact. Thus it is better that they contact the server when they can.
When using e.g. MQTT the sensors/devices publish and subscribe data to each other. Thus they have both a server and client role. The sensors however, normally start by opening an “eternal” TCP to the “broker”. In this way they are technically always TCP-clients.
The device as server
- In some scenarios, e.g. configuration, you only have the IoT-device and a local PC or a phone. It is not always easy to get a server running on a normal PC. There may be a firewall, antivirus and other obstacles. In these scenarios, it is easier to have the server in the IoT-device. For basic setup, a 1:1 connection with a PC/phone/pad is very practical. Just think about Google’s Chromecast. For the initial setup you connect e.g. a phone to the Chromecast’s SSID. Thus the Chromecast is server. Now you tell it about the household SSID and the password to this. It reboots and is now a client on your home WiFi.
- When using REST web-services (see also my IoT book Embedded Software for the IoT) to get data out of the device, you see the device as a path to several resources, each with their own URL. This could be several different sensors on a single device. Alternatively, the IoT-Device is capable of doing local processing that must be controlled, and it makes sense to see it as a server. REST is often implemented via a web-server inside the IoT-device. The arrows in the figure go from the client to the IoT-Servers, defining who actively takes control. Data typically flow in the opposite direction. See description below.
- MQTT brokers have a server-role. CoAP sensors act like servers.
The overall pattern for an IoT Device – Client or Server
The smallest devices used for e.g. asset tracking or simple sensors emitting a single, rare value now & then are almost always clients.
“Aggregating devices” often act as servers. These devices may be physical boxes/gateways harvesting data from many smaller, separate devices. Alternatively, they may be more advanced equipment, directly giving access to many kinds of information. Based on already delivered data, some remote client decides what it wants to see next, or maybe even which local processing must be performed on the device (think e.g. Industry 4.0).
To keep the cloud-server as a “clean” server, this design may involve a central device that has the role of client towards the IoT-devices, extracting relevant data. This client then delivers the data to the cloud-web-server. This client could run on the same PC as the cloud-server. However, considering server parks etc. this “extractor-client” probably runs on one or several separate PCs. Thus it actively controls the IoT-servers that deliver the data, and hands these over to the big cloud-server.
By keeping the cloud-server as a clean server in both scenarios, it is not a problem to mix the two kinds.