This overview explores three potential SMQ use cases that demonstrate the flexibility and usefulness of the protocol.
A very useful, but not so obvious, use scenario for SMQ is in 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 the use of 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 and that 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, the 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, Windows CE, etc, the 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 typically 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 subsequently connect to all devices that he/she wants to manage individually.
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 one broker.
One SMQ broker can manage any number of devices; thus, a microcontroller based product can be designed with firmware that is hardcoded to connect to one known name. This could be an IP address, but a more flexible solution is to use multicast DNS or mDNS for short. The computer where the broker is installed may, for example, include an mDNS service that responds to say your product name. The devices then use mDNS when looking 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 be embedded in a larger embedded 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, thus 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 by using one application server.
As IoT and web technologies merge, modern design may include solutions comprised of many on-premises devices running the Barracuda App Server. A single operator user interface running in a browser would benefit from being able to control and supervise all devices by connecting to just one device. One of the benefits with the SMQ protocol is that one 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 communicating between disparate networks, such as from a mobile network to say devices connected to a hospital network. Private networks are designed such that computers and network enabled equipment can connect out to servers on the Internet, but not the other way. For this reason, a cloud server solution is required if communication between disparate private networks is required. The cloud server solution enables user interfaces such as browsers, phones, etc. and devices such as industrial equipment to connect out to one server on the Internet. The cloud server is then responsible for managing the communication between the connected clients.
Most private networks are connected to the Internet via a router, but some high security networks only enable connections to the Internet via a proxy. We provide solutions that enable all SMQ clients to connect to the Internet via proxy hardened private networks. All SMQ client solutions, with the exception of the non-secure SMQ client C 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 operating system installed on a Virtual Private Server (VPS). There are many possibilities when it comes to running and operating a cloud server solution. In addition to using services such as Amazon Cloud Services and Microsoft Azure's services, a large selection of other VPS providers can be selected.
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 setup a low cost VPS IoT server for educational purposes. A link to a practical example/tutorial follows at the end of the whitepaper.