Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).
Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc...
Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).
[^] # Re: Pas mal d'erreurs dans l'article
Posté par xryl669 . En réponse à la dépêche Transmission de données de capteurs via internet. Évalué à 2. Dernière modification le 31 mai 2022 à 10:25.
Liste des erreurs:
1. Payload dans MQTT non typé (et pas forcément JSON)
2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).
Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc...
Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).