Quelques réflexions sur mon expérience avec TCP, UDP et MQTT ainsi que quelques ressources supplémentaires à revoir.
Avec UDP, j'ai rencontré le problème d'échec silencieux dans lequel une application sur un nœud de réseau, le client, ne voit que certains des messages UDP qui ont été envoyés. Il y a trop de raisons pour lesquelles le trafic réseau peut mal tourner. Le problème avec UDP est que les paquets peuvent être jetés à peu près chaque fois que l'un des nœuds du chemin réseau entre le producteur de paquets et le consommateur de paquets le justifie. Voir le sujet Wikipedia Perte de paquets .
La question est de savoir quel est votre taux de perte dans n'importe quel contexte de réseau actuel. Donc, s'il s'agit d'une communication au sein d'un LAN ou d'un sous-réseau, votre taux de perte peut être faible. Sur un WAN ou sur Internet, votre taux de perte peut être assez élevé. Les paquets UDP sont rejetés pour un certain nombre de raisons et acheminés, mais les conditions du réseau le permettent avec cette décroissance du nombre de sauts. L'envoi de paquets dans le grand vide sans aucune responsabilité laisse ouverte la possibilité d'échecs silencieux.
Il semble que dans votre cas, un simple accusé de réception avec retransmission après un délai d'attente sans recevoir d'acquittement suffirait.
J'ai fait des messages XML sur une connexion TCP maintenue et cela a très bien fonctionné. J'avais une couche qui livrait des messages complets chacun dans un tampon à la couche application à gérer. J'ai utilisé XML pour emballer le message avec une balise de début XML pour le début du message et une balise de fin XML pour savoir quand le message entier a été reçu.
TCP a quelques fonctionnalités telles que l'ordre séquentiel des paquets, aucune répétition et le fait d'être un mécanisme de transport connecté signifie que vous savez si l'autre extrémité disparaît ou non, même si cela peut prendre un certain temps à le découvrir. La connexion et la déconnexion peuvent introduire des retards mais pas trop lourdes dans des conditions normales, bien que les conditions du réseau puissent ralentir le débit TCP.
MQTT est un protocole qui est transporté par une couche de transport réseau, normalement TCP. MQTT utilise un modèle de publication / abonnement, il n'y a donc aucun stockage de message. Ainsi, lorsqu'un éditeur publie un message si l'abonné n'est pas connecté au moment où il se connecte, il ne verra pas le message. MQTT est à peu près en temps réel, je suppose que c'est la partie télémétrie de l'acronyme. J'aime MQTT pour les petits messages et j'ai fait quelques expériences avec la charge utile JSON via MQTT en utilisant Mosquitto. Voir cet article Remise de messages fiable avec Mosquitto (MQTT) avec un aperçu de MQTT et de la qualité de service. Et consultez ce bref article avec des liens vers des ressources, notamment un exemple d'application IoT - MQTT Publish and Subscriber C Code .
Mes expériences avec MQTT en utilisant du texte JSON et une base de données SQLite3 dans l'abonné pour stocker les messages se trouvent à https://github.com/RichardChambers/raspberrypi/tree/master/mqtt bien que la source soit en C et soit assez désordonnée.
Voici une vidéo de 13 minutes # 144 Protocoles Internet: CoAP vs MQTT, Network Sniffing, et préparation pour IKEA Tradfri Hacking . Ceci est un article intéressant sur CoAP, Constrained Application Protocol: CoAP est le protocole «moderne» de l'IoT . Il y a cette somme de CoAP:
Les premiers adoptants conviennent que le protocole d'application contraint fonctionne extrêmement bien pour les réseaux et les périphériques contraints. Quelque chose de moins connu: "Sur un réseau sans fil très encombré - Wi-Fi ou cellulaire - CoAP peut continuer à fonctionner là où un protocole TCP (Transmission Control Protocol) comme MQTT ne parvient même pas à terminer une prise de contact, "Dit Vermillard.
En effet, contrairement à la plupart des autres protocoles IoT, CoAP est basé sur UDP. En d'autres termes, cela signifie pas de poignée de main de protocole ou de correction d'erreur comme cela se produit avec TCP. "CoAP peut ne pas être aussi fiable que HTTP ou garantir la livraison de messages comme MQTT, mais il est extrêmement rapide", a noté Matthieu. "Si vous acceptez que certains messages ne soient pas reçus, vous pouvez envoyer beaucoup plus de messages dans le même délai."
Il y a quelques autres tels que AMQP, STOMP et CBOR que vous pourriez également consulter. Voir le site web standard CBOR ainsi que cette thèse, Implémentation et évaluation du protocole CBOR . Voir cet article, Choix de votre protocole de messagerie: AMQP, MQTT ou STOMP qui compare et contraste l'AMQP, MQTT et STOMP et se termine par une note sur le courtier RabitMQ:
J'espère que cela peut aider beaucoup de personnes à commencer à naviguer dans la soupe protocolaire pour chacun de vos cas d'utilisation. Comme il est courant pour les entreprises d'avoir de nombreuses applications ayant des besoins différents, il est certainement possible que vous ayez besoin des trois courtiers pour différentes applications. C'est là qu'intervient un courtier polyglotte solide multiprotocole comme RabbitMQ, car il peut envoyer STOMP, MQTT ou AMQP et en retirer l'un des autres. Vous n'avez pas besoin d'être verrouillé par l'un de ces protocoles - les trois sont pris en charge par le courtier RabbitMQ, ce qui en fait un choix idéal pour l'interopérabilité entre les applications. L'architecture du plugin permet également à RabbitMQ d'évoluer pour prendre en charge des versions supplémentaires ou mises à jour de ces protocoles à l'avenir.
Ce package de partage de diapositives d'une soixantaine de diapositives fait une comparaison et un contraste entre quatre protocoles IoT différents en examinant les besoins de deux groupes IoT différents, les consommateurs et les industriels, qui ont des besoins différents en matière de fiabilité et de robustesse. Quelle est la bonne norme de messagerie pour l'IoT? .
Ackn'est pas nécessaire. Je pense que travailler sur la fiabilité par-dessus UDP n'a pas trop de sens, c'est à cela que sert TCP.