This post has been “upgraded” to a page where updates will take place – IoT Device – Client or Server?.
You are planning an IoT Device. Now, is it implemented as a server or a client? 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 (PC’s, phones etc). These are not shown in the figure.
Data flows from the IoT-devices to the cloud-server, where clients may fetch it. 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.
- If the IoT-device is behind a NAT, it will be difficult for it to act as a server. The NAT must be configured for this, unless special “hole-punching” techniques are used. When the IoT-devices are clients, the problem is avoided.
- You can save battery, if the IoT-device is allowed to sleep most of the time. It is easy to wake it up with a local signal/timer. We do see “Wake-on-Wireless” technologies, but this will typically still require 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. You may argue that this is not very “connected” – so not IoT at all. However, the device may be a router to smaller IoT-devices.
- When using REST web-services 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 may easily flow in the opposite direction. See description below.
- MQTT brokers have a server-role. CoAP sensors act like servers.
The pattern
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 physically 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 (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 PC’s. 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.