MQTTv5.0: aperçu des nouvelles fonctionnalités. Partie 2

salut!



Le matériel ci-dessous est une suite de l' article sur les fonctionnalités ajoutées dans la nouvelle version de MQTTv5.0. Si vous l'avez déjà étudié, il ne vous sera pas difficile de remarquer que la plupart des nouvelles fonctions sont basées sur le concept de propriétés qui peuvent être ajoutées au package. Dans cet article, nous les analyserons en détail.



Environ. - L'article s'adresse à ceux qui ont un intérêt ou qui ont besoin de se plonger profondément dans les subtilités de MQTT. Il n'y aura pas de photos et de digressions lyriques, seulement du hardcore !!!



Vous trouverez ci-dessous un tableau de toutes les propriétés ( voir la section 2.2.2.2 de la spécification ).







Maintenant, regardons-les de plus près.

Indicateur de format de charge utile - indicateur de format de charge utile

• 0 - les données sont un ensemble d'octets non définis, ce qui équivaut à ne pas envoyer d'indicateur de format de charge utile,
  
  
• 1 - les données sont des données de caractères encodées en UTF-8.
  
  

Intervalle d'expiration des messages - intervalle d'expiration des messages

Un nombre représentant l'intervalle d'expiration du message (en secondes).



Si l'intervalle d'expiration du message est écoulé et que le serveur n'a pas pu remettre le message au bon abonné, il doit supprimer le message de cet abonné.

Type de contenu - type de contenu

La valeur du type de contenu est déterminée par le client d'envoi et de réception.

Sujet de réponse - un sujet pour une réponse

Chaîne UTF-8 utilisée comme sujet du message de réponse.



Le destinataire du message avec le sujet spécifié pour la réponse envoie sa réponse, en utilisant ce sujet comme sujet de sa publication.



L'interaction demande / réponse dans ce cas se produit comme suit ( voir la clause 4.10.1 de la spécification ):

1. Le client (expéditeur) publie un message de demande avec un sujet, qui spécifie le sujet de la réponse.
   
   
2. () , , . . , .
   
   
3. , , .
   
   
4. . - . , .
   
   

Correlation Data —

Les données de corrélation sont utilisées par l'expéditeur du message de demande pour déterminer à quelle demande le message de réponse appartient lorsqu'il est reçu. S'il n'y a pas de données de corrélation, le demandeur n'a pas besoin de données de corrélation.



Si le message de demande contient des données de corrélation, le récepteur doit également inclure les données de corrélation en tant que propriété dans le paquet PUBLISH du message de réponse.



La valeur des données de corrélation n'a de sens que pour l'expéditeur du message de demande et le destinataire du message de réponse.

Identifiant d'abonnement - identifiant d'abonnement

Un nombre représentant l'ID d'abonnement.



Si la publication est le résultat d'une correspondance avec plus d'un abonnement, plusieurs ID d'abonnement seront spécifiés, auquel cas leur ordre n'a pas d'importance.



Un client peut également faire plusieurs abonnements correspondant à une publication donnée et utiliser le même identifiant pour plusieurs d'entre eux. Dans ce cas, le package PUBLISH contiendra plusieurs identifiants d'abonnement identiques.



L'ID d'abonnement est associé à tout abonnement créé ou modifié à la suite du package SUBSCRIBE. S'il existe un ID d'abonnement, il est enregistré avec l'abonnement. Si cette propriété n'est pas spécifiée, aucun abonnement n'est enregistré avec l'abonnement.



Les identifiants d'abonnement font partie de l'état de session sur le serveur et sont renvoyés au client recevant le paquet PUBLISH correspondant. Ils sont supprimés de l'état de session du serveur lorsque le serveur reçoit un paquet UNSUBSCRIBE, lorsque le serveur reçoit un paquet SUBSCRIBE du client pour le même filtre de rubrique mais avec un ID d'abonnement différent ou aucun ID d'abonnement, ou lorsque le serveur envoie un Session Present de 0 dans le paquet CONNACK.

Intervalle d'expiration de session - intervalle d'expiration de session

Un nombre représentant l'intervalle d'expiration de la session (en secondes).



S'il n'y a pas d'intervalle d'expiration de session, la valeur est utilisée 0. Si elle est définie sur 0 ou n'est pas présente, la session se termine lorsque la connexion réseau est fermée.



Si l'intervalle d'expiration de session est 0xFFFFFFFF (UINT_MAX), la session n'expire pas.



Le client et le serveur doivent conserver l'état de session après la fermeture de la connexion réseau si l'intervalle d'expiration de session est supérieur à 0.



Le client peut se connecter au serveur via un réseau qui fournit une connexion intermittente. Ce client peut utiliser un intervalle d'expiration de session court afin de pouvoir se reconnecter lorsque le réseau redevient disponible et continuer à livrer des messages de manière fiable. Si le client n'a pas le temps de restaurer la connexion, les messages seront perdus.



La définition de Clean Start sur 1 et l'intervalle d'expiration de 0 équivaut à définir CleanSession sur 1 dans la version 3.1.1 de la spécification MQTT. Définir Clean Start sur 0 et aucun intervalle d'expiration de session équivaut à définir CleanSession sur 0 dans la spécification MQTT version 3.1.1.

Identifiant de client attribué - identifiant de client attribué

Une chaîne qui est l'ID client attribué par le serveur. Utilisé si un identifiant client de longueur nulle a été utilisé dans le paquet CONNECT.

Serveur Keep Alive - Serveur Keep Alive

Un nombre qui définit le temps Keep Alive attribué par le serveur. Si le serveur renvoie Server Keep Alive dans un paquet CONNACK, le client DOIT utiliser cette valeur au lieu de la valeur qu'il a envoyée comme Keep Alive. Si le serveur n'envoie pas Server Keep Alive, il DOIT utiliser la valeur Keep Alive définie par le client dans le paquet CONNECT.



L'utilisation principale de Server Keep Alive pour un serveur est d'informer le client qu'il déconnectera le client en cas d'inactivité avant l'expiration du délai Keep Alive spécifié par le client.

Méthode d'authentification - méthode d'authentification

Une chaîne contenant le nom de la méthode d'authentification utilisée pour l'authentification étendue.



S'il n'y a pas de méthode d'authentification, l'authentification étendue n'est pas effectuée.



Une méthode d'authentification est un accord entre un client et un serveur sur la signification des données envoyées dans les données d'authentification et tous les autres champs de CONNECT, ainsi que sur les échanges et le traitement requis par le client et le serveur pour terminer l'authentification. La méthode d'authentification est généralement un mécanisme SASL.

Données d'authentification - données d'authentification

Données binaires contenant des données d'authentification. Envoyé uniquement si une méthode d'authentification est spécifiée. Le contenu de ces données est déterminé par la méthode d'authentification.

Demander des informations sur le problème - informations sur le problème de la demande

Le client utilise cette valeur pour indiquer si une chaîne de motif ou des propriétés personnalisées sont distribuées en cas d'échec.

• 0 - le serveur peut renvoyer une chaîne de motif ou des propriétés personnalisées dans un package CONNACK ou DISCONNECT, mais ne doit pas envoyer de chaîne de motif ou de propriétés personnalisées dans un package autre que PUBLISH, CONNACK ou DISCONNECT,
  
  
• 1 - Le serveur peut renvoyer une chaîne de motif ou des propriétés personnalisées pour n'importe quel package lorsque cela est autorisé.
  
  

Will Delay Interval - Will Message delay interval

Un nombre représentant l'intervalle du délai de Will Message (en secondes). S'il n'y a pas d'intervalle de délai, la valeur par défaut est 0 et il n'y a aucun délai avant la publication du message de volonté.



Le serveur retarde la publication du message jusqu'à ce que l'intervalle de délai expire ou que la session se termine, selon la première éventualité. Si une nouvelle connexion réseau à cette session est établie avant l'expiration de l'intervalle de délai, le serveur DEVRAIT ne pas envoyer de message Will.



Une façon de l'utiliser consiste à empêcher la publication d'un message de volonté s'il y a une déconnexion temporaire du réseau et que le client est en mesure de se reconnecter et de continuer la session avant que le message ne soit publié.

Demander des informations de réponse - demander des informations pour une réponse

Un octet avec la valeur 0 ou 1. Le client utilise cette valeur pour demander au serveur les informations de réponse CONNACK.

• 0 - le serveur ne doit pas renvoyer les informations de réponse,
  
  
• 1 - le serveur peut renvoyer des informations de réponse dans un paquet CONNACK, mais cela n'est pas nécessaire même si le client a demandé ces informations.
  
  

Informations de réponse - informations pour la réponse

Une chaîne UTF-8 utilisée comme base pour créer le sujet de réponse. La façon dont le client crée une rubrique de réponse à partir des informations de réponse n'est pas définie par cette spécification.



Ceci est généralement utilisé pour transmettre un sous-ensemble de sujets unique au monde qui est réservé à ce client, au moins pour la durée de vie de sa session. L'utilisation de ce mécanisme permet de faire cette configuration une fois sur le serveur plutôt que sur chaque client.

Référence du serveur - lien vers le serveur

Une chaîne qui peut être utilisée par le client pour identifier un autre serveur en cours d'utilisation. La valeur de cette chaîne est une liste de liens séparés par des espaces. Le format des liens n'est pas réglementé.



Le serveur peut demander que le client utilise un serveur différent en envoyant un CONNACK ou DISCONNECT avec le code raison «Utiliser un autre serveur» ou «Serveur déplacé». Lors de l'envoi de l'un de ces codes, le serveur peut également inclure une propriété de référence de serveur pour indiquer l'emplacement du ou des serveurs que le client doit utiliser.

• Utiliser un serveur différent - Le client doit temporairement basculer pour utiliser un serveur différent.
  
  
• Serveur déplacé - Le client doit toujours se connecter à un autre serveur.
  
  

Il est recommandé que chaque lien se compose d'un nom suivi de deux points et d'un numéro de port. Si le nom contient deux points, la chaîne de nom peut être placée entre crochets. Un nom entre crochets ne peut pas contenir le caractère de crochet droit ("]"). Ceci est utilisé pour représenter une adresse IPv6 qui utilise un signe deux-points comme séparateur.



Le nom d'un lien serveur est généralement le nom d'hôte, le nom DNS, le nom SRV ou l'adresse IP. La valeur après les deux points est généralement le numéro de port décimal. Cela n'est pas nécessaire si les informations de port sont extraites du nom (par exemple, pour SRV) ou sont la valeur par défaut.



Si plusieurs liens sont fournis, le client doit en sélectionner un.

Chaîne de raison - la chaîne de raison

Une chaîne décrivant la raison associée à cette réponse. Le serveur utilise cette valeur pour fournir des informations supplémentaires au client.



L'utilisation correcte de la chaîne de motif dans le client inclura l'utilisation de ces informations dans une exception levée par le code client ou la journalisation de la chaîne de motif.

Receive Maximum - la valeur maximale du nombre de paquets QOS> 0

Un nombre qui définit le quota d'envoi, qui est utilisé pour limiter le nombre de paquets PUBLISH QOS> 0 qui peuvent être envoyés sans recevoir PUBACK (pour QoS 1) ou PUBCOMP (pour QoS 2). Autrement dit, cette valeur est utilisée pour limiter le nombre de publications QoS 1 et QoS 2 envoyées simultanément. Le client / serveur ne doit pas envoyer de messages avec QoS 1 et QoS 2 s'il y a des messages de réception maximum envoyés qui n'ont pas encore reçu de réponses. Lorsque le maximum de réception est atteint, l'envoi de paquets avec QoS 0 peut également être suspendu, mais pas obligatoire. En même temps, il n'est pas nécessaire de retarder l'envoi de paquets autres que PUBLISH.



Si le client et le serveur ont défini le maximum de réception sur 1, ils s'assurent qu'il n'y a pas plus d'un message «en vol» en même temps.



La valeur spécifiée s'applique uniquement à la connexion réseau actuelle et est réinitialisée lors de la reconnexion.



S'il n'est pas spécifié, la valeur par défaut est 65 535.

Topic Alias ​​Maximum - la valeur maximale de l'alias de rubrique

Nombre qui représente la valeur maximale d'un alias de rubrique.



Cette valeur indique la plus grande valeur acceptée comme alias de rubrique. Il est utilisé pour limiter le nombre d'alias de rubrique qui doivent être stockés dans cette connexion.

Alias ​​de sujet - alias de sujet

Pour réduire la taille du paquet PUBLISH, l'expéditeur peut utiliser un alias de rubrique. Il s'agit d'une valeur entière utilisée pour identifier le sujet au lieu d'utiliser le nom du sujet. Cette technique réduit la taille du paquet PUBLISH et est utile lorsque les noms de rubrique sont longs et que le même nom est souvent réutilisé sur une connexion réseau.



Du côté du destinataire, lors de la réception d'un alias pour un sujet, la correspondance nécessaire est établie entre le sujet et son alias.



Si le package PUBLISH contient un alias de rubrique, le récepteur le traite comme suit ( voir la section 3.3.4 de la spécification ):

1. ,
   
   a) , , ,
   
   b) , , , .
   
   
2. ,
   
   a) ,
   
   b) , .
   
   

Maximum QoS — QoS

Peut être 0 ou 1. S'il n'y a pas de QoS maximum, le client utilise la QoS maximum de 2.



Si le serveur ne prend pas en charge les paquets PUBLISH QoS 1 ou QoS 2, il DOIT envoyer la QoS maximum dans un paquet CONNACK indiquant la QoS la plus élevée qu'il prend en charge.



Si le client reçoit la qualité de service maximale du serveur, il ne doit pas envoyer de paquets PUBLIÉS avec un niveau de qualité de service supérieur au maximum spécifié.

Conserver disponible - l'enregistrement est disponible

• 0 - les messages enregistrés ne sont pas pris en charge,
  
  
• 1 - les messages enregistrés sont pris en charge.
  
  

Un client recevant une valeur Retain Available de 0 du serveur NE DOIT PAS envoyer un paquet PUBLISH avec l'indicateur RETAIN mis à 1.

Propriété utilisateur - propriété utilisateur

Il s'agit d'une paire de chaînes «nom» - «valeur». Cette propriété, contrairement à d'autres, peut apparaître plusieurs fois. Le même nom peut être utilisé pour plusieurs propriétés.



Cette propriété peut être utilisée pour fournir un diagnostic supplémentaire ou d'autres informations.



La signification de ces propriétés n'est pas spécifiée dans la spécification, leur signification et leur interprétation ne sont connues que des clients émetteurs et récepteurs.

Taille maximale des paquets - taille maximale des paquets

Un nombre qui spécifie la taille maximale de paquet que le client / serveur est prêt à accepter. La taille du paquet est le nombre total d'octets dans le paquet MQTT. Cette propriété est utilisée pour indiquer que les paquets dépassant cette limite ne seront pas traités.



S'il n'y a pas de taille de paquet maximale, aucune limite de taille de paquet n'est imposée.



Il est de la responsabilité de l'application de sélectionner une valeur de taille de paquet maximale appropriée si elle choisit de limiter la taille de paquet.

Abonnement Wildcard disponible - Abonnement Wildcard disponible

• 0 - les abonnements génériques ne sont pas pris en charge,
  
  
• 1 - ces abonnements sont pris en charge.
  
  

Si la propriété est manquante, les abonnements génériques sont pris en charge.



Si le serveur prend en charge les abonnements génériques, il peut toujours rejeter une demande d'abonnement spécifique contenant un abonnement générique.

Identificateur d'abonnement disponible - l'identifiant d'abonnement est disponible

• 0 - les identifiants d'abonnement ne sont pas pris en charge,
  
  
• 1 - Les identifiants d'abonnement sont pris en charge.
  
  

Si la propriété est manquante, les ID d'abonnement sont pris en charge.

Abonnement partagé disponible - Abonnement partagé disponible

• 0 - les abonnements généraux ne sont pas pris en charge,
  
  
• 1 - les abonnements généraux sont pris en charge.
  
  

Si la propriété est manquante, les abonnements généraux sont pris en charge.

Conclusion

Permettez-moi de vous rappeler que l'article est né en travaillant sur l'intégration de la fonctionnalité émergente décrite ci-dessus au service de la plateforme IoT. Il m'a également semblé qu'il était assez pratique d'afficher l'affichage des propriétés reçues du client dans l'interface objet ( vous pouvez en savoir plus sur les objets ici >>> ). Vous pouvez masquer les propriétés sans intérêt et ajouter des propriétés personnalisées supplémentaires à afficher. En général, cela ressemble à ceci. C'est probablement tout. Pour tester la fonctionnalité, j'ai trouvé ce projet redboltz / mqtt_cpp assez pratique et clair . Je serais très heureux si, dans les commentaires, vous partagiez d'autres projets open-source de clients MQTT (avec et sans interface graphique) qui prennent en charge la version 5.0.