Confusión sobre el establecimiento de la conexión cliente-servidor en MQTT

Según las especificaciones , siempre es el cliente quien debe establecer la conexión con un servidor.

Cliente:

Un programa o dispositivo que usa MQTT. Un cliente siempre establece la conexión de red al servidor . Puede

• Publique mensajes de aplicación en los que otros clientes puedan estar interesados.

• Suscríbase para solicitar mensajes de aplicación que le interese recibir.

• Anule la suscripción para eliminar una solicitud de mensajes de aplicación.

• Desconectarse del servidor.

Y si este cliente se suscribe a un Mensaje de aplicación, el servidor debe reenviar esos mensajes a este cliente en particular.

Servidor:

Un programa o dispositivo que actúa como intermediario entre los Clientes que publican Mensajes de aplicación y los Clientes que han realizado Suscripciones. Un servidor

• Acepta conexiones de red de clientes.

• Acepta mensajes de aplicación publicados por clientes.

• Procesa solicitudes de suscripción y cancelación de suscripción de clientes.

• Reenvía mensajes de aplicación que coinciden con las suscripciones de clientes .

¿Significa esto que si un cliente se suscribe, entonces permanece conectado al servidor mientras la suscripción es válida aunque no haya flujo de datos la mayor parte del tiempo?

Llego a esta conclusión porque si el cliente se desconecta después de la suscripción, entonces un servidor no puede reenviarle mensajes porque es el cliente el que debe establecer la conexión. Pero no sabrá cuándo restablecerlo.

¿Significa esto que si un Cliente se suscribe, entonces permanece conectado al servidor mientras la suscripción es válida aunque no haya flujo de datos la mayor parte del tiempo?

Sí, una vez que se realiza la conexión, el cliente esperará los mensajes, sin embargo, también enviará mensajes PING al servidor regularmente en función del valor de keepalive. Si el servidor no recibe un mensaje PING, puede desconectarlo.

Si el Cliente se desconecta después de la suscripción, un servidor no puede reenviarle mensajes porque es el Cliente quien debe establecer la conexión.

Si el cliente está desconectado, entonces sí, no recibirá mensajes, sin embargo, hay características en MQTT que evitan esto.

Si el cliente se conecta al servidor con el indicador 'Sesión limpia' establecido en falso, entonces el servidor recordará la suscripción para ese ID de cliente. Una vez que el cliente se vuelve a conectar, no será necesario volver a suscribirse ya que el servidor lo habrá recordado.

Además, puede suscribirse utilizando QoS Nivel 1 o 2. Con estos Niveles de QoS, el Servidor almacenará los mensajes y esperará a que el cliente se vuelva a conectar antes de enviarlos. De esta manera, incluso si el cliente se desconecta y vuelve a conectar, seguirá recibiendo todos los mensajes publicados.

Este sitio tiene algunos buenos recursos que explican el protocolo MQTT.

¿Significa esto que si un Cliente se suscribe, entonces permanece conectado al servidor mientras la suscripción es válida aunque no haya flujo de datos la mayor parte del tiempo?

Sí, su cliente esperará los mensajes.

... si el Cliente se desconecta después de la suscripción, un servidor no puede reenviar mensajes

Debe gestionar la desconexión (especialmente en dispositivos alimentados por batería). Esto se puede hacer utilizando la función " última voluntad y testamento " de MQTT: cuando un dispositivo se desconecta, enviará un último mensaje.

Debe diferenciar la conexión y la sesión.

Todo está definido por la sesión. Cuando la conexión MQTT se autoriza al intermediario por primera vez, el intermediario crea una sesión para esta conexión, generalmente basada en el parámetro de conexión de id de cliente.

En el protocolo MQTT 3.1.1 (predeterminado actualmente en la mayoría de los clientes / intermediarios) durante la conexión, puede especificar clean = true o clean = false flag. Si clean = true, el agente creará automáticamente una nueva sesión y la cerrará cuando la conexión se interrumpa o se cierre. Si clean = false, el intermediario mantendrá la sesión y entregará los eventos (en algún tipo de almacenamiento de sesión) incluso cuando el cliente esté desconectado. Depende de la implementación de los corredores si permite una sesión clean = false y cuál es el máximo ttl de dicha sesión.

En el protocolo MQTT 5.0 (muy nuevo, pero en perspectiva) es posible especificar la sesión ttl desde el lado del cliente o incluso cambiarla después de que se haya realizado la conexión. Esto es extremadamente útil para conexiones WAN inestables (IoT principalmente) o conexiones con estado como usted describió.

AFAIK Actualmente MQTT 5,0 protocolo desde la perspectiva del cliente se puede utilizar en pitón con gmqtt y en javascript con mqtt.js .