Embedding a web server in a product is a remarkably powerful mechanism for easily implementing a variety of key features and functions in your device. One of the greatest benefits of an embedded web server is that it resides in the equipment itself and not as a separate software that needs to be installed on a computer. A user can simply use a browser and navigate to the IP address or domain name given to access key features in the product.
In this article, we look into a few use cases where embedding a web server in a product is not the optimal solution, but where a hybrid IoT solution creates a much better user experience.
Products powered by small microcontrollers, such as ARM Cortex M4, that mandate the use of secure HTTPS web servers are problematic since modern web browsers may attempt to pre-allocate as many as 12 connections before sending the first GET request. Each connection requires its own time consuming TLS handshake.
To fully understand the problem with using HTTPS in microcontrollers, we recommend reading the article "Creating Applications with the Secure Minnow Server", section Why use WebSockets for Device Management.
Devices and other products with an embedded web server normally operate on private networks such as Intranets. Private networks are not directly accessible via the Internet and are shielded from external Internet access by a firewall/router. For example, even the most basic home router shields any type of server solution from external Internet access.
In many cases, preventing external access is beneficial since the embedded web server is protected from potentially malicious external users. However, it creates a major problem if the product with the embedded web server needs to be operated from another network via the Internet. This type of remote access could be anything from remote management and supervision to updating the device firmware.
External access to one web server on a private network is technically possible by opening a pinhole in the firewall. In computer networking, a firewall pinhole is a port that is not protected by a firewall to allow a particular application to gain access to a service on a host in the network protected by the firewall.
How to set up a firewall pinhole depends on the firewall product being used. However, regardless of firewall type, setting up a pinhole such as port forwarding is generally complicated and requires extensive network experience. Unless your customers are very tech savvy, setting up port forwarding will be near to impossible for them to configure. Customers deploying your products in corporate environments may have IT personnel with the required expertise, but corporate environments typically ban the use of pinholes.
For all practical purposes, accessing a private web server from another network is not practical and we should look into alternative solutions that provide an as-close-to-embedded-web-server-as-possible solution that works over the Internet.
Although firewalls block all external access by default, virtually all networks allow products to connect out to services on the Internet (Figure 4). Instead of embedding a web server and waiting for incoming connections, a product can instead connect to a service on the Internet that acts as a proxy for all connected clients, including the users using a browser.
Although the solution depicted in Figure 4 can be designed from scratch or partly assembled using a number of open source products, we provide a complete ready to use secure solution called SMQ. One of the things we strive to do at Real Time Logic is to simplify security. The SMQ protocol makes it easy for you to include a multilayered defense system as outlined in the DZone article Have We Forgotten the Ancient Lessons About Building Defense Systems?.
In Figure 4, we show the virtual connection between the user and the device. The real communication path is via the online server; however, as a computer programmer, you do not have to think about it this way. You set up a one-to-one communication between the SPA running in the browser and the device. The one-to-one communication is referred to as the virtual connection in Figure 4. An SPA may be designed to manage one virtual connection as shown in Figure 4 or an SPA can also be designed to manage any number of virtual connections. In other words, an SPA can be designed to manage any number of devices simultaneously.
Unlike many IoT solution providers, SMQ does not constrain your server deployment options. You may deploy the server on one low cost virtual private server as shown in Figure 4, or you may choose to use a cloud server solution. The following figure depicts an SMQ cluster solution deployed on a cloud solution using two online servers.
To learn more about how to use SMQ for remote device management, we recommend the following:
SMQ does not exclude the use of an embedded web server. In fact, the same embedded web server's HTML web application can be re-used by the SMQ solution if the HTML web application is designed as a Single Page Application (SPA). For details on this design technique and how to re-use the SPA for SMQ, see the article Creating Applications with the Minnow Server.