This page shows four deployment patterns for Simple Message Queue (SMQ). It focuses on where the broker and clients run. For protocol details, see the SMQ overview. For authentication, authorization, and transport protection, see SMQ Security.
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 this design, which does not require 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.
Centralized management for constrained or multi-device systems
A common design approach is to embed a web server in industrial equipment to enable browser-based device management or supervision. There are two possible limitations to this design option:
Many current microcontrollers can run an embedded web server, including BAS or BWS. A centralized broker may still be preferable when the selected device cannot accommodate the application, when one user interface must manage a fleet, or when maintaining a separate web application on every device would complicate updates.
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 or supervision.
In the centralized pattern, each device runs an SMQ client and connects to one broker that also serves the management application. This reduces the device-side software, but it makes broker availability, capacity, and network access part of the system design.
One SMQ broker can manage multiple devices, subject to the server's memory, file-descriptor, network, and application limits. Device firmware can connect to a configured IP address or host name. On a local network, multicast DNS (mDNS) can resolve a product-specific host name without hard-coding an address. Production systems should also define discovery failure, duplicate broker, and reconnect behavior.
The Barracuda App Server (BAS) is available for multiple platforms. A broker can run as a service on a computer, on a small Linux system, or inside a larger controller. The operator opens the web application hosted by that BAS instance and manages the devices connected to its broker. The supported fleet size depends on the complete server and application configuration.
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.
An on-premises installation may contain several devices running BAS. A browser can remain connected to one origin server while that server exchanges messages with the other devices. A server-side Lua application can participate as an SMQ client, and the cluster plugin can connect multiple BAS-powered nodes. Capacity is bounded by the participating systems, network, broker configuration, and application workload.
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.
A publicly reachable broker is one way to connect clients located behind separate private networks, such as a mobile client and equipment on a hospital network. Each client makes an outbound connection to the broker, avoiding inbound connections to either private network. Depending on the deployment, alternatives may include a managed messaging service, a site-to-site virtual private network (VPN), a private access gateway, or an approved enterprise relay.
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.
Mako Server provides a ready-to-run BAS host for deploying an online SMQ broker on a high-level operating system (HLOS). Linux is a common server target. Connection capacity depends on the operating-system limits, available memory, TLS configuration, message rate, payload size, subscriptions, application logic, and deployment architecture. Validate capacity with a representative load test instead of using a single connection-count figure as a deployment guarantee.
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.