WebSphere MQ Telemetry Transport entrega los mensajes de acuerdo con los niveles definidos en una Calidad de servicio (QoS). Los niveles se describen a continuación.
La tabla que sigue muestra el flujo del protocolo QoS de nivel 0.
Cliente | Mensaje y dirección | Intermediario |
---|---|---|
QoS = 0 | PUBLISH |
Acción: Publicar mensaje para suscriptores |
Un mensaje con el nivel de QoS 1 tiene un ID de mensaje en la cabecera de mensaje.
La tabla que sigue muestra el flujo del protocolo QoS de nivel 1.
Cliente | Mensaje y dirección | Intermediario |
---|---|---|
QoS = 1 |
PUBLISH |
Acciones:
|
Acción: Descartar mensaje | PUBACK |
Si el cliente no recibe un mensaje PUBACK (dentro de un periodo de tiempo definido en la aplicación o si se detecta una anomalía y se reinicia la sesión de comunicaciones), el cliente vuelve a enviar el mensaje PUBLISH con el distintivo DUP establecido.
Cuando recibe un mensaje duplicado del cliente, el intermediario vuelve a publicar el mensaje para el suscriptores y envía otro mensaje PUBACK.
Un mensaje con el nivel de QoS 2 tiene un ID de mensaje en la cabecera de mensaje.
La tabla que sigue muestra el flujo del protocolo QoS de nivel 2.
Cliente | Mensaje y dirección | Intermediario |
---|---|---|
QoS = 2 |
PUBLISH |
Acción: Almacenar mensaje en la base de datos |
PUBREC |
ID de mensaje = x | |
ID de mensaje = x | PUBREL |
Acciones:
|
Acción: Descartar mensaje | PUBCOMP |
ID de mensaje = x |
Si se detecta un fallo o después de un periodo de tiempo definido, cada parte del flujo de protocolo se reintenta con el bit DUP establecido. Los flujos de protocolos adicionales aseguran que el mensaje se entregue una sola vez a los suscriptores.
Puesto que QoS1 y QoS2 indican que los mensajes se deben entregar, el intermediario almacena los mensajes en una base de datos. Si el intermediario tiene problemas al acceder a estos datos, es posible que los mensajes se pierdan. Si desea ver más información detallada y conocer las acciones que puede realizar para reducir estos problemas, consulte el apartado Diseñar aplicaciones de telemetría.
En cualquier red, es posible que fallen los dispositivos o los enlaces de comunicaciones. Si sucede esto, es posible que un extremo del enlace no sepa qué está sucediendo en el otro extremo; esto se conoce como ventanas dudosas. En estos escenarios hay que suponer la fiabilidad de los dispositivos y las redes que están implicados en la entrega de mensajes.
WebSphere MQ Telemetry Transport supone que el cliente y el intermediario son generalmente fiables y que probablemente el canal de comunicaciones no lo será. Si falla el dispositivo de cliente, normalmente será una anomalía grave, no una transitoria. Hay pocas posibilidades de recuperar datos del dispositivo. Algunos dispositivos tiene un almacenamiento no volátil, por ejemplo una memoria flash ROM. La provisión de almacenamiento más persistente en el dispositivo cliente protege los datos más críticos de determinados tipos de fallos.
Más allá de las anomalías básicas en el enlace de comunicaciones, la matriz del tipo de fallo se vuelve compleja, lo que produce más casos de los que la especificación para WebSphere MQ Telemetry Transport puede manejar.
El retardo de tiempo (intervalo de reintento) antes de volver a enviar un mensaje del que no hay acuse de recibo es específico de la aplicación y no lo define la especificación de protocolo.