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

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.

Nivel de QoS 0: entrega Como máximo una vez
El mensaje se entrega utilizando al máximo las posibilidades de la red TCP/IP subyacente. No se espera ninguna respuesta y en el protocolo no se ha definido ninguna semántica de reintento. El mensaje llega al intermediario una vez o ninguna.

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
Nivel de QoS 1: entre Al menos una vez
El intermediario acusa el recibo de un mensaje mediante un mensaje PUBACK. Si hay una anomalía identificada del enlace de comunicaciones o del dispositivo de envío o bien el mensaje de acuse de recibo no se recibe después de un periodo de tiempo especificado, el emisor vuelve a enviar el mensaje con el bit DUP establecido en la cabecera de mensaje. El mensaje llega al intermediario una vez como mínimo. Los dos mensajes SUBSCRIBE y UNSUBSCRIBE utilizan el nivel de QoS 1.

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
DUP = 0
ID de mensaje = x

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

Acciones:
  • Almacenar mensaje en la base de datos
  • Publicar mensaje para los suscriptores
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.

Nivel de QoS 2: entrega exactamente una vez
Los flujos de protocolos adicionales por encima del nivel 1 de QoS aseguran que no se entreguen mensajes duplicados a la aplicación receptora. Este es el nivel de entrega más alto y se utiliza cuando no se aceptan mensajes duplicados. El tráfico en la red aumenta pero, normalmente resulta aceptable debido a la importancia del contenido del mensaje.

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
DUP = 0
ID de mensaje = x

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

Acción: Almacenar mensaje en la base de datos
 

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

ID de mensaje = x
ID de mensaje = x

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

Acciones:
  • Actualizar base de datos
  • Publicar mensaje para los suscriptores
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.

Supuestos para los niveles 1 y 2 de QoS

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.

Conceptos relacionados
WebSphere MQ Telemetry Transport
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac10850_