Avant de commencer le texte, je dois remercier le internaute « Xiaolong » et les internautes du groupe emqtt.io pour leur aide, je viens tout juste de commencer à utiliser MQTT. Il y a beaucoup de choses que je ne comprends pas, lorsque j’ai demandé la solution dans le groupe emqtt.io, « Xiaolong » m’a donné une explication détaillée de certains points de connaissance MQTT et a donné des solutions, merci beaucoup. Je pense que certaines des choses mentionnées sont encore très utiles pour les débutants, donc voici un résumé de mon historique de discussions avec « Xiaolong » pour votre référence.
Question 1 : Si le MCU a un cache et une puissance de traitement limités, il est impossible d’envoyer des messages en même temps, comment publier les messages via MQTT dans ce cas ?
D’abord, assemblez l’en-tête du protocole publie, écrivez la longueur de la charge utile dedans, envoyez-la via TCP, puis envoyez la charge utile petit à petit. Si vous ne pouvez pas obtenir la longueur totale de la charge utile, c’est difficile. Parce que vous envoyez un rapport du protocole de publication, après que le serveur ait lu la longueur de la charge utile dans la tête, il continuera à lire jusqu’à atteindre la longueur requise, puis la publication sera comptée. Par conséquent, il faut d’abord confirmer la longueur du contenu que vous publiez, puis regrouper l’en-tête du paquet de publication, remplir la longueur de la charge utile, tcp :send(head), puis envoyer la charge utile une par une, par exemple 1k à la fois, ou envoyer les données selon le TCP normal, et l’envoyer complètement, même si la publication est terminée. Le prochain envoi appartient à la couche TCP, et vous n’avez pas besoin d’intervenir. Si dans la couche TCP, l’envoi échoue, il doit y avoir un problème avec le socket, la connexion est coupée, vous devez vous reconnecter au serveur MQTT, si ce n’est pas terminé, alors la session serveur se terminera aussi, c’est-à-dire que le serveur n’a pas reçu les données. Reconnecter, vous devez renvoyer le message, tant qu’il est déconnecté, vous devez vous reconnecter, et si vous voulez renvoyer les données, cela dépend si vous avez sauvegardé les données précédentes. Aussi, si le message est important, vous pouvez utiliser qos=1 ou 2 pour vous assurer que le serveur reçoit le message, qos=1 nécessite un aller-retour, qos=2 en nécessite quatre, qos=0 est très simple, tant que vous l’envoyez, cela n’a pas d’importance.
Question 2 : Existe-t-il de nombreuses ressources open source pour MQTT ?
La connexion hyperlientérée est visible.Il y en a beaucoup
Question 3 : Pourquoi MQTT ne fournit-il généralement pas de fonctions de persistance ?
Le protocole MQTT est conçu selon la conception en ligne de l’appareil, et les données sont stockées en mémoire
Question 4 : Le MQTT est-il une source de mémoire qui consomme beaucoup ?
MQTT consomme plus de mémoire, et les données mesurées d’emqtt sont : 38W, la mémoire compte 14G, CPU 15 %
Question 5 : Quelle est la relation entre la session et le client ?
Par exemple, si une carte, en tant que client, initie une requête de connexion MQTT pour se connecter au serveur MQTT, par exemple un service EMQTT, après que le serveur EMQTT ait reçu la requête de connexion de cette carte, il établira une connexion TCP avec la carte sur la couche TCP, et au sein d’EMQTT, un processus sera généré pour communiquer avec cette carte, et un processus sera également généré, appelé session. Ce session est un thème spécialisé dans la gestion de l’abonnement de ce forum, et d’autres conseils l’enverront également à la session correspondante à ce forum s’ils publient le sujet d’intérêt pour ce forum. Si cette session reçoit le sujet abonné et constate que le client est toujours en vie, il enverra les données via ce client via TCP vers ce forum, si l’on constate que le client n’est plus là, c’est-à-dire que le tableau et le serveur sont défaillants. Ensuite, la session enregistrera d’abord le sujet d’abonnement reçu dans la session, et la prochaine fois que le tableau sera connecté, et cleansession=false, la session ne sera pas effacée, et lors de la connexion, le message d’abonnement précédemment reçu sera envoyé au board, ce qui est probablement ce que cela signifie.
Question 6 : Comment emqtt sait-il que le client connecté est le même ?
Lors de la connexion, vous devez définir un identifiant client, cet ID peut rester non défini, sinon non défini, un identifiant unique sera automatiquement généré côté serveur emqtt, si vous voulez utiliser la session, vous devez avoir un identifiant unique, vous pouvez utiliser l’IMEI. Si vous devez recevoir des messages hors ligne, vous devez utiliser un identifiant défini.
Question 7 : Peut-on modifier l’heure de session d’emqtt ?
Vous pouvez changer l’heure de la séance, maintenant elle est de 48 heures, vous pouvez la changer à une semaine, si vous voulez que ce soit permanent, j’ai bien peur que l’EMQTT ne soit pas adapté.
Question 8 : L’autorisation d’accès d’emqtt est-elle écrite dans le fichier de configuration ?
etc/acl.config
Question 9 : Quelle est la répartition de l’emqtt ?
Distribué signifie simplement connecter plusieurs de vos serveurs ensemble, un ou plusieurs d’entre eux, tant qu’ils ne sont pas tous défectueux, emqtt peut fonctionner normalement. Les données EMQTT sont partagées par plusieurs nœuds, et s’il y a un problème avec un nœud, les données ne seront pas perdues, mais les données de session sur le nœud seront perdues.
|
Publié sur 15/02/2019 10:25:09
|
|
|
