O WebSphere MQ Telemetry Transport entrega mensagens de acordo com os níveis definidos em um QoS (Qualidade de Serviço). Os níveis são descritos abaixo:
A tabela abaixo mostra o fluxo de protocolo de nível 0 de QoS.
Client | Mensagem e Direção | Intermediário |
---|---|---|
QoS = 0 | PUBLISH |
Ação: Publicar mensagem para assinantes |
Uma mensagem com nível de QoS 1 possui um ID de Mensagem no cabeçalho da mensagem.
A tabela abaixo mostra o fluxo de protocolo de nível 1 de QoS
Client | Mensagem e Direção | Intermediário |
---|---|---|
QoS = 1 |
PUBLISH |
Ações:
|
Ação: Descartar mensagem | PUBACK |
Se o cliente não receber uma mensagem PUBACK (em um período de tempo definido no aplicativo, ou se for detectado um defeito e a sessão de comunicação for reiniciada), o cliente reenviará a mensagem PUBLISH com o conjunto de sinalizadores DUP.
Quando ele recebe uma mensagem duplicada do cliente, o intermediário publica novamente a mensagem para os assinantes e envia outra mensagem PUBACK.
Uma mensagem com nível de QoS 2 possui um ID de Mensagem no cabeçalho da mensagem.
A tabela abaixo mostra o fluxo de protocolo de nível 2 de QoS.
Client | Mensagem e Direção | Intermediário |
---|---|---|
QoS = 2 |
PUBLISH |
Ação: Armazenar mensagem no banco de dados |
PUBREC |
ID da Mensagem = x | |
ID da Mensagem = x | PUBREL |
Ações:
|
Ação: Descartar mensagem | PUBCOMP |
ID da Mensagem = x |
Se for detectado um defeito, ou após um período de tempo definido, cada parte do fluxo do protocolo será tentada novamente com o conjunto de bits DUP. Os fluxos de protocolo adicionais asseguram que a mensagem seja entregue aos assinantes apenas uma vez.
Pois QoS1 e QoS2 indicam que mensagens devem ser entregues, o intermediário armazena mensagens em um banco de dados. Se o intermediário tem problemas ao acessar esses dados, as mensagens podem ser perdidas. Para obter detalhes adicionais e para quais ações pode ser executadas para reduzir esses problemas, consulte Projetando Aplicativos de Telemetria.
Em qualquer rede, é possível que dispositivos ou links de comunicação falhem. Se isso acontecer, um final do link pode não saber o que está acontecendo no outro final; esses são conhecidos como janelas em dúvida. Nesses cenários, é necessário fazer algumas suposições sobre a confiabilidade dos dispositivos e redes envolvidos na entrega das mensagens.
O WebSphere MQ Telemetry Transport assume que o cliente e o intermediário geralmente são confiáveis e que o canal de comunicações provavelmente parece não ser confiável. Se o dispositivo cliente falhar, provavelmente será por um defeito catastrófico, em vez de um transitório. A possibilidade de recuperar dados do dispositivo é pequena. Alguns dispositivos possuem armazenamento não-volátil, por exemplo, ROM flash. A provisão de armazenamento mais persistente no dispositivo do cliente protege os dados mais importantes contra alguns modos de defeito.
Além do defeito básico do link de comunicações, a matriz do modo de defeito se torna complexa, resultando em mais cenários do que a especificação para WebSphere MQ Telemetry Transport pode tratar.
O retardo de tempo(intervalo de novas tentativas) antes de reenviar uma mensagem cujo recebimento não foi confirmado é específico do aplicativo e não é definido pela especificação de protocolo.