Calidad de niveles de servicio y flujos de WebSphere MQ Telemetry Transport

WebSphere MQ Telemetry Transport entrega mensajes de acuerdo con los niveles definidos en un servicio de calidad (Qos). A continuación se describen los niveles:

Nivel de QoS 0 "Como máximo una" entrega

El mensaje se entrega de acuerdo con el funcionamiento de la red TCP/IP subyacente. No se espera una respuesta y no se definen semánticas de reintentos en el protocolo. El mensaje llega al intermediario una vez o no llega.

Nivel de QoS 1 "Al menos una" entrega

La recepción de un mensaje por el intermediario y, si procede, su colocación en una cola de WebSphere MQ, se reconoce mediante un mensaje PUBACK. Si se produce una anomalía identificada en el enlace de comunicaciones o en el dispositivo emisor, o no se recibe el mensaje de reconocimiento una vez transcurrido un periodo de tiempo especificado, el emisor vuelve a enviar el mensaje con el bit DUP establecido en la cabecera del mensaje. El mensaje llega al intermediario al menos una vez.

Nivel de QoS 2 "Exactamente una" entrega

Los flujos de protocolos adicionales por arriba del nivel de QoS 1 garantizan que no se entreguen mensajes duplicados a la aplicación receptora. Este es el nivel de entrega más alto que se utiliza cuando no se aceptan mensajes duplicados. Hay un aumento en el tráfico de la red, pero en general se acepta debido a la importancia del contenido del mensaje.

Determinadas clases de anomalía pueden causar que no se entreguen los mensajes con nivel de QoS 1 o 2.

Un mensaje con el nivel de QoS 1 o 2 tiene un ID de mensaje en la cabecera del mensaje.

Supuestos para los niveles de QoS 1 y 2

Antes de desarrollar una aplicación que utiliza WebSphere MQ Telemetry Transport, debe tener en cuenta las suposiciones detrás de los niveles de QoS 1 y 2.

Algunos aspectos de entrega "garantizada" y "fiable" están llenos de problemas. Es difícil lograr una entrega "garantizada" en todas las circunstancias debido a la aparición de ventanas "pendientes", donde un dispositivo falla y el sistema se queda en un estado en el que un extremo del enlace no sabe lo que ocurre en el otro extremo. Es necesario establecer algunos supuestos sobre la fiabilidad de los dispositivos y las redes implicados en la entrega de mensajes y concluir que se tienen muchas posibilidades de entregar los mensajes de forma fiable.

WebSphere MQ Telemetry Transport da por supuesto que el cliente y el intermediario son normalmente fiables y que lo más probable es que el canal de comunicaciones sea poco fiable. Si se produce una anomalía en el dispositivo de cliente, lo más probable es que sea catastrófica en lugar de pasajera. Hay pocas posibilidades de recuperar datos del dispositivo. Algunos dispositivos tienen almacenamiento no volátil, como por el ejemplo memoria flash ROM . El aprovisionamiento de almacenamiento permanente en el dispositivo del cliente protege los datos más críticos de algunos tipos de anomalías.

Además de la anomalía básica en el enlace de comunicaciones, la matriz de modalidades de anomalías se vuelve compleja, lo que genera más casos de los que la especificación de WebSphere MQ Telemetry Transport puede manejar.

Reintentos

El retardo antes de volver a enviar un mensaje que no se ha reconocido depende de la aplicación y no está definido por la especificación de protocolo.

Flujos de protocolos de QoS

Los niveles de QoS están soportados por flujos de protocolos que definen la secuencia de los flujos de mensajes entre el cliente y el intermediario.

Flujo de protocolos de nivel de QoS 0

En la tabla siguiente se muestra el flujo de protocolos de nivel de QoS 0.

Cliente Mensaje y dirección Intermediario
QoS = 0

PUBLISH
---------->

Acción: Publicar mensaje para suscriptores

Flujo de protocolos de nivel de QoS 1

En la tabla siguiente se muestra el flujo de protocolos de nivel de QoS 1.

Cliente Mensaje y dirección Intermediario

QoS = 1
DUP = 0
ID de mensaje = x

PUBLISH
---------->

Acción: publicar mensaje para suscriptores
Acción: descartar mensaje

PUBACK
<----------

 

Si el cliente no recibe un mensaje PUBACK (dentro del periodo de tiempo definido en la aplicación o si se detecta una anomalía y se vuelve a iniciar 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 los suscriptores y envía otro mensaje PUBACK.

Flujo de protocolo de nivel de QoS 2

En la tabla siguiente se muestra el flujo de protocolo de nivel de QoS 2.

Cliente Mensaje y dirección Intermediario

QoS = 2
DUP = 0
ID de mensaje = x

PUBLISH
---------->

Acción: anotar mensaje al almacén persistente
 

PUBREC
<----------

ID de mensaje = x
ID de mensaje = x

PUBREL
---------->

Acción: publicar mensaje para suscriptores
Acción: descartar mensaje

PUBCOMP
<----------

ID de mensaje = x

Si se detecta una anomalía 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 garantizan que el mensaje se entregue a los suscriptores sólo una vez. Tanto los mensajes SUBSCRIBE como los mensajes UNSUBSCRIBE utilizan el nivel de QoS 1.

Conceptos relacionados
WebSphere MQ Telemetry Transport

Referencia relacionada
Cabecera variable de WebSphere MQ Telemetry Transport
Mensajes de mandatos de WebSphere MQ Telemetry Transport