Before you embark on a new Internet of Things project, you should consider which communication patterns are best suited to it. In fact, you should consider these patterns before you even decide on the protocols, communication frameworks, and middleware you’ll use. The reason is simple: The decision prevents you from painting yourself into corner that will be difficult to get out of without breaking the code, architecture, security, or interoperability of your solution.
By adhering to standards and open specifications, you improve interoperability. Similarly, by using existing open, standardized, interchangeable components, you also avoid building costly middleware. Some patterns may induce added complexity early in the project, but that cost can be minute compared to the cost of unforeseen yet avoidable problems later in the project life cycle, including problems related to integration.
Request/Response
Request/Response is perhaps the most commonly known communication pattern. It consists of a client, or caller, that requests a service from a server, or responder (Figure 1). This is the pattern that HTTP uses, and it’s the basis for serviceoriented architecture, web services, and Representational State Transfer. It’s a useful pattern, especially if you have a client–server or primary-secondary architecture. Other protocols that support this pattern include the Constrained Application Protocol (CoAP) and the Extensible Messaging and Presence Protocol (XMPP).
Figure 1. The Request/Response communication pattern
One drawback of this pattern, however, is the inequality of participants, which is also apparent in Internet topology. Bidirectional communication, where both parties request information from each other, may be difficult, especially if firewalls are present. You have to decide who the client is and who the server is. If you make a sensor the client and the middleware a server, the sensor can report its data when it chooses to, but the middleware will have difficulty fetching information when it wants to. If the sensor is the server and the middleware the client, the middleware can collect data when it needs to, but the sensor might not be protected by a firewall, leaving anybody able to connect to it. As a consequence, either events and event subscriptions or security is difficult to manage and sometimes require additional services or substantial resources if firewalls are used in the network.
Event Subscription
The Event Subscription pattern allows a client to subscribe to events of a given type from a server. The server then informs the client each time the event is triggered, without having to constantly poll the server (Figure 2). Advanced event subscription mechanisms can include clientspecific requirements of when events are desired and under what conditions. The benefits of using this pattern are that half of the messages aren’t needed over time and the latency of updates is kept to a minimum. Protocols that support this pattern include CoAP; XMPP; and the General Event Notification Architecture, which is part of the Universal Plug and Play architecture, an extended version of HTTP.
Figure 2. The Event Subscription communication pattern
Asynchronous Messaging
Asynchronous messaging is the ability to send a message between peers in a network. The pattern assumes that messages can travel in both directions, and there’s no implied hierarchical difference between participants (Figure 3). If a protocol supports the Asynchronous Messaging communication pattern, all other communication patterns can be built on top of it. Protocols that support this pattern include XMPP; Advanced Message Queuing Protocol (AMQP); and, on the IP level, the User Datagram Protocol (UDP), although this latter protocol might have problems with firewalls.
Figure 3. The Asynchronous Messaging communication pattern
Reliable Messaging
For critical applications, it’s important to know that a message has been delivered exactly once to the destination, and the Asynchronous Messaging communication pattern does just that. The message can be lost en route, but using the Request/Response pattern, you can retry sending the message until an acknowledgement (or response) is returned from the destination. Because both the message and its response can be lost, this method makes sure that the message is delivered at least once to its destination, but at most once—or at least once—isn’t good enough for some applications, such as those that require transactions or those that do counting. Reliable messaging is a way to ensure that a message is delivered exactly once to its destination. Protocols that support reliable messaging include Message Queuing Telemetry Transport (MQTT), AMQP, and—through published open extensions—HTTP and XMPP.
Multicasting
The previous patterns have concerned themselves with communication between two entities. Sometimes, however, a more efficient pattern is required if the same information is to be sent to multiple entities at the same time. The simplest such pattern is the Multicasting communication pattern. Here, the sender sends one message through an intermediary (a broker or router), which then distributes it to multiple recipients that have all requested participation in the communication (Figure 4). This pattern saves bandwidth because the sender doesn’t have to send individual messages to all parties by itself. In fact, the sender doesn’t even have to know who the recipients are. This pattern can be useful in many ways—for instance, when synchronizing multiple entities or when distributing information to many recipients. Protocols that support Multicasting include XMPP, AMQP, and UDP.
Figure 4. The Multicasting communication pattern
One word of caution, however: Although you can use this pattern to save bandwidth, it’s often used as a means of overcoming restrictions in the chosen protocol and its support of the Event Subscription pattern, as well. In addition, multicasting is inherently difficult to secure, and it’s more efficient in terms of bandwidth only if the recipients actually use most of the values transmitted. If you use frequent multicasting to decrease latency in a network where Event Subscription is desired but not possible, the Multicasting pattern might drastically increase rather than decrease the bandwidth required.
Publish/Subscribe
The Publish/Subscribe communication pattern is an extension of the Multicasting pattern, with the principal difference that messages transmitted are also stored on the intermediary node. The messages, or a reference to the messages, are then distributed to the corresponding subscribers, depending on protocol. Only the latest message is stored, a given number of messages are stored, or all messages are stored on the intermediary, depending on protocol chosen and the settings on the intermediary. The difference between distributing the entire message and distributing only a reference to the message is important and affects the performance of the solution in terms of consumed bandwidth. If subscribers consume most of the messages, forwarding the messages themselves is more efficient, as in the case of multicasting. If, however, consumption occurs only on demand, then sending shorter references is more efficient because these messages are smaller and subscribers will use only a minority of them to fetch an actual message. To fetch a message in the latter case, a separate Request/Response action needs to be performed. Protocols that support the Publish/Subscribe pattern include MQTT, AMQP, and XMPP.
Queues
Queues—or first in, first out queues—is a communication pattern that allows one or more entities to post messages or work items to a queue, and then lets one or more receivers receive these messages in an ordered fashion (Figure 5). The queues typically reside on an intermediary node or network to which all participants are connected. Queues are an excellent tool for balancing load, where work items collected from multiple sources need to be distributed among existing workers, perhaps having different performance. By using a queue, you avoid any hard links between data providers and workers and can thus easily extend or constrict both the set of data providers and the set of workers, depending on actual work load. Among the protocols discussed in this article, only AMQP supports queues natively.
Figure 5. The Queue communication pattern
Message Brokers
Essentially standardized middleware components, message brokers provide an elegant solution to the problem that firewalls impose on bidirectional communication between peers in a network. They work by allowing entities to connect to them, and then broker messages between connected clients. Because all connections are made from the devices toward the broker, only the broker needs to be accessible from the Internet. Firewalls don’t need to accept or forward incoming connections to devices, as would be required if you used a strict peertopeer protocol.
Apart from brokering messages, brokers can provide important services to connected entities, such as acting as intermediaries in the Multicasting, Publish/Subscribe, and Queue patterns. Message brokers also typically provide client authentication services, something that can be tricky for connected devices in distributed networks. So, if the broker forwards the identities of alreadyauthenticated parties included in the communication, entities can use this information to make security decisions without the need to implement customized authentication in each device. Although peertopeercommunication might be an option to many, such solutions must handle client authentication themselves to avoid becoming insecure. If you use a protocol that includes message brokers, you might not need to develop your own middleware to make your solutions work. Protocols that use brokers in some form or another include XMPP, AMQP, and MQTT.
Federation
Federation is an important pattern in which a global network is partitioned into logical parts to allow for global scalability and organic growth (Figure 6). The key here is to allow for growth without limiting the performance of the existing network using a divideandconquer approach. In unbrokered communication, such as that done using HTTP or CoAP, federation takes place at the domain level. Each domain points to its own set of IP addresses hosting its own web server. You can add new web servers on new domains without limiting access to existing web servers. This has been a key feature for the success and scalability of the World Wide Web.
Figure 6. Federation
When using a brokered protocol that supports federation, the brokers connect between themselves to route or relay messages. Each broker handles authentication on its own domain and recognizes how to connect to other domains to forward messages to them. The bestknown brokered protocol that supports federation is the Simple Mail Transport Protocol. Among the brokered protocols discussed in this article, only XMPP supports federation. Federated brokered networks provide an elegant way to attribute a global identity to each entity.
Discovery
Several problems arise in a massdistribution scenario. First, things don’t know either the network identity nor the identity of the owner at production time: They know only their conceptual identity. After installation and configuration, which preferably you use some zeroconfiguration technique to achieve, they learn their new network identity but not the identity of the owner. In contract, the owner knows its own network identity and the conceptual identity of the things, perhaps by scanning a sticker on the box. The Discovery communication pattern creates a mechanism whereby the network identity of the things is matched to the network identity of the owner using the common knowledge of the things’ conceptual identity (Figure 7). This occurs using a Thing Registry available on the network to both the things and the owner. The things register their conceptual identity with the registry, and the owner claims the things using only their conceptual identity. If successful, the network identities of each are sent to the other, and both then know how to communicate with each other. An extension to XMPP exists to support this pattern.
Figure 7. Discovery
Delegation of Trust
On the Internet, it’s important to be able to make good security decisions. Delegation of Trust is a communication pattern in which a thing forwards a request to a stronger, trusted entity in real time, and then performs the action when a response is returned based on the contents of the response (Figure 8). This trusted entity can then either use machine learning or direct communication with the owner of the thing to learn how to respond to new requests on the network related to the things belonging to him or her. For this pattern to be possible, asynchronous bidirectional messaging in real time is required. An extension to XMPP exists to support this pattern.
Figure 8. The Delegation of Trust communication pattern
Additional Information
For more information about these protocols, see the following sites: