This overview explores four SMQ use cases that demonstrate the flexibility and usefulness of the protocol.
A very useful, but not so obvious, use scenario for SMQ is providing real-time browser updates for one device or system running the Barracuda App Server.
We will look at two design options, where Option 1 is based on the use of Lua bindings and Option 2 is designed without Lua bindings.
Option 1 - Use of Lua bindings:
The following diagram illustrates how an embedded system uses SMQ for sending real-time (asynchronous) messages from a single device to one or multiple connected browsers.
The device C code sends and receives real-time messages to and from the browser via the following chain: Device C code, C-to-Lua binding, your Lua app code, the SMQ broker, and then finally the browser.
Your Lua app code is an interface between your Lua bindings and the SMQ pub/sub API available to server-side Lua code. See the following for more information on these APIs:
Option 2, no Lua bindings:
An alternative to the above design, which does not require designing new Lua bindings, is to integrate and use the non-secure SMQ C client library in the device C code. A separate thread or task, designed in C or C++, can then use the non-secure SMQ C client library and communicate with the SMQ broker over the loopback interface "localhost". Most TCP/IP stacks are very efficient at communicating over the loopback interface.
In an RTOS environment, communication can be between tasks/threads and the thread running the Barracuda socket dispatcher, which in turn powers the SMQ broker. In a high-level operating system such as Linux, VxWorks, or Windows CE, communication can also be between different processes running on the same machine.
A common design approach is to embed a web server in industrial equipment to enable browser-based device management and/or supervision. There are two possible limitations to this design option:
Microcontroller-based solutions typically have insufficient memory since the web server and the web application stored in the device are often too large for the microcontroller's internal memory.
Another limitation with a web-enabled device is that an operator needs to know the IP address of all devices and must then connect to each device individually for management and/or supervision.
SMQ can be used as a solution that eliminates both of the above limitations. Instead of embedding a web server in each device, the SMQ C client library is embedded in the device, which in turn enables device management via a single broker.
One SMQ broker can manage any number of devices; thus, a microcontroller-based product can be designed with firmware that is hard-coded to connect to one known name. This could be an IP address, but a more flexible solution is to use multicast DNS (mDNS). The computer where the broker is installed may, for example, include an mDNS service that responds to your product name. The devices then use mDNS to look up the IP address of the one and only SMQ broker running in the network and subsequently connect to the SMQ broker.
The Barracuda App Server (BAS) is available for many platforms. A broker (powered by BAS) can be installed as a background service on a Windows computer, on a low-cost hardware unit such as a Raspberry Pi, on an Android phone/tablet, or embedded in a larger system such as a PLC. The operator simply navigates to the computer where the Barracuda App Server is installed by entering the mDNS product name in the browser. The web application you design is then loaded from the Barracuda App Server into the browser, enabling the operator to manage any number of devices connected to the broker in real time via SMQ.
The article Modern Approach to Embedding a Web Server in a Device provides additional information on how to control multiple devices in real time using one application server.
As IoT and web technologies merge, modern designs may include solutions composed of many on-premises devices running the Barracuda App Server. A single operator user interface running in a browser benefits from being able to control and supervise all devices by connecting to just one device. One of the benefits of the SMQ protocol is that it can control and supervise any number of devices using the same client. The server hosting the SMQ broker also becomes an SMQ client when a custom Lua application is installed on the server side. The SMQ broker includes a cluster plugin enabling any number of Barracuda App Server-powered devices to communicate using the cluster bus.
The SMQ cluster technology includes a ready-to-use SMQ autodiscover plugin, enabling SMQ-enabled devices to automatically connect to the SMQ cluster bus. A custom server-side Lua application can then inform connected clients/browsers when SMQ-powered devices connect and disconnect. The SMQ publish/subscribe feature also enables a browser to send messages to all devices connected to the cluster bus.
The SMQ protocol uses WebSockets when communicating with an origin server and the SMQ connection is typically authenticated with the origin server using an already established session. A user can establish a session by initially performing a user login. The benefit in transporting all messages via the origin server is that it simplifies authentication and device discovery. A browser would otherwise have to authenticate with any device it connects to.
An IoT cloud server is the only viable solution for communication between disparate networks, such as from a mobile network to devices connected to a hospital network. Private networks are designed so that computers and network-enabled equipment can connect out to servers on the Internet, but not the other way around. For this reason, a cloud server solution is required when communication between disparate private networks is needed. The cloud server solution enables user interfaces such as browsers and phones, and devices such as industrial equipment, to connect out to one server on the Internet. The cloud server is then responsible for managing communication between connected clients.
Most private networks are connected to the Internet via a router, but some high-security networks only allow connections to the Internet via a proxy. We provide solutions that enable all SMQ clients to connect to the Internet through proxy-hardened private networks. All SMQ client solutions, with the exception of the non-secure SMQ C client library, support HTTPS and SOCKS proxy connections.
We recommend using the Mako Server for the online broker solution. The Mako Server, which is internally based on the Barracuda App Server library, is a ready-to-use application server solution you can run on a high-level operating system (HLOS). The recommended IoT cloud server operating system is Linux since the Mako Server for Linux can support up to 212,000 SMQ clients. More devices can be supported by horizontal scaling.
A possible SMQ cloud server solution is depicted in the following figure.
A cloud server machine is typically a Linux system installed on a Virtual Private Server (VPS). There are many options when it comes to running and operating a cloud server solution. In addition to services such as Amazon Web Services and Microsoft Azure, many other VPS providers are available.
Check out the article How to Run Your Own Secure IoT Cloud Server if you are new to cloud server technologies. The whitepaper provides an introduction to how you can set up a low-cost VPS IoT server for educational purposes. A link to a practical example/tutorial follows at the end of the whitepaper.