Do protocols based on the publish-subscribe pattern negate the benefits of mesh networks?

Question

Protocols that are modelled on the publish-subscribe pattern such as MQTT and AMQP require a centralised message broker to co-ordinate messages being sent and received. This does not pose much of a problem when your IoT network is based on a star topology, where all messages have to go through a central hub anyway, however I've been thinking about the benefits of mesh networks and how these may be affected by protocol choice.

The Thread Introduction presentation outlines several benefits of Thread's mesh network in particular (however these should apply generally):

✔ No single point of failure

✔ Self-healing

✔ Interference robustness

✔ Self-extending

✔ Reliable enough for critical infrastructure

Although I can't imagine the latter four points being affected by protocol choice, I'm curious as to whether using a message-brokered protocol would cancel out any advantages of the mesh network's "no single point of failure".

Does using a publish-subscribe based protocol introduce an inevitable single point of failure in general, and is this why the Thread Introduction presentation suggests CoAP instead as a potential protocol to use?

---

^{I've already asked about Mosquitto supporting multiple brokers to remove the single point of failure, but I'm asking this to question whether this is a fundamental conflict between mesh networks and publish-subscribe protocols.}

Answer 1

Yes and no.

Both technologies are concerning different levels of providing connectivity. Usually mesh networking is provided by level 3 or 4 or even both of the ISO OSI model, depending on the extend of implementation. The network and transport layers provide the basic reliability of the mesh network. That reliability is usually not impeded when a node drops off.

MQTT and AMQP are application layer protocols on level 7. Therefore these protocols are dependent on the reliability of the lower levels as far as the basic model goes. However it's always the prerogative of higher OSI levels to implement safeguards to cope with failures of the lower levels. For example the application can switch to a completely different network, like from Wi-Fi to 4G for example if it detects network failure. Smartphones do it all the time when we enter or leave a place with a configured Wi-Fi.

There are also possibilities for the lower levels to accommodate for failures in upper levels. OSI level 4 load balancing for example can accommodate for failing nodes behind it. Of course, that requires that each nodes that can be addressed for load balancing and or failover solutions can provide the same service. Also obviously you need the central component at least twice. Since MQTT is basically application level routing based on topics that should be possible by simple duplication. This is an example of an MQTT cluster solution with the HiveMQ implementation.

With that in mind it can be concluded that, no, the reliability on the network and transport levels cannot be negated by the choice of any higher level protocols. However that does not apply to the user experience. For the user the lower level protocols are just vehicles. Using an application layer protocol that has a single point of failure still means, that if that node is broken, then yes, the functionality is broken even though my network is still working.

Anyhow, the application layer and above are responsible to provide the reliability to the user. Mesh networks can only deliver the basics.

There is one final thing to consider. Unless one has redundancies for every component, there are always use cases that have single points of failure. It's most likely the node the user actually interacts with. In home automation for example every failing node very likely means that one just lost a use case.