MQTT Capabilities in Reekoh

MQTT has become a de-facto standard protocol for many IoT and Industrial IoT solutions. When working with MQTT capabilities in Reekoh, we have devised a series of best practices that you can follow to best handle your data and scaling requirements.

Reekoh Plugins and Modules that enabled MQTT

Reekoh MQTT Plugin and Module Attributes

MQTT Request/Response Patterns

Gateway to Connector

• This is a naïve implementation of a request response pattern over MQTT.
• Data is published to a Topic on the Gateway, and the Connector is publishing to other Topics on the Gateway, to which the consumer is subscribing.
• Autoscaling on the MQTT Gateway can mean that some messages may be published on different replicas and therefore may not be able to be reliably subscribed to.

Gateway to Channel

• This approach permits a request/response pattern through separating data ingress from data egress, allowing the use of optimisations for each stage of the pipeline.
• Best suited to patterns where outbound only communication is desired and lower volumes are required (e.g. bridging OT systems to IT applications).
• The lack of autoscaling support on the Channel, which is required to permit reliable subscription, limits applications to those with lower volumes.

Topic Segregated Flow

• This approach permits a high volume request response pattern, but only if topic segregation is possible (for example with Sparkplug B).
• It permits the use of a single MQTT endpoint for both request and response.

Gateway to Cloud Broker

• This approach permits a high volume request response pattern, but requires the use of two different MQTT endpoints.
• Very similar to Gateway to Channel approach, except facilitates high volume egress as well.

Integration-less MQTT with Cloud Broker

• The standalone MQTT Cloud Broker module (launching late 2020) can be used to create high-volume, clustered MQTT brokers from within the Reekoh platform.
• This broker can be used on its own, and not tied to an integration pipeline, for purposes where existing applications may require a broker to communicate directly with each other.
• The broker can also be used to emit selected data to an integration pipeline.

Using Sparkplug

• Standalone MQTT Cloud Broker can be used for all Sparkplug interactions.
• Gateways permit registration of multiple topics through wildcarding as data ingress. Streams can subscribe to subsets of data only.
• In the future, Sparkplug B Birth/Death Certificates will integrate with the Reekoh Device Registry module, and Payload Definitions can be loaded as Data Schemas in the Data Management module.