El análisis más completo en la historia del protocolo MQTT (uso compartido puro de productos secos)

¿Qué es MQTT?

El nombre completo del protocolo MQTT es (Message Queuing Telemetry Transport), que es el Protocolo de transporte de telemetría de Message Queue Server.

Es un protocolo de comunicación liviano basado en el modelo de publicación/suscripción (Publicar/Suscribir), y el protocolo está construido sobre el protocolo TCP/IP. Sabemos que el protocolo TCP en sí tiene las características de alta confiabilidad, por lo que se basa en it El protocolo MQTT también tiene las características de alta confiabilidad y baja sobrecarga.La razón de la baja sobrecarga es que el mensaje más pequeño transmitido por el protocolo MQTT es de solo dos bytes.

En el desarrollo del Internet de las cosas, MQTT no es la única opción, los protocolos que compiten con MQTT incluyen los protocolos XMPP y CoAP.

En cuanto al concepto de publicación y suscripción, tomemos como ejemplo la plataforma Douyin. Cada uno de nuestros usuarios es un cliente, y Douyin es un servidor en el protocolo MQTT. Cuando nosotros (usuario 1) seguimos a un determinado editor de videos (Usuario 2) , tal acto de atención puede entenderse como una suscripción; al mismo tiempo, el usuario 2 también puede seguirte, entonces esto es una suscripción mutua. Cuando el usuario 2 publica un trabajo, el trabajo se publica en la plataforma Douyin, que es nuestro servidor actual, y este proceso es el lanzamiento de noticias.

Cabe señalar aquí que el mensaje publicado por el usuario 2 (cliente) no se publica directamente en el usuario 1, sino en la plataforma Douyin (servidor).Como el usuario 1 se suscribe al mensaje del usuario 2 (equivalente a hacer clic en Seguir), entonces Douyin la plataforma (servidor) enviará este mensaje al usuario (tenga en cuenta la diferencia entre publicar y enviar). Esta es una metáfora simple para la suscripción y publicación del protocolo MQTT.

Lo anterior es una metáfora, comparemos el modelo de comunicación del protocolo MQTT real:

la realización del protocolo MQTT requiere la finalización de la comunicación entre el cliente y el servidor. En el proceso de comunicación, hay tres identidades en el protocolo MQTT: Editor (Publicar ), Broker (Broker) (Servidor), Suscriptor (Subscribe). Entre ellos, el publicador y el suscriptor del mensaje son clientes, el agente de mensajes es el servidor y el publicador del mensaje puede ser el suscriptor al mismo tiempo.

El mensaje que transmite MQTT se divide en dos partes: tema (Topic) y carga (payload).

• Tema, que puede entenderse como el tipo de mensaje, después de que el suscriptor se suscriba (Subscribe), recibirá el contenido del mensaje (carga útil) del tema
• la carga útil, que puede entenderse como el contenido del mensaje, se refiere al contenido específico que utilizará el suscriptor

algunos términos explicados

Conexión de redConexión de red

La infraestructura subyacente del Protocolo de transporte (TCP) utilizada por MQTT.

• El cliente lo usa para conectarse al servidor.
• Proporciona una transferencia de flujo de bytes ordenada, fiable y bidireccional.

Mensaje de aplicación Mensaje de aplicación

El protocolo MQTT transmite datos de aplicación a través de la red. Cuando los mensajes de la aplicación se transmiten a través de MQTT, tienen una calidad de servicio (QoS) y un tema (Tema) asociados.

cliente cliente

Un programa o dispositivo que utiliza MQTT. Los clientes siempre se conectan a los servidores a través de la red. puede

• Publicar mensajes de aplicación a otros clientes relacionados.
• Suscríbase a la solicitud para recibir noticias relevantes sobre la aplicación
• Cancele la suscripción para eliminar las solicitudes para recibir mensajes de la aplicación.
• Desconectarse del servidor.

servidor servidor

Un programa o dispositivo que actúa como intermediario entre los clientes que envían mensajes y los clientes que solicitan suscripciones. Servidor

• Aceptar conexiones de red de los clientes.
• Aceptar los mensajes de la aplicación publicados por el cliente.
• Maneja las solicitudes de suscripción y cancelación de suscripción de los clientes.
• Reenviar mensajes de solicitud a clientes suscritos elegibles.

Suscribirse Suscripción

Las suscripciones contienen un filtro de temas (Filtro de temas) y un nivel máximo de calidad de servicio (QoS). Las suscripciones están asociadas a una sola sesión. Una sesión puede contener más de una suscripción. Cada suscripción a una sesión tiene un filtro de tema diferente.

Nombre del tema

Una etiqueta adjunta a los mensajes de la aplicación conocida por el servidor y que coincide con una suscripción. El servidor envía una copia del mensaje de la aplicación a cada suscripción de cliente coincidente.

Filtro de tema Filtro de tema

Una expresión contenida en una suscripción que representa uno o más temas con los que está relacionada. Los filtros de temas pueden usar comodines.

Sesión Sesión

Interacción con estado entre el cliente y el servidor. Algunas sesiones duran tanto como una conexión de red, otras pueden extenderse a través de varias conexiones de red consecutivas entre el cliente y el servidor.

Mensaje de control Paquete de control MQTT

Un paquete de información enviado a través de una conexión de red. La especificación MQTT define catorce tipos diferentes de mensajes de control, uno de los cuales (mensaje PUBLISH) se utiliza para transmitir mensajes de aplicación.

Características de MQTT

1. El cliente lo usa para conectarse al servidor.
2. Proporciona una transmisión de flujo de bytes ordenada, fiable y bidireccional.
3. Utilice el modo de publicación/suscripción de mensajes para proporcionar distribución de mensajes de uno a muchos y desacoplamiento entre aplicaciones.
4. La transmisión de mensajes no necesita conocer el contenido de la carga útil.
5. Proporcione tres niveles de calidad de servicio QoS:
6. Pequeño consumo de transmisión e intercambio de datos de protocolo, minimizando el tráfico de red
7. Cuando ocurre una desconexión anormal de la conexión, se puede notificar a las partes relevantes.

Calidad del mensaje (QoS)

Hay tres niveles de calidad de mensaje MQTT, QoS 0, QoS 1 y QoS 2.

QoS 0: distribuir como máximo una vez. La transmisión de mensajes depende completamente de la red TCP/IP subyacente. La respuesta y el reintento no están definidos en el protocolo. Los mensajes llegarán al servidor solo una vez o nunca llegarán. Los mensajes pueden perderse. Por ejemplo, este nivel se puede usar para datos de sensores ambientales, donde una sola pérdida de datos está bien porque se enviará nuevamente poco tiempo después.

QoS 1: entrega al menos una vez. El mensaje recibido por el servidor es confirmado por el mensaje PUBACK.Si el enlace de comunicación o el dispositivo de envío es anormal, o el mensaje de confirmación no se recibe dentro del tiempo especificado, el remitente reenviará el mensaje con el bit DUP establecido en el mensaje. encabezamiento. (función de entrega garantizada)

QoS 2: Distribuido solo una vez. Este es el nivel más alto de mensajería, la pérdida y la duplicación de mensajes son inaceptables, y hay una sobrecarga adicional por usar este nivel de calidad de servicio. Por ejemplo, este nivel podría usarse en un sistema de facturación donde los mensajes duplicados o faltantes darían como resultado una facturación incorrecta.

Por ejemplo,
los candados inteligentes para bicicletas compartidos actualmente populares, los candados inteligentes pueden usar regularmente mensajes de calidad QoS nivel 0 para solicitar al servidor que envíe la ubicación actual de la bicicleta. No importa si el servidor no lo recibe, de todos modos, lo enviará nuevamente después de un período de tiempo. Después de eso, el usuario puede consultar la ubicación de las bicicletas circundantes a través de la aplicación. Después de encontrar la bicicleta, debe desbloquearse. En este momento, se puede usar el mensaje de calidad QoS nivel 1. La aplicación del teléfono móvil enviará continuamente la desbloquee el mensaje al candado de la bicicleta para asegurarse de que el mensaje se pueda alcanzar una vez para desbloquear la bicicleta. Finalmente, después de que el usuario haya agotado la bicicleta, debe enviar el formulario de pago, y el mensaje de calidad de nivel 2 de QoS se puede usar para garantizar que los datos solo se transmitan una vez, de lo contrario, el usuario pagará de más.

Formato de paquete de control MQTT

La estructura del mensaje de control MQTT

Encabezado fijo	Encabezado fijo, todos los paquetes de control contienen
Encabezado variable	Cabecera variable, algunos paquetes de control contienen
Carga útil	Carga útil, algunos paquetes de control contienen

Nota: El encabezado fijo debe tenerlo, y el encabezado variable y la carga útil pueden estar ausentes.

[ Encabezado fijo ]: los 4 bits superiores del primer byte son el tipo de mensaje de control MQTT + los 4 bits inferiores del primer byte se usan para especificar el bit indicador del tipo de mensaje de control (solo se usa cuando PUBLISH publica un mensaje) + La longitud restante es de 1 a 4 bytes (el campo de longitud máxima restante es de 4 bytes)
La longitud restante incluye encabezado variable y datos de carga útil.
La longitud restante no incluye el número de bytes utilizados para codificar el propio campo de longitud restante.
El campo de longitud restante utiliza un esquema de codificación de longitud variable, y para valores inferiores a 128 utiliza una codificación de un solo byte. Los valores más grandes se manejan de la siguiente manera.
Los 7 bits menos significativos se usan para codificar datos y los bits más significativos se usan para indicar si hay más bytes. Entonces cada byte puede codificar 128 valores y un bit de continuación.
El campo de longitud máxima restante es de 4 bytes.

【Encabezado variable】: el contenido del encabezado variable varía según el tipo de mensaje.
Ciertos mensajes de control MQTT contienen una sección de encabezado variable. Está entre el encabezado fijo y la carga útil. El campo Identificador de paquete del encabezado variable existe en varios tipos de paquetes.
Identificador de mensaje (2 bytes): 9 mensajes de control que contienen identificadores de mensaje: PUBLISH (QoS>0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK

Notas sobre los identificadores de mensajes:
1. El cliente y el servidor asignan identificadores de mensajes independientemente uno del otro. Por lo tanto, la combinación de cliente y servidor que utiliza el mismo identificador de mensaje puede lograr un intercambio de mensajes simultáneo.
2. Los paquetes de control SUBSCRIBE, UNSUBSCRIBE y PUBLISH (QoS mayor que 0) deben contener un identificador de paquete de 16 bits distinto de cero (Packet Identifier) ​​3. Cada vez que el cliente
envía un nuevo paquete de estos tipos, debe asignarse Un identificador de mensaje no utilizado actualmente. Si un cliente reenvía este paquete de control en particular, DEBE usar el mismo identificador cuando reenvíe ese paquete posteriormente. Después de que el cliente haya procesado la confirmación correspondiente al mensaje, el identificador del mensaje se libera para su reutilización.
4. Los paquetes PUBLICAR con QoS establecido en 0 no pueden contener identificadores de paquetes.
5. Los paquetes PUBACK, PUBREC, PUBREL deben contener el mismo identificador de paquete que el paquete PUBLICACIÓN enviado originalmente. Del mismo modo, SUBACK y UNSUBACK deben contener el identificador de mensaje utilizado en los mensajes SUBSCRIBE y UNSUBSCRIBE correspondientes.
6. Función: determine si estos campos deben incluirse en el encabezado de variable en función del bit de bandera

【Carga útil】: algunos mensajes de control MQTT contienen una carga útil en la última parte del mensaje. Por ejemplo, para PUBLICAR, la carga útil es el mensaje de la aplicación.
Los paquetes de control que pueden contener cargas útiles son: CONECTAR, PUBLICAR, SUBSCRIBE, SUBACK, UNSUBSCRIBE

Catorce tipos de mensajes de control.

Nota: C->S se refiere al cliente al servidor, S->C se refiere al servidor al cliente, C<->S se refiere a ambas direcciones, lo que permite que los valores de tipo 0 y 15 sigan siendo
inválidos.
Los valores de la tabla se refieren a los 4 bits superiores del primer byte de la cabecera fija, es decir, los valores del tipo de mensaje de control MQTT
PUBREC, PUBREL y PUBCOMP solo existen a nivel de QoS2

Mensaje de control nº 1: CONNECT – conectar con el servidor

Nota: Una vez establecida la conexión de red del cliente al servidor, el primer mensaje enviado por el cliente al servidor debe ser un mensaje de CONEXIÓN.
En una conexión de red, el cliente solo puede enviar un mensaje de CONEXIÓN una vez. El servidor debe tratar el segundo paquete CONNECT enviado por el cliente como una violación del protocolo y desconectar al cliente.
El encabezado variable del mensaje CONNECT contiene cuatro campos en el siguiente orden: Nombre de protocolo (Nombre de protocolo), Nivel de protocolo (Nivel de protocolo), Banderas de conexión (Banderas de conexión) y Keep Alive (Keep Alive) Un valor sin signo indica la revisión
de el protocolo. Para la versión de protocolo 3.1.1, el valor del campo Nivel de protocolo es 4 (0x04). Si
se encuentra un nivel de protocolo no admitido, el servidor debe enviar un mensaje CONNACK con un código de retorno de 0x01 (nivel de protocolo no admitido) al cliente en respuesta al mensaje CONECTAR y luego desconectar el cliente
. parámetros utilizados para especificar el comportamiento de la conexión MQTT. También indica si el campo está presente en la carga útil. Esta bandera de conexión indicará el contenido de la siguiente carga útil
Nota: El servidor debe verificar si el bit de bandera reservada (bit 0) del mensaje de control CONNECT es 0, y si no es 0, el cliente debe desconectarse

Contenido del mensaje de control CONNECT:
encabezado fijo MQTT Tipo de mensaje de 4 bits más 4 bits reservados es 10, los bytes de longitud restantes están determinados por la longitud de datos subsiguiente
Nombre de protocolo fijo de encabezado variable Longitud de 6 bytes 00 04 + MQTT UTF-8 Codificación 00 04 4D 51 54 54
Nivel de protocolo 1 byte 04 representa la versión de protocolo 3.1.1
Indicador de conexión 1 byte C2 Establecer indicador de contraseña, indicador de nombre de usuario, indicador de borrado de sesión
Mantener el tiempo de conexión 2 bytes 00 78 representa 120 segundos
de carga ID de cliente longitud de datos 2 bytes + ID de cliente Código ASC + nombre de usuario longitud de datos 2 bytes + nombre de usuario Código ASC + contraseña longitud 2 bytes + contraseña Código ASC

¡Aviso! La carga útil del mensaje CONNECT contiene uno o más campos con el prefijo de longitud, y el indicador de conexión en el encabezado de la variable determina si se
incluyen estos campos. Si se incluye, DEBE aparecer en este orden: Identificador de cliente, Asunto del testamento, Mensaje del testamento, Nombre de usuario, Contraseña

00 04 4D 51 54 54 | 04 | C2 | 00 78 | 00 09 35 32 38 39 38 36 38 37 35 | 00 06 32 34 38 34 39 33 | 3 6B

El encabezado fijo 0x10 significa que el cliente solicita conectarse al servidor. El
encabezado fijo 0x25 significa que el encabezado variable y la carga útil tienen un total de 37 bytes de datos, que no están incluidos en el
nombre del protocolo. 00 04 4D 51 54 54 , 00 04 significa 4 bytes, 4D 51 54 54 es la cadena codificada en UTF-8 (también valor de código ASC) del nivel 04 del protocolo MQTT
, el cliente usa un valor sin firmar de 8 bits para indicar la versión de revisión del protocolo. Para el protocolo de la versión 3.1.1, el valor del campo de nivel de protocolo es 4 (0x04), la
bandera de conexión C2
mantiene la conexión 00 78, es decir, 120 segundos
00 09 35 32 38 39 38 36 38 37 35 ID del dispositivo, 9 bytes, código ASC de 528986875, el mismo a continuación
00 06 32 34 38 34 39 33 ID de producto 248493
00 06 6B 66 62 73 6B 64 información de autenticación kfbskd

Mensaje de control N° 2: CONNACK – confirmar solicitud de conexión

Nota: El servidor envía un mensaje CONNACK en respuesta al mensaje CONNECT recibido del cliente. El primer paquete enviado por el servidor al cliente debe ser un paquete CONNACK.Si
el cliente no recibe el paquete CONNACK del servidor dentro de un tiempo razonable, el cliente debe cerrar la conexión de red. Un tiempo razonable depende del tipo de aplicación e infraestructura de comunicación.
El contenido del mensaje de control CONNACK:
el tipo de mensaje de 4 bits MQTT de encabezado fijo más 4 bits reservados es 20, y los bytes de longitud restantes están determinados por la longitud de datos subsiguiente Encabezado variable de
dos bytes: indicador de confirmación de conexión (los primeros 7 bits deben sea ​​0, el bit más bajo depende del indicador de sesión de limpieza en los indicadores de conexión) + código de retorno de conexión (normalmente 00, de lo contrario indica falla)
carga útil Ninguno

Ejemplo de mensaje:
20 02 01 00
encabezado fijo 20 02: 20 marcas tipo de mensaje 2, 02 longitud restante
encabezado variable 01 00
carga útil ninguno

Mensaje de control nº 3: PUBLICAR – publicar un mensaje

El mensaje de control PUBLICAR se refiere a la transmisión de un mensaje de aplicación del cliente al servidor o del servidor al cliente.
El cliente utiliza el mensaje PUBLISH para enviar el mensaje de la aplicación al servidor, con el fin de distribuirlo a otros clientes con suscripciones coincidentes.
El servidor usa el mensaje PUBLICAR para enviar el mensaje de la aplicación a cada cliente coincidente.

Composición del contenido del mensaje:
los 4 bits altos del primer byte del encabezado fijo son el tipo de mensaje 3, los 4 bits bajos son los bits reservados bajos del nivel QoS alto del nivel QoS de retransmisión DUP y el segundo byte es la longitud restante
Encabezado variable El encabezado variable contiene el nombre del asunto (codificación UTF-8) y el identificador del mensaje en secuencia. Hay dos bytes de nombre de tema antes del nombre de tema y el identificador de mensaje es de dos bytes.
Tenga en cuenta que el identificador de mensaje solo está presente en el mensaje de QoS clase 1 y 2, la clase 0 no se ignora directamente
Carga útil La carga útil contiene el mensaje de la aplicación que se publicará. El contenido y formato de los datos es específico de la aplicación. El cálculo de la longitud es la longitud restante: la longitud del encabezado variable

Con respecto al indicador de retransmisión de DUP: Si el indicador de DUP se establece en 0, significa que es la primera vez que el cliente o el servidor solicita enviar este mensaje PUBLICAR. Si el indicador DUP
se establece en 1, indica que esto puede ser una retransmisión de una solicitud de mensaje anterior.
El indicador DUP debe establecerse en 1 cuando el cliente o el servidor solicita volver a enviar un mensaje PUBLICAR. Para los mensajes QoS 0, la bandera DUP se establecerá en 0.

Con respecto a los bits de bandera del nivel de QoS: los paquetes PUBLISH no pueden establecer todos los bits de QoS en 1. Si el servidor o el cliente recibe un paquete PUBLICAR con todos los bits de QoS establecidos en 1, debe cerrar la conexión de red

Con respecto a los bits reservados: si el indicador RETAIN del mensaje PUBLISH enviado por el cliente al servidor se establece en 1, el servidor debe almacenar el mensaje de la aplicación y su calidad de servicio (QoS) para que pueda distribuirse a futuros Suscriptores cuyo tema coincidencia de nombres.
Si el cliente envía un mensaje de PUBLICACIÓN al servidor con el bit de indicador reservado 0, el servidor NO DEBE almacenar el mensaje ni eliminar o reemplazar ningún mensaje reservado existente.

Ejemplo de mensaje:
30 0E 00 09 6B 66 62 5F 74 6F 70 69 63 31 32 33 QoS nivel 0 datos: 123, nivel 0 sin respuesta

32 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 Nivel 1 Datos: 123

34 10 00 09 6B 66 62 5F 74 6F 70 69 63 00 01 31 32 33 Nivel 2 Datos: 123

El nombre del tema aquí es kfb_topic: 6B 66 62 5F 74 6F 70 69 63, antes del nombre del tema hay una longitud de dos bytes nombre del tema 00 09 el identificador del mensaje solo está
en el mensaje de QoS clase 1 y 2, en el ejemplo The el identificador del mensaje es 00 01

Mensaje de control nº 4: PUBACK – confirmación de liberación

El mensaje PUBACK es la respuesta al mensaje QoS 1 PUBLISH.

Composición del contenido del mensaje:
encabezado fijo tipo de mensaje 40 + longitud restante 02
encabezado variable contiene dos bytes de identificador de mensaje del mensaje PUBLISH en espera de confirmación. El contenido específico depende del identificador del mensaje en el mensaje PUBLICAR anterior.
Carga útil Ninguno

Ejemplo de mensaje:
40 02 00 01 Respuesta de nivel 1, indicando recibo
Encabezado fijo 40 02: 40 marcas tipo de mensaje 4, 02 longitud restante
Encabezado variable 00 01 es consistente con el identificador de mensaje de PUBLICAR mensaje esperando confirmación
Carga útil ninguno

Mensaje de control N° 5: PUBREC - liberación recibida (QoS 2, primer paso)

El mensaje PUBREC es la respuesta al mensaje PUBLICAR QoS clase 2. (Generalmente contestado por el receptor) Es el segundo mensaje intercambiado por el protocolo de nivel QoS 2.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo 50 + longitud restante 02
encabezado variable contiene dos bytes de identificador de mensaje del mensaje PUBLISH en espera de confirmación. El contenido específico depende del identificador del mensaje en el mensaje PUBLICAR anterior.
Carga útil Ninguno

Ejemplo de mensaje:
50 02 00 01 es la primera respuesta del servidor en el nivel 2, hay dos respuestas en el nivel 2, el cliente envía 62 02 00 01 nuevamente y la segunda respuesta 70 02 00 01 del servidor indica que el encabezado 50 02 se ha solucionado
con éxito: 40 marca el tipo de mensaje 5, 02 longitud restante
Cabecera variable 00 01 Consistente con el identificador de mensaje del mensaje PUBLICAR esperando confirmación
Sin carga útil

Paquete de control No. 6: PUBREL - publicar publicación (QoS 2, segundo paso)

El paquete PUBREL es la respuesta al paquete PUBREC. (Generalmente enviado por el remitente) Es el tercer mensaje intercambiado por el protocolo de nivel QoS 2.
¡Aviso! Los bits 3, 2, 1 y 0 del encabezado fijo del paquete de control PUBREL son bits reservados y deben establecerse en 0, 0, 1, 0. Los servidores DEBEN tratar cualquier otro valor como inválido y cerrar la conexión de red.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo 62 + longitud restante 02
encabezado variable contiene dos bytes de identificador de mensaje del mensaje PUBLISH en espera de confirmación. El contenido específico depende del identificador del mensaje en el mensaje PUBLICAR anterior.
Carga útil Ninguno

Ejemplo de mensaje:
62 02 00 01 Nivel 2 Preguntar de nuevo

Mensaje de control No. 7: PUBCOMP - publicación completa (QoS 2, paso 3)

El paquete PUBCOMP es la respuesta al paquete PUBREL. (Generalmente contestado por el receptor) Es el cuarto y último mensaje intercambiado por el protocolo de clase QoS 2.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo 70 + longitud restante 02
encabezado variable contiene dos bytes de identificador de mensaje del mensaje PUBLISH en espera de confirmación. El contenido específico depende del identificador del mensaje en el mensaje PUBLICAR anterior.
Carga útil Ninguno

Ejemplo de mensaje:
70 02 00 01 La segunda respuesta del nivel 2, que indica finalización completa

Mensaje de control No. 8: SUBSCRIBE - tema de suscripción

El cliente envía un mensaje SUBSCRIBE al servidor para crear una o más suscripciones.
Para reenviar mensajes de aplicación a temas que coincidan con esas suscripciones, el servidor envía un paquete PUBLICAR al cliente.
El mensaje SUBSCRIBE también especifica (para cada suscripción) el nivel máximo de QoS y el servidor envía mensajes de aplicación al cliente de acuerdo con esto.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo 82 +
identificador de mensaje de encabezado variable de longitud restante dos bytes.
Longitud del filtro de tema de carga útil 2 bytes + filtro de tema (+ [puede contener varios] longitud del último filtro de tema 2 bytes + filtro de tema +) nivel de calidad de servicio 1 byte solo los dos bits inferiores son válidos

La carga útil del paquete SUBSCRIBE debe contener al menos un par de combinaciones de campos de filtro de tema y clase de QoS.
Cada filtro va seguido de un byte, este byte se denomina requisito de calidad de servicio (QoS solicitada). Da el nivel máximo de QoS permitido por el servidor para enviar mensajes de aplicación al cliente.

Ejemplo de mensaje:
82 0E 00 0A 00 09 61 70 70 5F 74 6F 70 69 63 00 Nivel 0
82 0E 00 0B 00 09 61 70 70 5F 74 6F 70 69 63 01 Nivel 1
tema suscrito llamado app_topic: 61 70 7 0 5F 74 6F 70 69 63, el 00 09 anterior es la longitud del nombre del sujeto

Mensaje de control N° 9: SUBACK – confirmación de suscripción

El servidor envía un mensaje SUBACK al cliente para confirmar que ha recibido y está procesando el mensaje SUBSCRIBE.
El paquete SUBACK contiene una lista de códigos de retorno que especifican la clase máxima de QoS que se otorgará para cada suscripción solicitada por SUBSCRIBE.

Composición del contenido del mensaje:
encabezado fijo tipo de mensaje 90 + longitud restante
encabezado variable encabezado variable contiene el identificador del mensaje SUSCRÍBETE esperando confirmación. dos bytes
La carga útil es una respuesta calificada al último mensaje de tema de suscripción. El número de bytes es el mismo que el número de filtros de tema en el mensaje SUBSCRIBE anterior.
La carga útil contiene una lista de códigos de retorno. Cada código de retorno corresponde a un filtro de tema en el paquete SUBSCRIBE en espera de reconocimiento. El orden de los códigos de retorno DEBE ser el mismo que el orden de los filtros de tema en el mensaje de SUSCRIPCIÓN.
Valores de código de retorno permitidos:
0x00 - Max QoS 0
0x01 - Correcto - Max QoS 1
0x02 - Correcto - Max QoS 2
0x80 - Error

Ejemplo de mensaje:
90 03 | 00 0A | 00 corresponde al identificador de mensaje de la primera suscripción anterior
90 03 | 00 0B | 01 corresponde al identificador de mensaje de la segunda suscripción anterior

Mensaje de control nº 10: DARSE DE BAJA – dar de baja

El cliente envía un mensaje UNSUBSCRIBE al servidor para darse de baja del tema.

Composición del contenido del mensaje:
encabezado fijo mensaje tipo A2 + longitud restante
encabezado variable encabezado variable contiene un identificador de mensaje. dos bytes
Carga útil La carga útil del paquete UNSUBSCRIBE contiene una lista de filtros de temas de los que el cliente desea darse de baja. Longitud 2 bytes + filtro de asunto (+longitud 2 bytes + filtro de asunto)
La carga útil de un mensaje UNSUBSCRIBE debe contener al menos un filtro de mensaje.

Ejemplo de mensaje:
A2 0D 00 0C 00 09 61 70 70 5F 74 6F 70 69 63
00 0C es el identificador del mensaje
Nombre del tema app_topic, es decir, 61 70 70 5F 74 6F 70 69 63, el 00 09 anterior es la longitud

Mensaje de control nº 11: UNSUBACK – confirmación de baja

El servidor debe enviar un paquete UNSUBACK en respuesta a la solicitud UNSUBSCRIBE del cliente. El paquete UNSUBACK debe contener el mismo identificador de paquete que el paquete UNSUBSCRIBE

Composición del contenido del mensaje:
encabezado fijo tipo de mensaje B0 + longitud restante 02
encabezado variable El encabezado variable contiene el identificador del mensaje UNSUBSCRIBE esperando confirmación. dos bytes
Carga útil Ninguno

Ejemplo de mensaje:
B0 02 00 0C
00 0C corresponde al último identificador de mensaje dado de baja

Paquete de control No. 12: PINGREQ – solicitud de latido

El cliente envía un mensaje PINGREQ al servidor. Usado para:

1. Informe al servidor que el cliente todavía está vivo cuando no se envían otros paquetes de control desde el cliente al servicio.
2. Pide al servidor que envíe una respuesta confirmando que está vivo.
3. Use la red para verificar que la conexión de red no se pierda.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo C0 + longitud restante 00
encabezado variable sin
carga útil ningún
servidor debe enviar un mensaje PINGRESP para responder al mensaje PINGREQ del cliente

Telegram:
C0 00 (solo este)

Paquete de control No. 13: PINGRESP – respuesta de latido

El servidor envía un mensaje PINGRESP en respuesta al mensaje PINGREQ del cliente. Indica que el servidor todavía está activo.

Composición del contenido del mensaje:
tipo de mensaje de encabezado fijo D0 + longitud restante 00
encabezado variable sin
carga útil no

Mensaje:
D0 00 (solo este)

Mensaje de control nº 14: DESCONECTAR – desconectar

El paquete DISCONNECT es el último paquete de control enviado por el cliente al servidor. Indica que el cliente se desconectó "con gracia".

Composición del contenido del mensaje:
encabezado fijo tipo de mensaje E0 + longitud restante 00
encabezado variable sin
carga útil no

Mensaje:
E0 00 (solo este)

Nota: Después de que el cliente envíe el mensaje DESCONECTAR:
1. La conexión de red debe estar cerrada.
2. No se pueden enviar más paquetes de control a través de esa conexión de red.
Cuando el servidor recibe un paquete DISCONNECT:
1. DEBE descartar cualquier mensaje de testamento no publicado asociado con la conexión actual.
2. La conexión de red debe cerrarse, si el cliente aún no lo ha hecho.

Acerca del indicador de conexión en el mensaje de control CONNECT

Acerca del indicador de contraseña:
si el indicador de contraseña (Password) se establece en 0, la carga útil no puede contener un campo de contraseña.
Si el indicador de contraseña se establece en 1, se debe incluir un campo de contraseña en la carga útil.
Si el indicador de nombre de usuario se establece en 0, el indicador de contraseña también debe establecerse en 0.

Con respecto al indicador de nombre de usuario:
si el indicador Nombre de usuario (User Name) se establece en 0, la carga útil no puede contener un campo de nombre de usuario.
Si el indicador de nombre de usuario se establece en 1, se debe incluir un campo de nombre de usuario en la carga útil.

Con respecto al bit Will Retain:
si el indicador Will Retain se establece en 0, el indicador Will Retain también debe establecerse en 0.
Si el indicador de testamento se establece en 1:
1. Si el testamento reservado se establece en 0, el servidor DEBE publicar el mensaje de testamento como un mensaje no retenido.
2. Si la reserva de testamento se establece en 1, el servidor DEBE publicar el mensaje de testamento como un mensaje de reserva.

Acerca de los bits Will QoS:
estos dos bits se utilizan para especificar el nivel de calidad de servicio utilizado al publicar mensajes Will.
Si Will Flag se establece en 0, Will QoS también debe establecerse en 0 (0x00).
Si el indicador Will se establece en 1, el valor de Will QoS puede ser igual a 0 (0x00), 1 (0x01), 2 (0x02). Su valor no puede ser igual a 3.

Acerca del bit de indicador de voluntad:
el servidor emite el mensaje de voluntad, generalmente el mensaje publicado inmediatamente después de la desconexión. El
indicador de voluntad (Will Flag) se establece en 1, lo que indica que si se acepta la solicitud de Mensaje) carga útil) debe almacenarse en el servidor y asociarse con esta conexión de red. Posteriormente, cuando se cierra la conexión de red, el servidor debe publicar el mensaje de voluntad, a menos que el servidor elimine el mensaje de voluntad cuando recibe el mensaje de DESCONEXIÓN.

Condiciones para la publicación de noticias testamentarias, incluidas, entre otras, las siguientes:

• El servidor ha detectado un error de E/S o una falla en la red.
• El cliente no se comunica dentro del tiempo de Keep Alive.
• El cliente cierra la conexión de red sin enviar primero un mensaje de DESCONEXIÓN.
• El servidor cerró la conexión de red debido a un error de protocolo.

Si el indicador will se establece en 1, el servidor utilizará los campos Will QoS y Will Retain en el indicador de conexión, y los campos Will Topic y Will Message deben incluirse en la carga útil. Los mensajes DEBEN eliminarse del estado de sesión almacenado una vez publicados o al recibir el servidor un paquete DISCONNECT del cliente.
Si el indicador will se establece en 0, los campos Will QoS y Will Retain en el indicador de conexión deben establecerse en 0, y los campos Will Topic y Will Message no se pueden incluir en la carga útil. Cuando se desconecta la conexión de red, el servidor no puede enviar el mensaje de voluntad.
El servidor debe publicar rápidamente el mensaje de voluntad cuando se cumpla la condición. En caso de apagado o falla, el servidor PUEDE diferir la publicación de mensajes de testamento hasta un reinicio posterior.
Si esto sucede, puede haber una demora entre la falla del servidor y la publicación del mensaje del testamento.

Acerca de la limpieza de indicadores de sesión:
especifica cómo se maneja el estado de la sesión. Los clientes y servidores pueden guardar el estado de la sesión para admitir la transferencia confiable de mensajes a través de conexiones de red. Este indicador se utiliza para controlar
la duración del estado de la sesión.
Si el indicador CleanSession se establece en 1, el cliente y el servidor DEBEN descartar cualquier sesión anterior y comenzar una nueva. Una sesión solo dura lo que dura la conexión a la red. Los datos de estado asociados con esta sesión no pueden ser reutilizados por ninguna sesión posterior.
Los clientes con el indicador de sesión limpia establecido en 1 no recibirán mensajes de aplicaciones antiguos y deberán volver a suscribirse a cualquier tema relacionado después de cada conexión exitosa.
Para garantizar un estado coherente en caso de falla, el cliente debe solicitar repetidamente una conexión con el indicador de estado de sesión 1 hasta que la conexión se realice correctamente.
(generalmente establecido en 1)

Sobre el tiempo de actividad en el mensaje de control CONNECT

Keep Alive (Keep Alive) es un intervalo de tiempo en segundos, expresado como una palabra de 16 bits, que hace referencia al tiempo que transcurre entre el momento en que el cliente transmite un mensaje de control y el momento en que se envía el siguiente mensaje. tiempo permitido para estar inactivo. El cliente es responsable de garantizar que el intervalo de tiempo para enviar paquetes de control no supere el valor de keep-alive. Si no hay otros paquetes de control para enviar, el cliente DEBE enviar un paquete PINGREQ.
Independientemente del valor de keep-alive, el cliente puede enviar un mensaje PINGREQ en cualquier momento y utilizar el mensaje PINGRESP para determinar el estado de actividad de la red y el servidor.
Si el valor de keep-alive no es cero y el servidor no recibe el paquete de control del cliente dentro de 1,5 veces el tiempo de keep-alive, debe desconectar la conexión de red del cliente y considerar que la conexión de red está desconectada.
Después de que el cliente envíe el mensaje PINGREQ, si aún no recibe el mensaje PINGRESP dentro de un tiempo razonable, debe cerrar la conexión de red con el servidor.
Un valor de cero para keepalives desactiva los keepalives. Esto significa que el servidor no necesita desconectarse porque el cliente no está activo, es decir, siempre puede mantenerse conectado. Nota:
Independientemente del valor de keep-alive, en cualquier momento, siempre que el servidor crea que el cliente está inactivo o no responde, puede desconectarlo.
El valor real de los keepalives es específico de la aplicación, normalmente unos pocos minutos. El valor máximo permitido es de 18 horas 12 minutos y 15 segundos.