Choosing the right communication mode for your IoT project

Before you embark on a new IoT project, you should consider which communication patterns are best suited for it. In fact, you should consider these patterns before deciding on protocols, communication frameworks, and middleware to use. The reason is simple: this decision prevents you from dragging yourself into a dilemma that will be difficult to get out of without breaking the solution's code, architecture, security, or interoperability.

By adhering to standards and open specifications, you can improve interoperability. Likewise, by using existing open, standardized, interchangeable components, you can also avoid building expensive middleware. Some patterns may introduce additional complexity early in a project, but this cost may be negligible compared to the cost of unforeseen but avoidable problems later in the project lifecycle, including those related to integration.

Request/Response

Request/response is probably the most common communication pattern. It consists of a client or caller requesting a service from a server or responder (Figure 1). This is the pattern used by HTTP and is the basis for service-oriented architecture, web services, and representational state transfer. It is a useful pattern, especially if you have a client-server or master-slave architecture. Other protocols that support this pattern include the Constrained Application Protocol (CoAP) and the Extensible Messaging and Presence Protocol (XMPP).

Figure 1 Request/Response Communication Pattern

However, one disadvantage of this model is the inequality of the participants, which is also evident in the Internet topology. Two-way communication where both parties request information from each other can be difficult, especially if there are firewalls. You have to decide who is the client and who is the server. If you set the sensor as a client and the middleware as a server, the sensor can report data when needed, but the middleware will have a hard time getting information when needed. If the sensor is a server and the middleware is a client, the middleware can collect data when needed, but the sensor may not be protected by a firewall and anyone can connect to the sensor. Therefore, if a firewall is used in the network, events and event subscriptions or security are difficult to manage, sometimes requiring additional services or a lot of resources.

Event Subscription

The event subscription pattern allows a client to subscribe to events of a given type from a server. The server then notifies the client each time an event is triggered, without having to constantly poll the server (Figure 2). Advanced event subscription mechanisms can include client-specific requirements for when and under what conditions events are needed. The benefit of using this pattern is that over time, half of the messages are not needed and latency for updates is kept to a minimum. Protocols that support this pattern include CoAP; XMPP; and the Generic Event Notification Architecture, which is part of the Universal Plug and Play Architecture and is an extended version of HTTP.

Figure 2 Event subscription communication mode

Asynchronous messaging

Asynchronous messaging is the ability to send messages between peers in a network. The pattern assumes that messages can flow in both directions, with no implicit hierarchical differences between participants (Figure 3). If a protocol supports the asynchronous messaging communication pattern, then all other communication patterns can be built on top of it. Protocols that support this pattern include XMPP Advanced Message Queuing Protocol (AMQP); at the IP layer, the User Datagram Protocol (UDP), although the latter can have issues with firewalls.

Figure 3 Asynchronous messaging communication pattern

Reliable messaging

For critical applications, it is important to know that a message has been delivered to its destination exactly once, and the asynchronous messaging communication pattern does just that. Messages can be lost along the way, but using the request/response pattern, you can retry sending a message until an acknowledgment (or response) comes back from the destination. Because both the message and its response can be lost, this approach ensures that a message is delivered to its destination at least once, but for some applications, such as those that require transactions or do counting, at most once delivery (or at least once delivery) is not enough. Reliable messaging is a method that ensures that a message is delivered to its destination only once. Protocols that support reliable messaging include Message Queuing Telemetry Transport (MQTT), AMQP, and HTTP and XMPP through published open extensions.

Broadcasting a stereo program using two FM transmitters

The previous patterns focused on communication between two entities. However, sometimes a more efficient pattern is needed if the same information is to be sent to multiple entities simultaneously. The simplest such pattern is the multicast communication pattern. Here, a sender sends a message through an intermediary (a proxy or router), which then distributes the message to multiple receivers who request to participate in the communication (Figure 4). This pattern saves bandwidth because the sender does not have to send separate messages to each party individually. In fact, the sender does not even need to know who the receiver is. This pattern is useful in many ways—for example, when synchronizing multiple entities or distributing information to multiple receivers. Protocols that support multicast include XMPP, AMQP, and UDP.

Figure 4 Multicast communication mode

However, there is one caveat: while you can use this pattern to save bandwidth, it is also often used as a way to overcome limitations of the chosen protocol and its support for event subscription patterns. Furthermore, multicast is inherently difficult to make secure, and is only more efficient in terms of bandwidth if the receivers actually use most of the transmitted values. If frequent multicasts are used to reduce latency in a network where event subscriptions are needed but not available, multicast mode may significantly increase rather than reduce the required bandwidth.

Publish/Subscribe

The publish/subscribe communication pattern is an extension of the multicast pattern, with the main difference that the transmitted messages are also stored on the intermediate nodes. Depending on the protocol, the messages or references to the messages are then distributed to the corresponding subscribers. Depending on the chosen protocol and the settings on the intermediary, only the latest message, a given number of messages, or all messages are stored. The distinction between distributing the entire message and only a reference to the message is important and affects the performance of the solution in terms of bandwidth consumption.

If the subscriber consumes most of the message, it is more efficient to forward the message itself, as in the case of multicast. However, if consumption only occurs when needed, it is more efficient to send shorter references, because these messages are smaller and the subscriber will consume only a small part of them to get the actual message. To get the message in the latter case, a separate request/response operation needs to be performed. Protocols that support the publish/subscribe model include MQTT, AMQP, and XMPP.

Ranks

A queue (or first-in, first-out queue) is a communication pattern that allows one or more entities to send messages or work items to a queue and then have one or more receivers receive those messages in an ordered fashion (Figure 5). The queue is typically located on an intermediate node or network to which all participants connect.

Queues are a great load balancing tool where work items collected from multiple sources need to be distributed among existing workers, which may have different performance. By using queues, you can avoid any hard links between data providers and workers, making it easy to expand or shrink the set of data providers and workers based on the actual workload. Of the protocols discussed in this article, only AMQP natively supports queues.

Figure 5 Queue communication mode

Message Broker

Message brokers are essentially standardized middleware components that 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 established from the device to the broker, only the broker needs to be accessible from the internet. The firewall does not need to accept or forward incoming connections from the device, which would be required if you were using a strict peer-to-peer protocol.

In addition to brokering messages, brokers can also provide important services to connected entities, such as acting as intermediaries in multicast, publish/subscribe, and queue patterns. Message brokers also often provide client authentication services, which can be a tricky thing for connected devices in a distributed network.

Therefore, if the broker forwards the identities of authenticated parties in the communication, entities can use this information to make security decisions without having to implement custom authentication in each device. Although peer-to-peer communication may be an option for many, such a solution must handle client authentication itself to avoid being insecure. If you use a protocol that includes a message broker, you may not need to develop your own middleware to make your solution work. Protocols that use brokers in some form include XMPP, AMQP, and MQTT.

alliance

Federation is an important pattern in which the global network is divided into multiple logical parts to enable global scalability and organic growth (Figure 6). The key here is to use a divide and conquer approach to achieve growth without limiting the performance of the existing network. In proxyless communication, such as that conducted using HTTP or CoAP, federation occurs at the domain level. Each domain points to its own set of IP addresses that host its own web servers. You can add new web servers on new domains without limiting access to existing web servers. This is a key feature of the success and scalability of the World Wide Web.

Figure 6 Alliance

When using a proxy protocol that supports federation, proxies connect to each other to route or relay messages. Each proxy handles authentication on its own domain and recognizes how to connect to other domains to forward messages to them. The most well-known proxy protocol that supports federation is Simple Mail Transfer Protocol. Of the proxy protocols discussed in this article, only XMPP supports federation. A federated proxy network provides an elegant way to assign a global identity to each entity.

Discover

Several problems arise in large-scale distribution scenarios. First, things know neither the network identity nor the owner's identity at production time: they only know their conceptual identity. After installation and configuration (preferably using some zero-configuration technology), they learn the new network identity but not the owner's identity.

In a contract, the owner might learn about his or her network identity and the conceptual identity of the item by scanning a sticker on a box. Discovering communication patterns creates a mechanism by which the network identity of the thing is matched to the network identity of the owner using the public knowledge of the conceptual identity of the thing (Figure 7).

This is accomplished by using a registry of things available to both things and owners on the network. Things register their conceptual identities with the registry, and owners simply claim those things using their conceptual identities. If successful, each person's network identity is sent to the other, and both parties then know how to communicate with each other. Extensions to XMPP support this model.

Figure 7 Discovery

Trust Delegation

Being able to make good security decisions is important on the Internet. Trust delegation is a communication pattern in which a thing forwards a request to a more powerful, trusted entity in real time, and then performs actions when a response is returned based on the content of the response (Figure 8).

This trusted entity can then use machine learning or direct communication with the item's owner to learn how to respond to new requests on the network related to items belonging to him or her. To make this model possible, real-time asynchronous two-way messaging is required. Extensions to XMPP support this model.

Trust and Delegation Communication Model