Os protocolos baseados no padrão de publicação e assinatura negam os benefícios das redes mesh?


7

Os protocolos modelados no padrão de publicação-assinatura , como MQTT e AMQP, exigem um intermediário de mensagens centralizado para coordenar as mensagens enviadas e recebidas. Isso não representa um grande problema quando sua rede IoT se baseia em uma topologia em estrela, na qual todas as mensagens precisam passar por um hub central de qualquer maneira, no entanto, estive pensando nos benefícios das redes mesh e em como elas podem ser afetadas. escolha de protocolo.

A apresentação Introdução ao Thread descreve vários benefícios da rede de malha do Thread em particular (no entanto, eles devem se aplicar geralmente):

✔ Nenhum ponto único de falha

✔ Auto-cura

✔ Robustez de interferência

✔ Auto-extensível

✔ Confiável o suficiente para infraestrutura crítica

Embora eu não possa imaginar os últimos quatro pontos afetados pela escolha do protocolo, estou curioso para saber se o uso de um protocolo intermediado por mensagens cancelaria quaisquer vantagens do "nenhum ponto único de falha" da rede mesh.

O uso de um protocolo baseado em publicação e assinatura introduz um ponto único inevitável de falha em geral, e é por isso que a apresentação de Introdução ao Thread sugere o CoAP como um protocolo potencial a ser usado?


Eu já perguntei sobre o Mosquitto dando suporte a vários corretores para remover o ponto único de falha, mas estou perguntando se isso é um conflito fundamental entre redes de malha e protocolos de publicação e assinatura.

Respostas:


5

Sim e não.

Ambas as tecnologias estão relacionadas a diferentes níveis de fornecimento de conectividade. Normalmente, a rede em malha é fornecida pelo nível 3 ou 4 ou mesmo pelo modelo ISO OSI , dependendo da extensão da implementação. As camadas de rede e transporte fornecem a confiabilidade básica da rede mesh. Essa confiabilidade geralmente não é impedida quando um nó cai.

MQTT e AMQP são protocolos da camada de aplicação no nível 7. Portanto, esses protocolos dependem da confiabilidade dos níveis mais baixos no que diz respeito ao modelo básico. No entanto, é sempre prerrogativa de níveis mais altos de OSI implementar salvaguardas para lidar com falhas nos níveis mais baixos. Por exemplo, o aplicativo pode mudar para uma rede completamente diferente, como Wi-Fi e 4G, por exemplo, se detectar falha na rede. Os smartphones fazem isso o tempo todo quando entramos ou saímos de um local com um Wi-Fi configurado.

Também existem possibilidades para os níveis inferiores acomodarem falhas nos níveis superiores. O balanceamento de carga OSI nível 4, por exemplo, pode acomodar os nós com falha por trás dele. Obviamente, isso exige que cada nó que possa ser endereçado para soluções de balanceamento de carga e / ou failover forneça o mesmo serviço. Obviamente, você também precisa do componente central pelo menos duas vezes. Como o MQTT é basicamente o roteamento no nível do aplicativo, com base em tópicos que devem ser possíveis por duplicação simples. Este é um exemplo de uma solução de cluster MQTT com a implementação do HiveMQ.

Com isso em mente, pode-se concluir que, não , a confiabilidade nos níveis de rede e transporte não pode ser negada pela escolha de quaisquer protocolos de nível superior. No entanto, isso não se aplica à experiência do usuário. Para o usuário, os protocolos de nível inferior são apenas veículos. O uso de um protocolo da camada de aplicativo que possui um único ponto de falha ainda significa que, se esse nó estiver quebrado, sim , a funcionalidade será interrompida, mesmo que minha rede ainda esteja funcionando.

De qualquer forma, a camada de aplicação e acima são responsáveis ​​por fornecer a confiabilidade ao usuário. As redes de malha podem fornecer apenas o básico.

Há uma última coisa a considerar. A menos que haja redundâncias para cada componente, sempre há casos de uso que têm pontos únicos de falha. Provavelmente é o nó com o qual o usuário realmente interage. Na automação residencial, por exemplo, todo nó com falha provavelmente significa que um deles acabou de perder um caso de uso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.