Usuário(a):Júlia Rocha Dangelo/Testes

Estrutura padrão publish-subscriber do MQTT

MQTT, sigla de MQ Telemetry Transport, é um protocolo de mensagens leve para sensores e pequenos dispositivos móveis otimizado para redes TCP/IP. . O esquema de troca de mensagens é fundamentado no modelo Publicador-Subscritor, extremamente simples e leve. Os princípios arquitetônicos são minimizar o uso de banda de rede e uso de recursos dos equipamentos enquanto garantindo confiabilidade e algum nível de garantia de entrega. Estes princípios tornam esse protocolo ideal para as comunicações emergentes (M2M) “machine-to-machine” e para as aplicações “Internet of Things” (Internet das coisas) um mundo de equipamentos conectados, além das aplicações mobile onde banda e potência da bateria são relevantes. Atualmente se encontra na versão 5.0 e a 3.1.1 (padrão ISO), ambos são padrões OASIS. MQTT-SN é uma variação do protocolo destinada a redes que não sejam baseadas em TCP/IP, como ZigBee.

História

O MQTT é um protocolo de mensagens (camada de aplicação) projetado para um baixo consumo de banda de rede e recursos de hardware, desenvolvido pela IBM e Eurotech na década de 90.

Inicialmente, as letras "MQ" não tinham um significado específico para o protocolo, vinham de uma linha de produtos da IBM chamada 'MQ Series' . O protocolo fornecia mensagens de publicação e subscrição sem filas de espera e foi especificamente projetado para dispositivos com recursos limitados, baixa largura de banda e redes de alta latência, assim como as linhas discadas e ligações via satélite.

Em 1999, Andy Stanford-Clark (IBM) e Arlen Nipper (Cirrus Link, Eurotech) criaram a primeira versão do protocolo MQTT. Sua primeira aplicação foi destinada ao monitoramento de oleodutos. O objetivo era um protocolo leve com economia de banda e baixo consumo de energia e hardware, uma vez que os aparelhos eram conectados via satélite que, na época, era um recurso extremamente caro.

Em 2013, a IBM submeteu o MQTT v3.1 ao organismo de especificação da OASIS com uma carta que assegurava que apenas alterações menores à especificação poderiam ser aceitas.

Atualmente, MQTT é um protocolo de comunicação máquina para máquina (M2M - Machine to Machine) com foco em Internet of Things (IoT).

MQTT métodos (methods)

MQTT define pacotes de controle (Control Packets) para indicar a ação desejada a ser executada pelo recurso desejado. O MQTT possui uma estrutura de pacotes de controle própria, que basicamente é constituída de três partes principais: Cabeçalho fixo, cabeçalho variável e o payload.

Cabeçalho fixo — composto de ao menos [3] 2 bytes, possui 4 bits (posição byte 1, bits 7–4) designados para definir o tipo do pacote de controle, 3 bits para flags (posição byte 1, bits 3–0) e um byte adicional para suportar bits adicionais do cabeçalho variável e payload. Flags: atualmente a maior parte dos parâmetros de flag (CONNECT, CONNACK..) encontram-se reservados para usos futuros. Apenas o tipo PUBLISH possui funções próprias e possui definições para entrega DUP, qualidade de serviço QoS e opções de retenção RETAIN.

Cabeçalho variável — nem todos os tipos de mensagem MQTT possuem um cabeçalho variável, que basicamente traz informações da identificação do pacote. Os tipos de pacotes de controle que usam identificadores são PUBLISH se QoS > 0), SUBSCRIBE, UNSUBSCRIBE e todos os derivados de confirmação (PUBACK, SUBACK, UNSUBACK, PUBREC..). Possui um tamanho de até 2 bytes.

Payload — inclui a mensagem como um todo (normalmente os tópicos). Os pacotes de confirmação (CONNACK, PUBACK, SUBACK…) não necessitam de um payload.

Os métodos são os seguintes:

CONNECT:

Cliente solicita uma ligação com um servidor

CONNACK

Reconhece solicitação de conexão

PUBLISH

publicar mensagem

PUBACK

reconhecimento de publicação

PUBREC

Publicação recebida. (QoS 2 Publicação recebida., part 1)

PUBREL

Publicação publicada. (QoS 2 Publicação recebida., part 2)

PUBCOMP

Publicação completada. (QoS 2 Publicação recebida., part 3)

SUBSCRIBE

Inscrever-se em um tópico

SUBACK

Reconhecimento de inscrição

UNSUBSCRIBE

Cancelamento de inscrição em um tópico

UNSUBACK

Reconhecimento de cancelamento de inscrição.

PINGREQ

PING request

PINGRESP

PING response

DISCONNECT

Notificação de desconexão

Conexão, Segurança e Qualidade de Serviço

A conexão do cliente ao Broker se dá via TCP, sendo ele Subscriber ou Publisher, com opções de login (usuário e senha) e uso de criptografia (SSL/TLS). Todo processo de conexão estabelece um nível de qualidade de serviço (QoS) desejado, relacionado ao esforço dedicado para garantir a entrega da mensagem. As mensagens poder ser enviadas em qualquer nível de prioridade, sendo que o nível final é definido pelo client. São três níveis de qualidade de serviço:

QoS 1 (at most one)— a comunicação ocorre apenas uma vez, e não há confirmação de entrega da mensagem. O Publisher em questão não tem obrigação de manter a mensagem armazenada para o caso de uma possível retransmissão.

QoS 2 (at least one)— exige no mínimo 1 envio com confirmação de entrega da mensagem. O Publisher mantém a cópia da mensagem, em caso de time out.

QoS 3 (exactly once)— garante que a mensagem seja entregue exatamente uma vez, com o envio da confirmação de recebimento e a confirmação da confirmação de recebimento. Ou seja, tanto Subscriber quanto Publisher confirmam o recebimento da mensagem. Se não houver a confirmação, a mensagem é mantida para futuras retransmissões.

O nível de QoS indicado depende do tipo de aplicação. Tudo é gerenciado pelo Broker, e não entre Subscriber e Publisher. Por isso, é possível ter uma publicação e uma subscrição em níveis diferentes para um mesmo tópico.

O MQTT especifica que é responsabilidade do client garantir que o intervalo de tempo em que as mensagens demoram a ser enviadas não exceda um valor de KeepAlive. Caso o valor seja excedido, o client envia uma mensagem de controle PINGREQ. PINGREQ avisa ao Broker que ele ainda está vivo (online). Se o Broker não recebe um PINGREQ ou qualquer mensagem de um client específico, ele fecha a sessão e envia um LWT(Last Will Testament, caso este tenha sido especidficado). Um client pode fornecer um LWT da primeira vez que se conectar com um Broker. Se tal client se desconectar da rede, o Broker envia uma mensagem de broadcast aos outros dispositivos, checando se um dispositivo está offline. Caso um client fique offline por alguma razão, a sessão é preservada, e o Broker armazena as mensagens em cache. Quando a conexão é reestabelecida, as mensagens são entregues.

Se o problema ainda persistir, a biblioteca iniciará o recurso chamado "Client Take Over", fazendo com que o Broker feche a sessão e envie uma requisição de nova sessão com o client.

O máximo intervalo de KeepAlive é 18 horas 12 minutos e 15 segundos. Se o valor for setado para zero, o recurso é desativado.

Referências

Categoria:Transmissão de dados Categoria:Protocolos de rede Categoria:Protocolos Internet Categoria:Arquitetura de redes