¿Los protocolos basados ​​en el patrón de publicación-suscripción niegan los beneficios de las redes de malla?

Los protocolos que se modelan en el patrón de publicación-suscripción como MQTT y AMQP requieren un intermediario de mensajes centralizado para coordinar los mensajes que se envían y reciben. Esto no plantea un gran problema cuando su red de IoT se basa en una topología en estrella, donde todos los mensajes tienen que pasar por un concentrador central de todos modos, sin embargo, he estado pensando en los beneficios de las redes de malla y cómo estos pueden verse afectados por elección de protocolo

La presentación de Introducción de hilos describe varios beneficios de la red de malla de hilos en particular (sin embargo, estos deberían aplicarse en general):

✔ Sin punto único de falla

✔ Autocuración

✔ robustez de interferencia

✔ autoextensible

✔ Suficientemente confiable para infraestructura crítica

Aunque no puedo imaginar que los últimos cuatro puntos se vean afectados por la elección del protocolo, tengo curiosidad por saber si el uso de un protocolo de mensajes corregirá cualquier ventaja de "ningún punto único de falla" de la red de malla.

¿El uso de un protocolo basado en publicación-suscripción introduce un punto único inevitable de falla en general, y es por eso que la presentación de Introducción de Hilos sugiere CoAP en su lugar como un protocolo potencial para usar?

^{Ya he preguntado sobre Mosquitto que admite múltiples corredores para eliminar el único punto de falla, pero estoy preguntando si esto es un conflicto fundamental entre las redes de malla y los protocolos de publicación-suscripción.}

Si y no.

Ambas tecnologías están relacionadas con diferentes niveles de conectividad. Por lo general, las redes de malla son proporcionadas por el nivel 3 o 4 o incluso por el modelo ISO OSI , dependiendo de la extensión de la implementación. La red y las capas de transporte proporcionan la fiabilidad básica de la red de malla. Esa confiabilidad generalmente no se ve impedida cuando un nodo se cae.

MQTT y AMQP son protocolos de capa de aplicación en el nivel 7. Por lo tanto, estos protocolos dependen de la confiabilidad de los niveles inferiores en lo que respecta al modelo básico. Sin embargo, siempre es prerrogativa de los niveles más altos de OSI implementar salvaguardas para hacer frente a las fallas de los niveles más bajos. Por ejemplo, la aplicación puede cambiar a una red completamente diferente, como Wi-Fi a 4G, por ejemplo, si detecta fallas en la red. Los teléfonos inteligentes lo hacen todo el tiempo cuando entramos o salimos de un lugar con un Wi-Fi configurado.

También hay posibilidades de que los niveles inferiores se adapten a las fallas en los niveles superiores. El equilibrio de carga de nivel 4 de OSI, por ejemplo, puede adaptarse a los nodos que fallan detrás de él. Por supuesto, eso requiere que cada nodo que pueda ser abordado para el equilibrio de carga y / o las soluciones de conmutación por error puedan proporcionar el mismo servicio. También, obviamente, necesita el componente central al menos dos veces. Dado que MQTT es básicamente un enrutamiento a nivel de aplicación basado en temas que deberían ser posibles por simple duplicación. Este es un ejemplo de una solución de clúster MQTT con la implementación de HiveMQ.

Con eso en mente, se puede concluir que, no , la confiabilidad en la red y los niveles de transporte no se pueden negar mediante la elección de protocolos de nivel superior. Sin embargo, eso no se aplica a la experiencia del usuario. Para el usuario, los protocolos de nivel inferior son solo vehículos. El uso de un protocolo de capa de aplicación que tiene un único punto de falla todavía significa que si ese nodo está roto, entonces sí , la funcionalidad está rota aunque mi red todavía esté funcionando.

De todos modos, la capa de aplicación y superior son responsables de proporcionar la confiabilidad al usuario. Las redes de malla solo pueden ofrecer lo básico.

Hay una última cosa a considerar. A menos que uno tenga redundancias para cada componente, siempre hay casos de uso que tienen puntos únicos de falla. Es muy probable que sea el nodo con el que el usuario interactúa realmente. En la automatización del hogar, por ejemplo, cada nodo que falla probablemente significa que uno acaba de perder un caso de uso.