Protocolo MQTT
O protocolo MQTT é um dos padrões de comunicação disponíveis nos equipamentos da HI Tecnologia.
Esta sessão apresenta o protocolo, define os conceitos associados e os recursos disponíveis nas bibliotecas de comunicação do Portal de Telemetria para utilização do protocolo MQTT em aplicações.
Introdução ao protocolo MQTT
MQTT , Message Queue Telemetry Transport(Transporte de Filas de Mensagem de Telemetria) é um protocolo de comunicação entre máquinas (Machine to Machine - M2M) desenvolvido através de uma parceria entre a IBM e Eurotech em 1999.
Seu objetivo original foi viabilizar a comunicação de sensores fisicamente distribuídos em oleodutos com sistema de satélites para permitir a monitoração remota do transporte do petróleo. Foi projetado com as seguintes premissas principais:
Ser portado para equipamentos (sensores) com poucos recursos computacionais;
Possuir baixa largura de banda pois o custo da comunicação via satélite era elevado;
Operar em equipamentos com baixo consumo de energia;
Este protocolo permaneceu restrito às empresas desenvolvedoras até 2010 quando foi liberado para utilização pública gratuitamente e, em 2014 a versão 3.1 se tornou um protocolo padrão aberto da OASIS (Organization of the Advanced of Structured Information Standard).
Sendo um padrão aberto, um grande número de empresas começou a se interessar em implementar o padrão em suas soluções de conectividade.
Com surgimento dos conceitos de Internet das Coisas (IOT) e indústria 4.0 na última década, a conectividade entre dispositivos se tornou mandatória, tornando hoje o MQTT, um dos protocolos de comunicação mais utilizados para a interconexão de equipamentos através da internet.
Fig. 16 Exemplo de comunicação de dispositivos via o protocolo MQTT.
Portanto, o protocolo MQTT é utilizado atualmente em automação industrial, comercial e residencial, focado em disponibilizar a troca de informações entre dispositivos, funcionalidade denominada de M2M (machine to machine). Com a expansão dos dispositivos IOT (internet of things) o protocolo MQTT vem se tornado um padrão de fato para interconexão destes elementos.
Algumas das características do MQTT explicam a popularidade deste protocolo:
Simples codificação, o que facilita que o MQTT funcione em sistemas não tão modernos ou com problemas de armazenamento;
Padrão de comunicação aberto, permitindo sua utilização sem custos de royalty;
Consegue ser incorporado em dispositivos com poucos recursos de memória e processamento;
Consumo de banda de dados mínimo e configurável pela aplicação;
Apenas as mensagens assinadas no broker serão encaminhadas para o dispositivo, não existindo tráfego inútil;
Informações são publicadas quando necessário para o(s) outros dispositivos não sendo necessário polling de dados, o que aumenta a banda de dados e diminui a latência(tempo necessário para que a informação chegue ao seu destino);
Excelente performance em aplicações e serviços que não demandam alta taxa de dados;
Inerentemente distribuído, ou seja, permite a conexão entre dois dispositivos localizados em qualquer lugar do mundo desde que tenha acesso a internet através de qualquer meio(rede física, celular, satélite etc);
Uma dada mensagem importante pode ficar armazenada no broker e ser transmitida para um cliente quando este se conectar, aumentando a confiabilidade da solução de comunicação;
Existem recursos no protocolo para garantir que uma dada mensagem seja entregue ao equipamento destino aumentando a segurança da solução.
Como funciona o protocolo MQTT
Como mencionado na introdução, o protocolo MQTT foi criado para permitir a troca de dados entre 2 ou mais dispositivos.
Vamos imaginar um cenário real para entendermos como o protocolo MQTT funciona.
Considere que uma pessoa deseje monitorar a temperatura da água de seu aquário de casa através do seu Smartwatch(relógio inteligente).
Fig. 17 Sensor de temperatura envia valor (20 oC) para um Smartwatch.
O valor da temperatura TEMP é a informação que o protocolo de comunicação será responsável por transferir do aquário (DEV_A) para o Smartwatch (DEV_B).
Sendo assim, podemos representar este cenário da seguinte forma:
Fig. 18 Dispositivo DEV_A envia valor TEMP para dispositivo DEV_B
O principal problema para conseguir que a informação do sensor chegue ao Smartwatch é que o sensor de temperatura não tem nenhuma informação sobre o que é, e tão pouco onde esta o Smartwatch e, analogamente o Smartwatch também não “conhece” o sensor de temperatura.
Para solucionar esta questão o protocolo MQTT cria um elemento concentrador denominado Broker MQTT.
Fig. 19 Dispositivo DEV_A se comunica com o dispositivo DEV_B através de um Broker MQTT.
Basicamente, o Broker MQTT é um programa de aplicação que roda em um servidor dentro de uma intranet ou na nuvem e aceita conexões de Cliente MQTT em uma porta específica. Para maiores detalhes, acesse a seção Broker MQTT.
Portanto, todos os dispositivos que necessitarem enviar dados (sensor de temperatura) ou receber dados (Smartwatch) se comunicam com o Cliente MQTT e este será o responsável por receber a informação gerada pelo sensor de temperatura e envia-la para o Smartwatch.
Note que, com esta abordagem, o sensor não necessita de nenhuma informação do Smartwatch para enviar o valor da temperatura (TEMP).
Da mesma forma, o Smartwatch também não necessita de nenhuma informação sobre o sensor de temperatura. Os dois dispositivos necessitam saber apenas como acessar o Cliente MQTT e isto é definido pelo protocolo MQTT.
Arquitetura de comunicação MQTT
O protocolo de comunicação MQTT utiliza um padrão de troca de mensagens denominado Publisher/Subscriber ou Publicador-Assinante para tornar possível que a informação do DEV_A chegue até ao DEV_B.
O padrão Publish/Subscriber especifica uma forma de interconexão para troca de informações entre dois ou mais dispositivos. É largamente utilizado em computação em vários cenários, sendo utilizado por inúmeros protocolos de comunicação além do protocolo MQTT.
Com este padrão, é possível dizermos que dispositivos e serviços podem se comunicar de forma assíncrona e independente.
Além disso, toda informação que é enviada ou recebida(através do Broker MQTT) deve possuir um nome ou identificador e também um conteúdo(chamado de carga útil ou payload da mensagem).
No protocolo MQTT, a identificação associada a informação é denominada como Tópico (para maiores detalhes, acesse Definição de Tópicos MQTT).
Sendo assim, no nosso exemplo, o tópico a ser transmitido pelo sensor de temperatura se chama TEMP e a carga útil, ou seja, o valor de temperatura do mesmo, é 20 oC.
Portanto, o tópico é a única informação que é necessária tanto ao Sensor de temperatura quanto ao Smartwatch para que os valores (carga útil da mensagem) possam ser trocados através do protocolo MQTT.
Como citado acima, o padrão Publish(publicador)/Subscriber(assinante) utiliza o Broker MQTT (elemento concentrador) que tem por função principal receber as mensagens dos dispositivos que querem enviar informações de tópicos (denominados publishers) e enviá-las para os dispositivos que assinaram estes tópicos (denominados subscribers).
Todos os equipamentos que quiserem trocar dados são denominados de Cliente MQTT e devem se conectar a um Broker MQTT para que o envio e recepção das informações ocorra.
Fig. 20 Conexão dos clientes MQTT (DEV_A e DEV_B) ao BROKER
Uma vez conectados ao Broker MQTT, a sequência a seguir ilustra as etapas necessárias para que o tópico TEMP seja enviado pelo dispositivo DEV_A e recebido pelo dispositivo DEV_B.
Fig. 21 Padrão Publisher/Subscriber.
Na etapa 1, o dispositivo DEV_B deve assinar(Subscribe) o tópico TEMP no Broker MQTT.
Com esta ação, o Broker MQTT sabe que, quando receber alguma publicação do tópico TEMP deverá reenvia-la para o dispositivo DEV_B.
Na etapa 2 o dispositivo DEV_A publica (Publish) o tópico TEMP com o valor 20 oC.
Na etapa 3 assim que o tópico é recebido pelo Broker MQTT, este é publicado novamente para o DEV_B.
Desta forma, sempre que o dispositivo DEV_A publicar o tópico TEMP este será recebido pelo dispositivo DEV_B.
A partir deste momento, qualquer outro dispositivo que necessitar da informação do tópico TEMP basta se conectar ao Broker MQTT e assinar este tópico pois, o broker é responsável por publicar o tópico recebido para todos os Cliente MQTT que assinarem o mesmo.
Elementos do Protocolo MQTT
O MQTT é aplicado em automação industrial, comercial e residencial, focado em disponibilizar a troca de informações entre dispositivos, funcionalidade denominada de M2M (machine to machine). Com a expansão dos dispositivos IOT (internet of things) o protocolo MQTT vem se tornado um padrão de fato para interconexão destes elementos.
Basicamente, o protocolo MQTT possui apenas dois elementos:
Fig. 22 Exemplo da interação entre os elementos do protocolo MQTT.
Broker MQTT
O Broker MQTT é considerado o coração do protocolo MQTT, por ser o elemento que viabiliza todo o funcionamento do protocolo.
Ele tem como principal função receber, filtrar e encaminhar as mensagens entre o Publicadores(publishers) e os Assinantes(subscribers), ou seja, funciona como um intermediário entre os Cliente MQTT.
Além disso, outra função que o broker desempenha é de armazenamento de dados, tanto as informações de registro dos assinantes, como as informações publicadas.
Outra responsabilidade do broker é o gerenciamento de segurança como autenticação e autorização dos clientes.
Normalmente, existem duas maneiras de implementar recursos que aumentam a segurança na rede MQTT: o uso de TSL/SSL que faz a encriptação dos dados que trafegam e a autenticação e autorização como mencionado anteriormente, utilizando nome de usuário e senha e/ou utilizando certificados X.509.
Os dados “dentro” de um broker são armazenados em tópicos e, desta forma, os Assinantes escolhem quais os tópicos querem se inscrever para receber apenas os que lhes convém.
Em outras palavras, o broker recebe todas as mensagens, filtra e decide quem está interessado e inscrito em cada uma.
O Broker pode ser tanto um servidor local na intranet ou rede corporativa de uma empresa, como uma estrutura totalmente em nuvem.
Cliente MQTT
Um Cliente MQTT é o elemento responsável por publicar mensagens para um Broker MQTT e/ou assinar mensagens no Broker MQTT para recebê-las após as publicações, ou seja, considerando a arquitetura de comunicação do protocolo MQTT, os Publicadores(publishers) e Assinantes(subscribers) são Clientes MQTT.
Um cliente MQTT pode ser qualquer dispositivo(de um microcontrolador até um servidor completo) que executa uma biblioteca MQTT e se conecta a um Broker MQTT em uma rede.
Por exemplo, o cliente MQTT pode ser um dispositivo muito pequeno, com recursos limitados, que se conecta a um Broker MQTT por meio de uma rede wireless e possui uma biblioteca mínima.
No nosso exemplo utilizado na introdução ao protocolo MQTT, o Sensor de Temperatura(DEV A) e o Smartwatch(DEV B) são clientes MQTT que interagem através do Broker MQTT.
A HI Tecnologia, disponibiliza diversos Controladores Lógicos Programáveis(CLPs) com suporte nativo ao protocolo MQTT:
NEON - G5;
RION - G5;
P7C - G5;
GTON - P.
Portanto, qualquer dispositivo que “fale” MQTT em uma pilha TCP/IP pode ser chamado de cliente MQTT.
A implementação do cliente do protocolo MQTT normalmente é direta e simplificada. A facilidade de implementação é um dos motivos pelos quais o MQTT é ideal para dispositivos pequenos.
As bibliotecas do cliente MQTT estão disponíveis para uma grande variedade de linguagens de programação. Por exemplo, Python, Arduino, C, C ++, C#, Go, iOS, Java, JavaScript e .NET. Você pode ver uma lista completa na wiki MQTT .
Relação Broker x Clientes MQTT
O processo de conexão de clientes com o Broker
No protocolo MQTT, nenhum Cliente MQTT transmite ou recebe dados de um para outro cliente diretamente. Toda a comunicação dos clientes é realizada através do Broker MQTT.
Portanto, Antes de iniciar o processo de publicação e assinaturas de tópicos, um Cliente MQTT necessita se conectar ao Broker MQTT, trocando as seguintes mensagens:
Fig. 23 Sequência de conexão de um Cliente MQTT com um BROKER.
No processo de conexão, o Cliente MQTT abre uma conexão com o Broker MQTT (normalmente uma conexão TCP/IP) através de uma mensagem do tipo CONNECT, especificando um identificador da conexão normalmente chamado de CLIENT_ID(ou ID de cliente), uma identificação de usuário e uma senha.
A obrigatoriedade destes parâmetros é dependente da implementação do Broker MQTT em que se deseja conectar e caso sejam obrigatórios, qualquer informação incorreta neste processo faz com que o Broker MQTT recuse a conexão do Cliente MQTT, cancelando o processo.
Quando o processo de conexão é aceito pelo Broker MQTT, este envia uma mensagem do tipo CONNACK para o Cliente MQTT, confirmando que processo foi realizado com sucesso.
Quando o Cliente MQTT terminar de publicar os tópicos desejados e não necessitar receber mais tópicos do broker, o mesmo pode se desconectar enviando uma mensagem do tipo DISCONNECT.
Ao receber esta mensagem o Broker MQTT fecha a conexão TCP/IP com o Cliente MQTT.
Fig. 24 Sequência de desconexão de um Cliente MQTT com um BROKER.
MQTT Keep Alive
O MQTT inclui uma função chamada de Keep Alive(mantenha vivo) que possibilita avaliar se a conexão ainda está aberta entre um Cliente MQTT e um Broker no cenário em que eventualmente não há mais troca de informações entre eles.
Quando um cliente estabelece uma conexão com o Broker, este cliente comunica um intervalo de tempo em segundos ao Broker e este intervalo define o período máximo de tempo que o broker e o cliente podem operar sem trocar nenhuma informação, ou seja, o tempo que ficam sem se comunicar.
Na especificação do protcolo MQTT, o Keep Alive é definido da seguinte forma:
“O Keep Alive é o intervalo de tempo máximo que é permitido transcorrer entre o ponto em que o Cliente termina de transmitir um Pacote de Controle e o ponto em que ele começa a enviar o próximo. É responsabilidade do Cliente garantir que o intervalo entre os Pacotes de Controle enviados não exceda o valor Keep Alive. Na ausência de envio de quaisquer outros Pacotes de Controle, o Cliente DEVE enviar um Pacote PINGREQ.” Desde que as mensagens sejam trocadas com frequência e o intervalo keep-alive não seja excedido, não há necessidade de enviar uma mensagem extra para estabelecer se a conexão ainda está aberta.”
Caso o cliente não envie uma mensagem durante o período de Keep Alive, ele deve enviar um pacote PINGREQ ao broker para confirmar que está disponível e para certificar-se de que o Broker também ainda está disponível.
O Broker deve desconectar um cliente que não envia uma mensagem ou um pacote PINGREQ em uma vez e meia o intervalo Keep Alive.
Da mesma forma, espera-se que o cliente feche a conexão se não receber uma resposta do Broker em um período de tempo razoável.
Fig. 25 Sequência de mensagem para avaliação de conexão(Keep Alive) entre um Cliente MQTT e um BROKER.
Assinatura de tópicos
Uma vez realizada a conexão com sucesso (resposta do Broker MQTT com a mensagem CONACK), caso o Cliente MQTT deseje receber os valores de tópicos do Broker MQTT, este deve informar quais tópicos deseja receber as informações.
Este processo no protocolo MQTT consiste no envio pelo Cliente MQTT de uma mensagem do tipo SUBSCRIBE para o Broker MQTT informando qual é a identificação do tópico que deseja receber os valores, conforme exemplificado na figura a seguir:
Fig. 26 Sequência de conexão de um Cliente MQTT com um BROKER e assinatura de um tópico(TEMP).
Se o Broker MQTT processou corretamente a mensagem recebida, este envia uma mensagem do tipo SUBACK para o cliente confirmando que o nome do tópico especificado foi registrado no broker com sucesso.
Atenção
Eventualmente, a implementação do Broker MQTT pode exigir que a conexão MQTT tenha autorização para assinar tópicos. Neste caso, o Broker MQTT pode utilizar as informações de client_id e/ou usuário para permitir a assinatura de determinado tópico(s).
Normalmente, o Cliente MQTT, após a conexão com o Broker MQTT, assina todos os tópicos que desejar receber de qualquer outro cliente.
Note que, apenas os tópicos que forem assinados (subscribed) serão enviados pelo Broker MQTT para este cliente. O Cliente MQTT não necessita de saber qualquer informação sobre quem irá enviar a informação que ele assinou, apenas a identificação do tópico e seus valores serão recebidos.
Publicação de Tópicos
Após o processo de assinatura (subscribe) dos tópicos desejados ou não (clientes podem apenas publicar informações), um Cliente MQTT publicar seus tópicos e irão receber do broker os tópicos assinados sempre que forem publicados por qualquer Cliente MQTT conectado ao mesmo Broker MQTT.
O processo de publicação consiste no envio de uma mensagem para o broker especificando o tópico e o valor conforme apresentado na figura a seguir.
Fig. 27 Sequência de conexão de um Cliente MQTT com um BROKER , assinatura de um tópico e publicação.
A figura F12 apresenta a sequencia de troca de informações do nosso cenário de exemplo, onde o Cliente MQTT DEV_B (Smartwatch) se conecta no broker a assina o tópico TEMP.
Em seguida o Cliente MQTT DEV_A (sensor de temperatura do aquario) se conecta ao broker e publica o valor de temperatura no tópico TEMP.
Esta informação quando recebida pelo Broker MQTT é retransmitida para o DEV_B (Smartwatch) que apresenta ao usuário a temperatura do aquário.
Atenção
Eventualmente, a implementação do Broker MQTT pode exigir que a conexão MQTT tenha autorização para publicar em tópicos. Neste caso, o Broker MQTT pode utilizar as informações de client_id e/ou usuário para permitir a publicação de determinado tópico(s).
Definição de Tópicos MQTT
No protocolo MQTT, um Tópico se refere a uma sequência UTF-8 que representa um endereço para qual uma mensagem será encaminhada, ou seja, um Publicador cria o endereço e o Assinante se inscreve naquele endereço para receber as informações.
Portanto, um tópico nada mais é do que uma forma de endereçamento utilizada por Cliente MQTT para compartilhar informações através de um Broker MQTT.
A estrutura de um tópico MQTT consiste em um ou mais níveis de agrupamento. Cada nível de tópico é separado por uma barra “/” (separador de nível de tópico).
Aqui estão alguns exemplos de tópicos:
casa/quarto/temperatura
brasil/bahia/salvador/numero-habitantes
9a3547bc/umidade
Observe que cada tópico deve conter pelo menos 1 caractere e os tópicos diferenciam maiúsculas de minúsculas.
Por exemplo, casa/quarto/temperatura e Casa/Quarto/Temperatura são dois tópicos diferentes.
Curingas (Wildcards)
Quando um Assinante se inscreve em um tópico, ele pode se inscrever no tópico exato de uma mensagem publicada ou pode utilizar curingas para se inscrever em vários tópicos simultaneamente.
Um curinga só pode ser utilizado para assinar tópicos e não para publicar uma mensagem.
Existem dois tipos diferentes de curingas: nível único(+) e múltiplos níveis(#).
Nível único: +
Como o nome sugere, um curinga de nível único substitui um nível de tópico. O símbolo de “+” representa um curinga de nível único em um tópico.
Qualquer tópico irá corresponder a um tópico com curinga de nível único se contiver uma sequência arbitrária em vez do curinga.
Por exemplo, uma assinatura de um tópico casa/+/temperatura pode produzir os seguintes resultados:
casa/sala-de-estar/temperatura
casa/quarto/temperatura
casa/cozinha/temperatura
Múltiplos níveis: #
O curinga de múltiplos níveis cobre os eventuais níveis definidos em um tópico. O símbolo de “#” representa o curinga de múltiplos níveis no tópico.
Para que o Broker MQTT determine quais tópicos correspondentes, o curinga de múltiplos níveis deve ser colocado obrigatoriamente como o último caractere no tópico e ser precedido por uma barra.
Quando um cliente se inscreve em um tópico com um curinga de múltiplos níveis, ele recebe todas as mensagens de um tópico que começa com o padrão definido antes do caractere curinga, não importando a extensão ou profundidade do tópico.
Por exemplo, a assinatura de todos os tópicos associados a ao nível “casa/”:
casa/#
Qualidade de serviço - QoS
O nível de Qualidade de Serviço (QoS) é um acordo entre o Publicador(remetente de uma mensagem e o receptor de uma mensagem que define a garantia de entrega de uma mensagem específica. Existem 3 níveis de QoS no MQTT:
No máximo uma vez (0);
Pelo menos uma vez (1);
Exatamente uma vez (2).
Quando falamos sobre QoS em MQTT, precisamos considerar os dois lados da entrega da mensagem:
Entrega de mensagens do Cliente da Publicação para o Broker MQTT;
Entrega de mensagens do Broker MQTT para o Cliente Assinante.
Veremos os dois lados da entrega da mensagem separadamente, pois existem diferenças sutis entre os dois. O cliente que publica a mensagem para o Broker MQTT define o nível de QoS da mensagem ao envia-la ao Broker MQTT.
Já o Broker MQTT transmite essa mensagem para clientes assinantes usando o nível de QoS que cada cliente assinante define durante o processo de assinatura.
Se o cliente assinante definir um QoS inferior ao do cliente da publicação, o Broker MQTT transmitirá a mensagem com a qualidade de serviço inferior.
Portanto, o QoS provê ao cliente a capacidade de escolher um nível de serviço que corresponda à confiabilidade da rede e à lógica de sua implementação.
Como o MQTT gerencia a retransmissão de mensagens e garante a entrega (mesmo quando o transporte subjacente não é confiável), o QoS torna a comunicação em redes não confiáveis muito mais fácil.
Abaixo segue uma descrição de como cada nível de QoS é implementado no protocolo MQTT e como funcionam:
QoS 0 - no máximo uma vez
A mensagem é entregue no máximo uma vez (at most once) ou não é entregue de modo algum.
Sua entrega na rede não é reconhecida. A mensagem não é armazenada. A mensagem poderá ser perdida se o cliente for desconectado ou se o servidor falhar.
É o modo de transferência mais rápido sendo chamado “fire and forget”.
O Protocolo MQTT não requer que o broker encaminhe publicações no QoS=0 para um cliente caso este esteja desconectado no momento em que o broker receber a publicação.
A grande vantagem da publicação com QoS=0 é a economia de banda pois os dados que são trafegados se resumem ao nome e valor do tópico e não existem mensagens de reconhecimento.
Fig. 28 Sequência de mensagens MQTT utilizando o QoS = 0.
QoS 1 - pelo menos uma vez
QoS = 1 é o modo de transferência padrão no protocolo MQTT.
A mensagem é sempre entregue no mínimo uma vez (at least once).
Se o emissor não receber uma confirmação, a mensagem será enviada novamente com o sinalizador DUP configurado até que uma confirmação seja recebida.
Como resultado, o receptor pode receber a mesma mensagem diversas vezes e processá-la diversas vezes.
A mensagem deve ser armazenada localmente no emissor e no receptor até ser processada. A mensagem será excluída do receptor após ter processado a mensagem.
Se o receptor for um broker, a mensagem será publicada para seus assinantes. Se o receptor for um cliente, a mensagem será entregue para a aplicação associada.
Após a mensagem ser excluída, o receptor enviará uma confirmação para o emissor. A mensagem será excluída do emissor após ter recebido uma confirmação do receptor.
Fig. 29 Sequência de mensagens MQTT utilizando o QoS = 1.
QoS 2 - exatamente uma vez
A mensagem é sempre entregue exatamente uma vez (exactly once).
A mensagem deve ser armazenada localmente no emissor e no receptor até ser processada. QoS = 2 é o mais seguro e o modo de transferência mais lento.
Ele levará pelo menos dois pares de transmissões entre o emissor e o receptor antes de a mensagem ser excluída do emissor. A mensagem poderá ser processada no receptor após a primeira transmissão.
No primeiro par de transmissões, o emissor transmite a mensagem e recebe a confirmação do receptor de que ele armazenou a mensagem. Se o emissor não receber uma confirmação, a mensagem será enviada novamente com o sinalizador DUP configurado até que uma confirmação seja recebida.
No segundo par de transmissões, o emissor informa ao receptor que ele pode concluir o processamento da mensagem, “PUBREL”. Se o emissor não receber uma confirmação da mensagem “PUBREL”, a mensagem “PUBREL” será enviada novamente até que uma confirmação seja recebida.
O emissor excluirá a mensagem que salvou ao receber a confirmação para a mensagem “PUBREL”.
O receptor poderá processar a mensagem na primeira ou na segunda fase, contanto que não reprocesse a mensagem.
Se o receptor for um broker, ele publicará a mensagem para os assinantes. Se o receptor for um cliente, ele entregará a mensagem para a aplicação associada.
O receptor envia uma mensagem de conclusão de volta “PUBCOMP” para o emissor que concluiu o processamento da mensagem.
Fig. 30 Sequência de mensagens MQTT utilizando o QoS = 2.
Mensagens Retidas(Retained Messages)
Normalmente, quando se publica uma mensagem em um tópico e ninguém (nenhum cliente) está inscrito nesse tópico, a mensagem é simplesmente descartada pelo Broker MQTT.
No entanto, o Publicador pode dizer ao Broker MQTT para manter a última mensagem nesse tópico, definindo o sinalizador de mensagem retida.
Fig. 31 Sequência de mensagens MQTT utilizando o flag retain = true(publicação retentiva).
Portanto, uma mensagem retida é uma mensagem MQTT normal com o sinalizador de retenção(retain) configurado como verdadeiro. Para essas mensagens, o Broker MQTT manterá a última mensagem e o nível de QoS correspondente armazenados para o tópico.
O que é importante entender é que apenas uma mensagem é retida por tópico. A próxima mensagem publicada nesse tópico substitui a última mensagem retida para aquele tópico.
Uma mensagem retida faz sentido quando é desejado que os assinantes recém conectados recebam mensagens imediatamente (sem esperar até que um cliente de publicação envie a próxima mensagem).
Em outras palavras, uma mensagem retida em um tópico é o último valor válido conhecido.
Sessões Persistentes(Clean Sections)
Na conexão com o Broker MQTT, um Cliente MQTT deve definir um parâmetro chamado de sinalizador de sessão limpa (clean section).
Se a sessão limpa da conexão for definida como falsa, a conexão será tratada como persistente(chamada de durável também).
Isso significa que, quando o cliente se desconectar, todas as suas assinaturas permanecerão registradas no Broker MQTT e todas as mensagens de QoS 1 ou 2(dependendo da implementação do broker) subsequentes serão armazenadas até que cliente se conecte novamente no futuro.
Neste caso, o Cliente MQTT deve obrigatoriamente informar um ID de Cliente(client_id) na abertura da conexão pois é com está informação que o Broker MQTT armazena as informações do cliente.
Agora, caso a sessão limpa for definida verdadeira, todas as assinaturas serão removidas para o cliente quando ele for desconectado.
Fig. 32 Sequência de mensagens MQTT utilizando o flag clean_section = false(cliente persistente).
Mensagem de Última Vontade e Testamento
Uma Mensagem de Última Vontade e Testamento(Last Will and Testament Message) é utilizada por um Cliente MQTT para instruir ao Broker MQTT realizar publicação de uma mensagem predefinida caso o cliente se desconecte de forma “involuntária”.
Em termos simples, o Cliente MQTT apenas informa ao Broker MQTT o seguinte: “Se eu for desconectado por algum motivo, publique esta mensagem neste tópico”.
Normalmente, se desejamos que um Cliente MQTT se desconecte, simplesmente chamamos uma função disconnect() para que este processo ocorra de forma “comportada”.
Mas caso o cliente seja desconectado sem que a função seja executada, pode ser interessante identificar esse evento. E é aí que entra a mensagem de Última Vontade e Testamento.
O processo básico é o seguinte:
O Cliente MQTT define a carga útil da mensagem de última vontade e testamento e o nome do tópico antes de se conectar ao Broker MQTT;
O Broker MQTT armazena está mensagem até que uma desconexão “comportada” seja enviada pelo cliente(função disconnect()). Neste caso, o Broker MQTT descartará a mensagem;
Agora, caso o cliente se desconecte de forma “inesperada”, o Broker MQTT publicará a mensagem de Última Vontade e Testamento no tópico definido.
Abaixo, é exemplificado o fluxo(simplificado) das mensagens MQTT que elvolvem o envio da mensagem de Última Vontade e Testamento:
Fig. 33 Sequência para envio da mensagem de Última Vontade e Testamento.