Clientes MQTT

Qualquer dispositivo que se comunique através do protocolo MQTT em uma rede é denominado cliente MQTT. Os clientes MQTT podem desempenhar dois papeis distintos: publicadores (publish) e assinantes (subscribe). Os publicadores são responsáveis por “publicar” mensagens. Essas mensagens são identificadas por uma palavra chave denominada tópico, de modo que, cada mensagem publicada, esteja vinculada a um tópico adequado. Os assinantes, por sua vez, “assinam” os tópicos de interesse e recebem as mensagens vínculadas ao tópico escolhido sempre que são publicadas.

Quando um cliente MQTT publica uma mensagem ele envia junto do conteúdo da mensagem o tópico a qual ela está associada. Esse tópico é definido pelos desenvolvedores da aplicação, que devem escolher sua estrutura e nomeclatura com base nos requisítos e lógica da aplicação.

Arquitetura Publish-Subscribe

A arquitetura utilizada no protocolo MQTT é a Arquitetura Publish-Subscribe. Diferente da arquitetura cliente-servidor na qual clientes se comunicam diretamente com os servidores, realizando requisições e recebendo as respostas dessas requisições diretamente dos servidores, na arquitetura Publish-Subscribe essa comunicação não é realizada de forma direta, sendo mediada por uma entidade intermediária denominado MQTT broker. Cada mensagem publicada é enviada para o MQTT broker que a distribui aos clientes assinantes apropriados. Dentre as funções do MQTT broker, destaca-se:

1. Mediar o fluxo de mensagens entre os clientes publicadores e assinantes
2. Gerenciar as solicitações de conexão e desconexão dos clientes MQTT.
3. Gerenciar as assinaturas e cancelamentos de tópicos dos assinantes
4. Garantir a entrega das mensagens aos clientes assinantes de acordo com o QoS especificados

Para exemplificar o funcionamento da arquitetura publish-subscribe, tomemos o diagrama da figura 1 abaixo. Um sensor de temperatura (cliente MQTT publicador) envia um pacote de dados (tópico + mensagem) para um servidor central (MQTT broker). O servidor central verifica no conteúdo dos dados recebidos a palavra chave (tópico) referente a medição realizada pelo sensor. A seguir, busca em uma tabela assinantes x tópicos, os dispositivos (cliente MQTT assinante) que a medição recebida deve ser enviada.



O uso da arquitetura Publish-Subscribe oferece vantagens significativas para o protocolo MQTT, destacando-se:

1. Desacoplamento: publicadores e assinantes não precisam conhecer uns aos outros diretamente, permitindo que eles operem de forma independente.
2. Escalabilidade: novos publicadores e assinantes podem ser adicionados facilmente sem afetar o sistema como um todo. Isso permite que os sistemas cresçam conforme necessário para lidar com um número crescente de usuários e/ou dispositivos.
3. Eficiência de rede: a arquitetura Publish-Subscribe é eficiente em termos de uso de rede, pois as mensagens são entregues apenas aos assinantes especificados. Isso reduz a largura de banda necessária e minimiza o tráfego desnecessário na rede.
4. Flexibilidade: os assinantes podem se inscrever e cancelar a assinatura de tópicos dinamicamente, conforme necessário. Isso oferece flexibilidade para os usuários personalizarem sua experiência de acordo com suas necessidades específicas.
5. Tempo real e assíncrono: a arquitetura Publish-Subscribe suporta comunicação em tempo real e assíncrona entre os componentes do sistema. Isso é especialmente útil em cenários onde a latência é crítica ou quando os dados são gerados em intervalos irregulares.

A não necessidade de assinantes realizarem requisições para receberem as mensagens dos publicadores aliadas a outras técnicas como uma estrutura compacta de mensagens, permitem o protocoloco de comunicação MQTT maximizar a utilização da largura de banda da rede, tornando-o leve e eficiente para aplicações com limitações de largura de banda e recursos computacionais.

Pacotes de Controle (Control Packets)

O protocolo MQTT define pacotes de controle como unidades de dados que carregam consigo informações sobre o tipo e a estrutura das mensagens enviadas ao MQTT Broker e recebidas dele. Atualmente, existem 15 diferentes tipos de pacotes de controle, que podem ser organizados em 3 categorias: pacotes voltados à conexão, pacotes voltados à publicação e pacotes voltados à inscrição.

CONNECT: utilizado pelo cliente MQTT para iniciar uma conexão com o MQTT broker.

CONNACK: enviado como resposta indicando o resultado da conexão.

DISCONNECT cliente MQTT e MQTT broker podem enviar esse pacote e encerrar a conexão de rede.

AUTH: presente no MQTT 5.0, é utilizado para prover uma autenticação mais segura entre cliente MQTT e MQTT broker.

PINGREQ e PINGRESP: são pacotes utilizados em conjunto com o objetivo de manter a conexão entre cliente MQTT e MQTT broker. O cliente MQTT envia pacotes PINGREQ ao MQTT broker, indicando que ainda está ativo, e verifica se o MQTT broker ainda está em atividade com base no tempo de retorno do pacote PINGRESP.

PUBLISH: utilizado para publicar mensagens.

PUBACK, PUBREC, PUBREL e PUBCOMP: utilizados para reconhecer mensagens de QoS 1 e 2.

SUBSCRIBE: utilizado pelo cliente MQTT para se inscrever em tópicos.

SUBACK: retorna o resultado da inscrição.

UNSUBSCRIBE: utilizado pelo cliente MQTT para desfazer a inscrição em determinado tópico.

UNSUBACK: retorno do resultado do cancelamento de uma inscrição.

Estrutura dos pacotes

No protocolo MQTT, os pacotes são compostos de três partes: (1) Fixed Header, (2) Variable Header e (3) Payload. Desses três componentes, a única parte que está presente em todos os pacotes é a Fixed Header.

(1). Fixed Header

A Fixed Header consiste de três campos: MQTT Control Packet Type, Flags e Remaining Length.

O MQTT Control Packet Type é um unsigned integer que representa o tipo do pacote que está sendo enviado. Por exemplo, o int 1 representa o pacote CONNECT, enquanto o 2 representa o CONNACK.

As flags definem ações específicas que podem ser realizadas pelos pacotes de controle. O pacote PUBLISH, por exemplo, contém a flag DUP que, quando ativa, indica se o pacote que está sendo enviado é um pacote que está sendo retransmitido. As flags do PUBLISH são as únicas que podem ser alteradas pelo cliente, todos os outros pacotes possuem flags com valores fixos.

O campo Remaining Length indica a quantidade de bytes existentes na parte restante do pacote de controle, que inclui a Variable Header e o Payload.


(2). Variable Header

O conteúdo da Variable Header depende do pacote que está sendo enviado. Na figura abaixo, temos o conteúdo da Variable Header dos pacotes CONNECT.

Protocol name length: indica o tamanho, em bytes, do nome do protocolo.

Protocol Name: representação, de acordo com a tabela ASCII, do nome do protocolo. MQTT (0X4d 0x51 0x54 0x54)

Protocol Level: indica à versão do protocolo que está sendo utilizada. “4” representa a versão MQTT v3.1.1 e “5”, MQTT v5.0.

Connect Flag: campo com informações relacionadas às opções de conexão. Por exemplo:

• Will retain: se ativo, a mensagem será retida.
• Will QoS: indica o nível de QoS que a mensagem possuirá.
• Will flag: caso ativo, o MQTT Broker enviará uma mensagem de Last Will and Testament em caso de desconexão.

Keep Alive: é o período máximo de tempo que o cliente MQTT ficará sem enviar pacotes ao Broker.

A ordem dos campos dentro da Variable Header é específica, eles só serão devidamente computados caso sigam a especificação do MQTT. Além disso, é proibido omitir qualquer campo, a não ser que o protocolo permita. No pacote PUBLISH, por exemplo, o Packet Identifier só está presente quando o QoS é diferente de 0.


(3). Payload

O Payload é utilizado para armazenar informações relacionadas ao propósito central de determinado pacote de controle. No pacote PUBLISH, por exemplo, o Payload carrega a mensagem que deve ser transmitida ao MQTT broker, enquanto que no SUBSCRIBE, o Payload contém os tópicos disponíveis para inscrição, o que corresponde à tarefa principal do pacote.

Mensagens Retidas (Retained Messages)

No MQTT, uma mensagem retida pode ser definida como um pacote de controle PUBLISH com a flag Retain ativa. Essa flag informa ao Broker que a mensagem que está sendo enviada pelo cliente deve ser armazenada sob determinado tópico e garante que qualquer novo assinante daquele tópico receba a mensagem.

Quando a flag não está ativa, apenas os clientes já inscritos no tópico no momento do envio irão receber a mensagem. Cada tópico tem a capacidade de armazenar somente uma mensagem por vez. Então quando a flag está ativa, o Broker mantém apenas a mensagem mais recente.

Last Will and Testament

Last Will and Testament é uma ferramenta que permite que os clientes definam uma mensagem que será automaticamente enviada pelo Broker aos assinantes de um tópico caso a conexão entre publicador e Broker seja interrompida de forma inesperada.

Quando um cliente se conecta a um Broker, uma mensagem “testamento” pode ser definida. O Broker armazena essa mensagem até que identifique uma desconexão súbita do cliente. Uma vez que a desconexão é percebida, o Broker transmite a mensagem a todos os inscritos do tópico em pauta. Caso a desconexão do cliente não seja inesperada, a mensagem será descartada.

Esse recurso é de extrema importância na manutenção da integridade do sistema e na garantia de uma comunicação eficiente.

Sessões Persistentes

Para receber mensagens de um Broker, um servidor deve estabelecer uma conexão com o mesmo e se inscrever nos tópicos de seu interesse. Em uma sessão não persistente, caso a conexão seja interrompida, o cliente perde todas as suas inscrições e, quando se reconecta, precisa refazê-las. Para contornar essa situação, o cliente pode requisitar uma sessão persistente ao se conectar com o Broker.

Sessões persistentes armazenam no Broker todas as informações do cliente consideradas relevantes, garantido que as inscrições e as mensagens sejam mantidas mesmo diante de uma desconexão. Assim, no momento de reconexão todas essas informações estarão imediatamente disponíveis.

Essa ferramenta contribui na redução da sobrecarga na reconexão entre cliente e Broker, especialmente em redes mais instáveis onde desconexões estão mais suscetíveis a ocorrer.

Quality of Service (QoS)

O mecanismo de Qualidade de Serviço no MQTT está relacionado ao nível de garantia de entrega das mensagens que estão sendo transmitidas na rede. O cliente que publica uma mensagem define o QoS a ser usado durante a transmissão do pacote, enquanto os assinantes selecionam o QoS de sua conexão durante o processo de inscrição.

O protocolo disponibiliza três níveis de QoS:

At most once (QoS 0)

At least once (QoS 1)

Exactly Once (QoS 2)

QoS 0

Em seu nível mais baixo, um serviço de entrega best-effort é oferecido. Nesse modelo o remetente não espera reconhecimento e nem garantia de que a mensagem foi recebida pelo destinatário.

QoS 1

Nesse segundo caso, o foco do serviço é garantir que a mensagem chegue pelo menos uma vez ao receptor. Quando uma mensagem é publicada com QoS 1, o remetente mantém uma cópia do que foi enviado até receber de volta um pacote PUBACK do destinatário, garantindo que a transmissão foi bem sucedida. Caso o rementente não receba o PUBACK dentro de um determinado intervalo de tempo, a mensagem é retransmitida.

QoS 2

É o nível mais alto de Qualidade de Serviço disponibilizado pelo MQTT e garante que as mensagens sejam entregues exatamente uma vez. Quando um destinatário recebe um pacote PUBLISH com QoS 2 ativado, o mesmo reconhece o recebimento enviado um pacote PUBREC de volta para o remetente. Caso o remetente não receba o PUBREC, ele envia novamente a mensagem original. Após receber o pacote PUBREC, o remetente enviará um PUBREL ao destinatário que, em resposta, descartará todos os estados armazenados e responderá enviando um pacote PUBCOMP ao remetente. Até que o receptor complete o processamento e transmita o PUBCOMP, o publicador mantém uma referência ao identificador pacote PUBLISH original. Uma vez que o PUBCOMP é devidamente recebido, o identificador fica liberado para reutilizção.

A Qualidade de Serviço é crucial no MQTT pois proporciona ao cliente a possibilidade de selecionar um nível de serviço que seja capaz de equilibrar a confiabilidade da rede e as necessidades da aplicação sendo configurada. A capacidade do MQTT de lidar com retransmissão de mensagens e garantia de entrega mesmo em conexões de rede não confiáveis faz do QoS uma ferramenta essencial para facilitar a comunicação em condições desfavoráveis.

Segurança

Embora o MQTT tenha sido projetado com foco na simplicidade e eficiência, o protocolo oferece alguns mecanismos de segurança. A segurança do protocolo MQTT pode ser abordada em várias camadas:

1. Autenticação

Username/Password: O MQTT permite a autenticação por meio de nome de usuário e senha ao se conectar ao MQTT Broker. No entanto, esses dados são enviados em texto junto com o pacote de conexão CONNECT e podem ser interceptados, o que requer a utilização de outros métodos como criptografia para uma proteção mais adequada.

Certificados X.509: Para uma autenticação mais robusta, o MQTT pode usar os serviços do TLS/SSL, onde clientes e brokers se autenticam mutuamente usando certificados X.509. Isso envolve a configuração de certificados digitais que são verificados durante a negociação TLS. É importante ressaltar que o uso adicional do TLS/SSL pode ser complexo e pode introduzir sobrecarga em dispositivos com recursos limitados.

2. Criptografia

TLS/SSL: O protoloco MQTT não oferece serviços nativos de criptografia. No entanto, ele permite o uso de protocolos externos como o TLS/SSL. Isso garante que os dados transmitidos entre o cliente e o broker estejam criptografados, evitando interceptação e modificação não autorizada dos dados durante o trânsito.

3. Controle de acesso

ACL (Access Control List): Muitos brokers MQTT suportam listas de controle de acesso, permitindo definir quais tópicos cada cliente pode publicar ou se inscrever. Isso ajuda a restringir o acesso apenas aos dados que cada dispositivo ou usuário deve ter.

Fluxo de trabalho do MQTT

O fluxo de trabalho do protocolo MQTT envolve um série de etapas bem definidas e estruturadas, sendo elas:

Conexão inicial

1. O cliente MQTT inicia o processo de conexão com o MQTT broker. Esse processo geralmente é realizado através de uma conexão TCP/IP. No entanto, outros protocolos também podem ser usados, como o MQTT-SN, WebSocket (WS), WebSocket Secure (WSS), QUIC, dentre outros.
2. Caso o protocolo de transporte utilizado seja o TCP/IP, o cliente MQTT estabelece uma conexão TCP/IP com o endereço IP e a porta do MQTT broker. A porta padrão para conexões MQTT é a porta 1883 (ou 8883 para conexões seguras SSL/TLS).
3. Durante a fase de conexão, ocorre um handshake entre o cliente MQTT e o MQTT broker para estabelecer os parâmetros da conexão. Isso inclui informações como o nível de QoS, e detalhes de autenticação, como nome de usuário e senha
4. O cliente MQTT envia um pacote CONNECT para o MQTT broker contendo informações sobre ele, como seu ID de cliente, suas configurações de sessão, nome de usuário e a senha (se aplicável).
5. MQTT broker responde com um pacote CONNACK, indicando se a conexão foi aceita ou não. Se aceita, o cliente MQTT e o MQTT broker estão prontos para trocar mensagens.
6. Uma vez estabelecida a conexão, o cliente MQTT pode começar a publicar mensagens, se inscrever em tópicos ou realizar outras operações suportadas pelo protocolo MQTT.
7. Periodicamente, o cliente MQTT e o MQTT broker podem trocar mensagens de controle para manter a conexão ativa e verificar se a outra parte ainda está disponível. Isso ajuda a garantir a confiabilidade da comunicação e permite detectar desconexões ou falhas de rede.

Publicação de mensagens

1. Após a conexão inicial ter sido estabelecida com sucesso, um cliente MQTT pode iniciar o processo de publicação de mensagens.
2. Para publicar uma mensagem, o cliente MQTT envia um pacote PUBLISH para o MQTT broker.
3. O pacote PUBLISH contém várias informações, incluindo o tópico ao qual a mensagem está sendo publicada e o conteúdo da mensagem (payload).
4. O tópico é uma string de texto que serve como um identificador para a mensagem. Ele pode seguir uma estrutura hierárquica para organizar as mensagens em categorias ou temas relacionados.
5. O payload da mensagem pode conter qualquer tipo de dados, como telemetria de sensores, comandos de controle, mensagens de status, entre outros.
6. Antes de publicar a mensagem, o cliente MQTT pode especificar o nível de QoS desejado para essa mensagem. O nível de QoS determina o nível de garantia de entrega da mensagem e pode ser 0, 1 ou 2.
7. Após receber a mensagem, o MQTT broker a armazena temporariamente e a encaminha para os assinantes que estão inscritos no tópico, consultando em uma tabela assinantes x tópicos para determinar os assinantes vinculados.
8. Se necessário, o MQTT broker pode confirmar a recepção da mensagem de volta ao cliente MQTT, dependendo do nível de QoS especificado. Isso ajuda a garantir a entrega confiável da mensagem, mesmo em condições de rede instáveis.
9. Depois que a mensagem é publicada com sucesso, o cliente MQTT pode continuar publicando mais mensagens conforme necessário ou realizar outras operações suportadas pelo protocolo MQTT.

Assinatura de tópicos

1. Um cliente MQTT que deseja receber mensagens sobre tópicos específicos deve se inscrever nesses tópicos no MQTT broker.
2. Para se inscrever em um tópico, o cliente MQTT envia um pacote SUBSCRIBE para o MQTT broker.
3. O pacote SUBSCRIBE contém uma lista de tópicos aos quais o cliente MQTT deseja se inscrever, bem como o nível de QoS desejado para cada tópico.
4. O cliente MQTT pode se inscrever em múltiplos tópicos de uma só vez, especificando-os na lista de inscrição.
5. O MQTT broker processa o pedido de inscrição e registra o cliente como um assinante dos tópicos especificados.
6. Quando uma mensagem é publicada em um tópico para o qual o cliente MQTT está inscrito, o MQTT broker encaminha a mensagem para o cliente MQTT.
7. O cliente MQTT pode especificar diferentes níveis de QoS para cada tópico ao se inscrever. Isso permite que o cliente controle a garantia de entrega das mensagens recebidas para cada tópico individualmente.
8. Após se inscrever com sucesso nos tópicos desejados, o cliente MQTT está pronto para receber mensagens publicadas sobre esses tópicos.
9. O cliente MQTT pode continuar se inscrevendo em outros tópicos conforme necessário ou realizar outras operações suportadas pelo protocolo MQTT.

Recebimento de mensagem

1. O MQTT broker verifica se há clientes MQTT inscritos no tópico específico no momento em que a mensagem é publicada.
2. Se houver um ou mais clientes MQTT inscritos no tópico, o MQTT broker envia a mensagem para esses clientes.
3. A entrega da mensagem pode ocorrer de acordo com o nível de QoS especificado na publicação da mensagem.
4. No nível de QoS 0 (entrega "no máximo uma vez"), o MQTT broker envia a mensagem uma única vez para o cliente MQTT assim que a mensagem é publicada, sem confirmar a entrega.
5. No nível de QoS 1 (entrega "pelo menos uma vez"), o MQTT broker envia a mensagem para o cliente MQTT e espera uma confirmação de recebimento (PUBACK) do cliente.
6. No nível de QoS 2 (entrega "exatamente uma vez"), o MQTT broker e o cliente MQTT trocam uma série de mensagens para garantir que a mensagem seja entregue exatamente uma vez, mesmo em caso de falhas de rede ou reconexão.
7. Após receber a mensagem, o cliente MQTT a processa conforme necessário, executando qualquer lógica associada a ele na definição da aplicação.
8. O cliente MQTT pode continuar recebendo e processando mensagens conforme elas são publicadas nos tópicos em que está inscrito.
9. O MQTT broker pode armazenar temporariamente as mensagens para clientes MQTT que estão temporariamente desconectados ou offline, garantindo que eles recebam as mensagens assim que se reconectarem.

Processamento da mensagem

1. Após receber uma mensagem do MQTT broker, o cliente MQTT processa essa mensagem de acordo com a lógica associada a ele na definição da aplicação.
2. O processamento da mensagem pode envolver uma variedade de atividades. Algumas possíveis ações incluem:

   • Análise dos dados contidos na mensagem para extrair informações relevantes.
   • Tomada de decisões com base nas informações recebidas, como acionar uma ação específica ou enviar uma resposta.
   • Atualização do estado interno do cliente MQTT com base nas informações recebidas, como atualização de variáveis ou registros de estado.
   • Encaminhamento da mensagem para outros sistemas ou componentes para processamento adicional.

3. O processamento da mensagem pode ser assíncrono, permitindo que o cliente MQTT continue funcionando normalmente enquanto processa a mensagem em segundo plano.
4. O cliente MQTT pode implementar tratamento de erro adequado para lidar com situações em que o processamento da mensagem falha ou ocorrem exceções.
5. Após o processamento da mensagem, o cliente MQTT pode realizar outras operações, como publicar mensagens adicionais, enviar respostas ou executar ações adicionais com base nas informações recebidas.

Desconexão

1. Após concluir as operações necessárias, o cliente MQTT pode optar por encerrar a conexão com o MQTT broker.
2. A desconexão pode ser iniciada pelo cliente MQTT ou pelo MQTT broker, e pode ocorrer por uma variedade de motivos, incluindo:

   • O cliente MQTT não precisa mais se comunicar com o MQTT broker.
   • O cliente MQTT está temporariamente offline ou entrando em um estado de economia de energia.
   • Ocorreu um erro ou exceção que requer a desconexão do cliente MQTT.

3. Para se desconectar desconectar, o cliente MQTT envia um pacote DISCONNECT para o MQTT broker.
4. O pacote DISCONNECT notifica o MQTT broker de que o cliente MQTT deseja encerrar a conexão de forma limpa.
5. Após receber o pacote DISCONNECT, o MQTT broker finaliza a sessão com o cliente MQTT e libera quaisquer recursos associados à sua conexão.
6. O cliente MQTT pode reconectar-se ao MQTT broker a qualquer momento posterior, se necessário, reiniciando o processo de conexão e retomando a comunicação com o MQTT broker.

Internet of Things (IoT)

O MQTT é um protocolo de mensagens leve e eficiente que é adequado para aplicativos de IoT. Seu suporte para transmissão eficiente de dados, entrega confiável e comunicação segura tornam uma escolha popular para uma ampla gama de aplicações, desde automação industrial até casas e edifícios inteligentes.

O MQTT foi criado para enfrentar os desafios do acesso massivo de dispositivos e gerenciamento de dispositivos em aplicativos de IoT, como ambientes de rede complexos e não confiáveis, pequena capacidade de memória e memória flash e capacidade de processamento limitada. Ele se tornou o protocolo preferido para a indústria de IoT devido às suas vantagens de leveza, eficiência, mensagens confiáveis, suporte de conexão maciço e comunicação bidirecional segura.

Aplicações móveis

Em dispositivos móveis, o MQTT é particularmente útil devido ao seu baixo consumo de energia, baixos requisitos de largura de banda e capacidade de lidar com redes de alta latência e não confiáveis. Essas características o tornam uma escolha ideal para aplicativos móveis que exigem comunicação em tempo real,

Visão geral de características

A versão mais recente do protocolo de comunicação MQTT é a versão 5. Essa nova versão trás uma série de atualizações e novos recursos em relação a sua versão anterior 3, com foco especialmente em se adaptar para as demandas que virão da era da Internet das Coisas (IoT). Como exemplos de novos recursos, podemos citar:

1. Intervalo de expiração da sessão
   Essa ferramenta consiste na definição de um parâmetro pelo cliente na transmissão de um pacote CONNECT. Tal parâmetro indica o intervalo de tempo que o Broker irá reter as informações relacionadas à sessão do cliente. A possibilidade de definir esse intervalo faz diferença quando se trata de sessões persistentes onde os dispositivos que se desconectaram não voltam a estabelecer a conexão devido a descomissionamento ou destruição. O resíduo dessas sessões podem representar uma sobrecarga desnecessária ao sistema e o intervalo de expiração age de forma a liberar recursos de rede.
2. Intervalo de expiração da mensagem
   Os clientes podem definir um Intervalo de Expiração da Mensagem para cada mensagem PUBLISH transmitida. Esse intervalo estabelece por quanto tempo o Broker irá preservar uma mensagem PUBLISH para assinantes que se encontram offline. A atribuição de tempos de expiração adequados às mensagens de pouca relevância garante um uso mais efetivo dos recursos do Broker para clientes que possam ficar desconectados por longos períodos. Além disso, evita que os clientes sejam abarrotados de mensagens irrelevantes quando reconectados.
3. Topic Aliases
   são valores inteiros usados para substituir nomes de tópicos. A ferramentas permite a redução de nomes longos e frequentemente utilizados para inteiros de 2 bytes, o que contribui para a minimização da largura de banda utilizada na publicação de mensagens MQTT. Aconservação dos recursos de rede é especialmente significativa diante de um alto volume de mensagens sendo publicadas em uma quantidade limitada de tópicos.

O MQTT é um protocolo poderoso e flexivel que atende a uma ampla gama de aplicações com diferentes requisítos. Sua capacidade de operar eficientemente em ambientes com recursos limitados e sua arquitetura escalável o torna ideal para aplicações modernas de Iot.

A decisão de usar ou não o MQTT depende das necessidades específicas da aplicação. Se você precisa de um protocolo leve, eficiente e flexível para comunicação IoT, o MQTT é uma excelente escolha. No entanto, se a segurança integrada, baixa latência sem sobrecarga ou a complexidade de implementação forem preocupações principais, talvez seja necessário considerar outras alternativas ou preparar-se para implementar as medidas adicionais necessárias para garantir um uso seguro e eficiente do MQTT.

O que é MQTT?

MQTT é um protocolo de comunicação mantido pelo OASIS (Organization for the Advancement of Structured Information Standards) extremamente simples e leve projetado para dispositivos restritos e redes de baixa largura de banda, alta latência ou não confiáveis. Os princípios de design do protocolo visam minimizar a largura de banda da rede e os requisitos de recursos do dispositivo, ao mesmo tempo que tentam garantir a confiabilidade e algum grau de garantia de entrega.

Quais as 3 principais características do MQTT?

Leveza, eficiência e escalável.

Onde o MQTT é usado?

O protocolo MQTT é utilizado em diversas aplicações como Iot, automação industrial, casas e edifícios inteligentes, dentre outros.

Quais os 3 principais agentes atuantes do MQTT?

Clientes publicadores, clientes assinantes e MQTT Broker.

O que é um cliente publicador?

Qualquer dispositivo que se comunique através do protocolo MQTT e que "publique" mensagens.

O que é um cliente assinante?

Qualquer dispositivo que se comunique através do protocolo MQTT e que "assine" mensagens.

O que é o MQTT Broker?

É um agente centralizador que intermedia a comunicação entre clientes publicadores e clientes assinantes. Ao publicar uma mensagem, o cliente publicador a envia ao MQTT Broker. Este, por sua vez, a envia para os clientes assinantes.

Qual modelo de arquitetura o MQTT usa?

O modelo Publish/Subscribe.

O que é mensagem e tópico?

Uma mensagem é uma informação publicada por um cliente publicador. Ao publicar uma mensagem, ela é identificada por uma palavra chave denominada tópico. Dessa forma, cada mensagem é identificada por um tópico. Podemos ter mensagens diferentes associadas ao mesmo tópico e, nesse caso, temos mensagens que pertencem a um grupo comum.

O protocolo MQTT garante a entrega das mensagens?

Sim. O MQTT oferece 3 níveis de Qos: 0, 1 e 2.

Existe uma porta padrão para o uso do MQTT?

Sim. A porta TCP/IP 1883 é reservada pela IANA para uso com MQTT. A porta TCP/IP 8883 também está registrada, para usar MQTT sobre SSL.

O MQTT oferece suporte à segurança?

Sim. O MQTT permite passar um nome de usuário e uma senha com um pacote MQTT na V3.1 do protocolo. A criptografia na rede pode ser tratada com SSL, independentemente do próprio protocolo MQTT (vale a pena notar que SSL não é o mais leve dos protocolos e adiciona sobrecarga significativa à rede). Segurança adicional pode ser adicionada por um aplicativo que criptografa os dados que envia e recebe, mas isso não é algo incorporado ao protocolo, para mantê-lo simples e leve.

[1] - MQTT: o padrão para mensagens Iot. MQTT, © 2022. Disponível em https://mqtt.org/. Acesso em 22 abr. 2024.

[2] - BASUMALLICK, Chiradeep. What Is MQTT (MQ Telemetry Transport)? Working, Types, Importance, and Applications. Spiceworks, © 2006-2024. Disponível em https://www.spiceworks.com/tech/iot/articles/what-is-mqtt/. Acesso em 22 abr. 2024.

[3] - O que é MQTT?. AWS Amazon, © 2023. Disponível em https://aws.amazon.com/pt/what-is/mqtt/. Acesso em 23 abr. 2024.

[4] - What Is the MQTT Protocol: A Beginner's Guide. EMQX, © 2013-2024. Disponível em https://www.emqx.com/en/blog/the-easiest-guide-to-getting-started-with-mqtt. Acesso em 23 abr. 2024.

[5] - MQTT 5 Vs MQTT 3 - MQTT 5 Essentials Parte 2. HIVEMQ, © 2024. Disponível em https://www.hivemq.com/blog/mqtt5-essentials-part2-foundational-changes-in-the-protocol/. Acesso em 24 abr. 2024.

[6] - MQTT 5: Seven Reasons to Upgrade to it from MQTT 3.11 - MQTT 5 Essentials Parte 3. HIVEMQ, © 2024. Disponível em //www.hivemq.com/blog/mqtt5-essentials-part3-upgrade-to-mqtt5-now/. Acesso em 24 abr. 2024.

[7] - Conheça o MQTT, protocolo de mensagens mais usado em IoT. Networkking, © 2018. Disponível em https://network-king.net/pt-pt/conheca-o-mqtt-o-protocolo-de-mensagens-mais-usado-em-iot/#:~:text=MQTT%20%C3%A9%20um%20protocolo%20para,confi%C3%A1veis%20ou%20com%20alta%20lat%C3%AAncia . Acesso em 4 abr. 2024.

[8] - 7 Advantages of MQTT protocol for IoT Devices. Medium, © 2020. Disponível em https://medium.com/@esperso/7-benefits-of-mqtt-protocol-for-iot-e463f6a97100. Acesso em 28 mai. 2024.

[9] - Limitations of MQTT. Medium, © 2020. Disponível em https://blog.iotify.io/limitations-of-mqtt-bd61e8150bca. Acesso em 28 maio 2024.

[10] - MQTT Topic Alias – MQTT 5 Essentials Part 10. HIVEMQ, © 2024. Disponível em https://www.hivemq.com/blog/mqtt5-essentials-part10-topic-alias/. Acesso em 28 mai. 2024.

[11] - What is MQTT Quality of Service (QoS) 0, 1, & 2? – MQTT Essentials: Part 6. HIVEMQ, © 2024. Disponível em https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/. Acesso em 02 jun. 2024.