Confusion sur l'établissement de la connexion client-serveur dans MQTT

Selon les spécifications , c'est toujours le client qui doit établir la connexion avec un serveur.

Client:

Un programme ou un périphérique qui utilise MQTT. Un client établit toujours la connexion réseau au serveur . Ça peut

• Publiez les messages d'application qui pourraient intéresser d'autres clients.

• Abonnez-vous pour demander des messages d'application qu'il souhaite recevoir.

• Se désinscrire pour supprimer une demande de messages d'application.

• Déconnectez-vous du serveur.

Et si ce client s'abonne à un message d'application, le serveur doit transmettre ces messages à ce client particulier.

Serveur:

Un programme ou un périphérique qui agit en tant qu'intermédiaire entre les clients qui publient des messages d'application et les clients qui ont effectué des abonnements. Un serveur

• Accepte les connexions réseau des clients.

• Accepte les messages d'application publiés par les clients.

• Traite les demandes d'abonnement et de désabonnement des clients.

• Transmet les messages d'application qui correspondent aux abonnements client .

Est-ce à dire que si un client s'abonne, il reste connecté au serveur pendant que l'abonnement est valide même s'il n'y a pas de flux de données la plupart du temps?

J'arrive à cette conclusion parce que si le client se déconnecte après l'abonnement, un serveur ne peut pas lui transmettre de messages car c'est le client qui doit établir la connexion. Mais il ne saura pas quand le rétablir.

Cela signifie-t-il que si un client s'abonne, il reste connecté au serveur pendant que l'abonnement est valide même s'il n'y a pas de flux de données dans la plupart du temps?

Oui, une fois la connexion établie, le client attendra les messages, mais il enverra également régulièrement des messages PING au serveur en fonction de la valeur keepalive. Si un message PING n'est pas reçu par le serveur, il peut vous déconnecter.

si le client se déconnecte après l'abonnement, un serveur ne peut pas lui transmettre de messages car c'est le client qui doit établir la connexion.

Si le client est déconnecté, alors oui, il ne recevra pas de messages, mais il existe des fonctionnalités dans MQTT qui fonctionnent autour de cela.

Si le client se connecte au serveur avec l'indicateur «Clean session» défini sur false, le serveur se souviendra de l'abonnement pour cet ID client. Une fois que le client se reconnecte, il n'a pas besoin de se réinscrire car le serveur s'en est souvenu.

De plus, vous pouvez vous abonner en utilisant QoS Level 1 ou 2. Avec ces niveaux de QoS, le serveur stockera les messages et attendra que le client se reconnecte avant de les envoyer. De cette façon, même si le client se déconnecte et se reconnecte, il recevra toujours tous les messages publiés.

Ce site possède de bonnes ressources expliquant le protocole MQTT.

Cela signifie-t-il que si un client s'abonne, il reste connecté au serveur pendant que l'abonnement est valide même s'il n'y a pas de flux de données dans la plupart du temps?

Oui, votre client attendra les messages.

... si le client se déconnecte après l'abonnement, alors un serveur ne peut pas transférer de messages

Vous devez gérer la déconnexion (en particulier dans les appareils alimentés par batterie). Cela peut être fait en utilisant la fonction " testament et testament " de MQTT: lorsqu'un appareil se déconnecte, il envoie un dernier message.

Vous devez différencier la connexion et la session.

Tout est défini par la session. Lorsque la connexion MQTT est autorisée pour la première fois au courtier, le courtier crée une session pour cette connexion, généralement en fonction du paramètre de connexion id client.

Dans le protocole MQTT 3.1.1 (par défaut actuellement dans la plupart des clients / courtiers) pendant la connexion, vous pouvez spécifier un indicateur clean = true ou clean = false. Si clean = true, le courtier crée automatiquement une nouvelle session et la ferme lorsque la connexion est rompue / fermée. Si clean = false, le courtier maintiendra la session et fournira les événements (dans une sorte de stockage de session) même lorsque le client est déconnecté. Cela dépend de l'implémentation des courtiers si elle autorise une session clean = false et quel est le ttl maximum d'une telle session.

Dans le protocole MQTT 5.0 (très récent, mais en perspective), il est possible de spécifier la session ttl du côté client ou même de la changer après que la connexion a été établie. Ceci est extrêmement utile pour les connexions WAN instables (IoT principalement) ou les connexions avec état comme vous l'avez décrit.

AFAIK actuellement protocole MQTT 5.0 du point de vue du client peut être utilisé en python avec gmqtt et en javascript avec mqtt.js .