Algumas reflexões sobre minha experiência com TCP, UDP e MQTT, bem como alguns recursos adicionais a serem revisados.
Com o UDP, deparei-me com o problema de falha silenciosa, no qual um aplicativo em um nó da rede, o cliente, está vendo apenas algumas das mensagens UDP enviadas. Existem muitas razões pelas quais o tráfego de rede pode dar errado. O problema com o UDP é que os pacotes podem ser descartados praticamente sempre que qualquer um dos nós no caminho da rede entre o produtor de pacotes e o consumidor de pacotes justificar. Consulte o tópico Wikipedia Perda de pacotes .
A questão é qual é a sua taxa de perda em qualquer contexto de rede atual. Portanto, se for uma comunicação dentro de uma LAN ou sub-rede, sua taxa de perda poderá ser baixa. Em uma WAN ou na Internet, sua taxa de perda pode ser bastante alta. Os pacotes UDP são descartados por vários motivos e roteados, no entanto, as condições da rede permitem com esse decréscimo na contagem de saltos. O envio de pacotes para o grande vazio sem responsabilidade deixa aberta a possibilidade de falhas silenciosas.
Parece que, no seu caso, apenas uma confirmação simples com retransmissão após um tempo limite sem receber uma confirmação seria suficiente.
Fiz mensagens XML em uma conexão TCP mantida e funcionou muito bem. Eu tinha uma camada que entregava mensagens completas em buffer para a camada de aplicação. Usei XML para empacotar a mensagem com uma marca de início XML para o início da mensagem e uma marca final de XML para saber quando toda a mensagem foi recebida.
O TCP possui alguns recursos, como ordem seqüencial de pacotes, sem repetição e ser um mecanismo de transporte conectado significa que você sabe se a outra extremidade desaparece ou não, embora possa demorar um pouco para descobrir. A conexão e a desconexão podem causar atrasos, mas não onerosas, em condições comuns, embora as condições da rede possam causar a diminuição da taxa de transferência TCP.
MQTT é um protocolo que é transportado por uma camada de transporte de rede, normalmente TCP. O MQTT usa um modelo de publicação / assinatura para que não haja armazenamento de mensagens. Portanto, quando um publicador publica uma mensagem se o assinante não estiver conectado no momento e quando ele se conectar, ele não verá a mensagem. O MQTT é praticamente em tempo real, suponho que é disso que trata a parte de telemetria do acrônimo. Eu gosto do MQTT para pequenas mensagens e tenho feito algumas experiências com a carga útil JSON através do MQTT usando o Mosquitto. Consulte este artigo Entrega confiável de mensagens com o Mosquitto (MQTT) com uma visão geral do MQTT e da qualidade do serviço. E consulte este breve artigo com links para recursos, incluindo um aplicativo de amostra IoT - MQTT Publish e Subscriber C Code .
Minhas experiências com o MQTT usando texto JSON e um banco de dados SQLite3 no assinante para armazenar mensagens estão em https://github.com/RichardChambers/raspberrypi/tree/master/mqtt, embora a fonte esteja em C e seja bastante confusa.
Aqui está um vídeo de 13 minutos # 144 Protocolos da Internet: CoAP vs MQTT, Sniffing de rede e preparação para o IKEA Tradfri Hacking . Este é um artigo interessante sobre CoAP, Protocolo de Aplicação Restrita: CoAP é o protocolo 'moderno' da IoT . Existe este somatório do CoAP:
Os primeiros usuários concordam que o Protocolo de Aplicativo Restrito funciona extremamente bem para redes e dispositivos restritos. Algo pouco conhecido: "Em uma rede sem fio muito congestionada - Wi-Fi ou celular - o CoAP pode continuar a trabalhar onde um protocolo TCP (Transmission Control Protocol) como o MQTT não consegue nem concluir um aperto de mão, "Disse Vermillard.
Isso ocorre porque, diferentemente da maioria dos outros protocolos de IoT, o CoAP é construído sobre o UDP. Em outras palavras, significa que não há handshakes de protocolo ou correção de erros, como encontrado no TCP. "O CoAP pode não ser tão confiável quanto o HTTP ou garantir a entrega de mensagens como o MQTT, mas é extremamente rápido", observou Matthieu. "Se você concorda com algumas mensagens que não estão sendo recebidas, pode enviar muito mais mensagens no mesmo período."
Existem alguns outros, como AMQP, STOMP e CBOR, que você pode ver também. Consulte o site padrão da CBOR , bem como esta tese, Implementação e avaliação do protocolo CBOR . Consulte este artigo, Escolhendo seu protocolo de mensagens: AMQP, MQTT ou STOMP, que compara e contrasta o AMQP, MQTT e STOMP e termina com uma observação sobre o broker RabitMQ:
Felizmente, isso pode ajudar muitos a começar a navegar na sopa de protocolo existente para cada um dos seus casos de uso. Como é comum as empresas terem muitos aplicativos com necessidades diferentes, certamente é possível que você precise dos três intermediários em aplicativos diferentes. É aí que entra um corretor poliglota sólido e multiprotocolo como o RabbitMQ - já que ele pode enviar STOMP, MQTT ou AMQP e liberar um dos outros. Você não precisa ficar preso a um desses protocolos - todos os três são suportados pelo broker RabbitMQ, tornando-o a escolha ideal para interoperabilidade entre aplicativos. A arquitetura do plugin também permite que o RabbitMQ evolua para suportar versões adicionais ou atualizadas desses protocolos no futuro.
Este pacote de compartilhamento de slides de cerca de 60 slides faz uma comparação e contraste entre quatro protocolos diferentes de IoT, atendendo às necessidades de dois grupos diferentes de IoT, Consumidores e Industriais, que têm necessidades diferentes de confiabilidade e robustez. Qual é o padrão de mensagens correto para a IoT? .
Ack
não é necessário. Eu acho que trabalhar com confiabilidade no UDP não faz muito sentido, é para isso que serve o TCP.