In part 1 we met two communication models for computers on a network: request-response and publish-subscribe. Now let's take a look at when you might want to use each, and why.
Request-response: proven and reliable
In a request-response architecture, each client opens a direct connection to each server, because the client requests data directly from the server.
In automation, typically clients are PCs and servers are PLCs or PACs. So each PC opens a direct connection to each PLC or PAC from which it needs data.
And because the client doesn’t know when data may change, it requests data at regular intervals.So PC clients repetitively send requests to PLC and PAC servers—in automation, as fast as multiple times per second—and servers repetitively respond:
Q: What’s the sensor value? A: 10
Q: What’s the sensor value? A: 10
Q: What’s the sensor value? A: 10
Q: What’s the sensor value? A: 10
Q: What’s the sensor value? A: 10
Q: What’s the sensor value? A: 9
Q: What’s the sensor value? A: 9
If your network is robust and has few servers, this model works very well. As long as the server has the capacity to respond to client demands and the network can handle the volume of traffic, request-response is a proven, reliable communication method. It's particularly useful for communications over a secure internal network.
What about traffic volume?
If you have multiple servers with multiple clients, however, the volume of traffic in a request-response model can quickly become a problem.
Below you see how this works. Each client is individually connected to each server it needs to request data from, and each connection may even be opened, queried, answered, and closed, over and over.
In our truck analogy from part 1, you'd see nonstop truck traffic—empty trucks, full trucks—over all of these connections.
In contrast, a pub-sub architecture simplifies communications. Direct connections and repetitive requests for data are not needed.
The web of links is replaced by a single link from each device to the broker (also called a server). The connection between client and broker is kept open and is incredibly lightweight. Only two things travel over this connection: changed data, and a tiny heartbeat to let the broker know that the client is still there.
There are fewer roads, and truck traffic shrinks.
Pub-sub: good for heavy traffic and lightweight networks
So a pub-sub model can make sense if you have many servers and many clients that need to share data and services.
Since the broker is the central clearinghouse for data, individual servers don’t have to strain to serve multiple clients, and clients don’t have to connect to multiple servers. In addition, network traffic is reduced overall, because data is published and sent on a report-by-exception (RBE) basis—that is, only when the data changes—rather than at regular intervals.
Pub-sub can also make sense when it's difficult to set up a direct connection between a client and a server, or when the network is low-bandwidth, expensive, or unreliable—for example, when monitoring equipment in remote locations.
Specific advantages with MQTT/Sparkplug
The pub-sub transport protocol MQTT is frequently mentioned for internet of things (IoT) applications. MQTT is an OASIS standard and an ISO standard (https://en.wikipedia.org/wiki
Often used today for personal internet of things applications, MQTT has an industrial history. It was invented in 1999 for an oil & gas pipeline application in Oklahoma, to solve problems of expensive communications via satellite lines from remote sites.
Of course problems with remote installations and tenuous or expensive network connections are not limited to the oil and gas industry. To solve them, MQTT with Sparkplug offers three additional advantages over request-response:
- Because payloads are compressed and data moves efficiently, even remote devices with irregular connections or low bandwidth can publish or subscribe to data.
- Devices that go offline can reconnect with the broker, sending or receiving current data and also a specified amount of buffered data to help fill in the gap.
- And for data publishers, an important security advantage: data is published using an outbound connection.
This last point is a key consideration for setting up networking and sending data securely without demanding too much help from a corporate information technology (IT) department. All firewalls block inbound traffic (for example, an external client requesting data from an internal server). But they typically allow outbound connections over TCP ports.
Because pub-sub data is sent from devices and software using only outgoing communications (to the broker), these communications do not require either a VPN or port forwarding. That means you can often move data where you need it without requiring a lot of time or effort from IT.
Another significant security advantage of MQTT architecture is that all security is managed at one place: the broker. All Access Control Lists (ACLs), usernames/passwords, and ports are managed at the broker, which can be placed safely on the corporate network or in the cloud. Ports, user authentication, and ACLs are never managed at the client side. That means fewer attack vectors. 
Getting started with MQTT/Sparkplug
To use MQTT/Sparkplug, you'll need to have an MQTT broker compatible with Sparkplug. You can locate the broker on your premises or in the cloud.
For prototyping, you may want to try a public broker. Once you've decided to use the protocol, however, you must have a secure broker. Here's a good article that explains more about using MQTT. More information is available online about using MQTT and Sparkplug in your network.
New products to make getting started easier
Getting the data out of your industrial devices used to be very difficult, but now it's much easier: Opto 22's groov EPIC® System includes Ignition Edge® or full Ignition from Inductive Automation®.
Ignition and Ignition Edge in groov EPIC include the MQTT Transmission Module by Cirrus Link®, which supports the Sparkplug data-encoding specification.
