



Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Descrição detalhada sobre o protocolo de comunicação MQTT
Tipologia: Manuais, Projetos, Pesquisas
1 / 6
Esta página não é visível na pré-visualização
Não perca as partes importantes!




Protocolo MQTT MQTT – Message Queuing Telemetry Transport “Transporte de Filas de Mensagem de telemetria” Protocolo de comunicação M2M, criada por Andy Stanford-Clark (IBM) e Arlen Nipper em 1999, com intuito de conectar sistemas de telemetria de oleodutos via satélite, liberada gratuitamente em 2010. Este protocolo possui vantagens sobre HTTP, inicialmente o conceito de districuição Publisher/Subscriber, possui vários níveis de serviço, com garantia de entrega, tem foco no transporte e não no conteúdo, tendo maior nível de segurança. No HTTP, temos envio de dados 1-1, já no MQTT, 1-0, 1-1, 1-N. MQTT é um protocolo de transporte de mensagens Cliente/Servidor no conceito de Publicação/Assinatura, ou seja, uma transmissão aprecida com rádio, a emissora transmite em uma sintonia, e os clientes entram nesta, para receber os dados. Ele é leve, aberto, simples e projetado para ser de fácil implementação, ideal para uso em cenários com recursos restritos, comunicações M2M, IoT, cenários em que são exigidos pacote de dados e/ou largura de banda mínimos. O protocolo é executado sobre TCP/IP ou sobre outros protocolos de rede que forneçam conexões bidirecionais ordenadas, sem perda. Niveis de acesso, adequado à relevância de cada mensagem, segurança alta. Conceitos Publisher: Cliente que envia o pacote de dados Subscriber: Cliente que recebe o pacote de dados Broker: Recebe dados do Publisher, armazena e distribui aos subscriber Cliente pode ser Publisher e Subscriber simultaneamente Não existe identificação do cliente perante o Broker, seja para publicar ou assinar Message: Pacote de dados trafegado entre Clientes e Broker Topic: Repositório de dados único que recebe a Mensagem, acessível aos clientes, instantâneo e sem histórico Publish: Ação de enviar ao Broker uma mensagem para um determinado tópico Subscribe: ação de solicitar receber mensagens de um determinado tópico Unsuscribe: Ação de solicitar não receber mais mensagens de um determinado tópico Payload (Conteúdo) : Dados eniados na mensagem QoS – Quality of Service o Nível de serviço sob o qual o Broker deve receber e/ou transmitir os dados o 0 – At most once (No máximo uma vez) o 1 – At least once (Pelo menos uma vez) o 2 – Exactly once (Exatamente uma vez) Last Will / Will Message (Ultima vontade) o Mensagem a ser enviada pelo Broker caso o Cliente perca a conexão `Ping : teste periódico entre Cliente e Broker Session: Período no qual o Cliente está conectado ao Broker
Clean o Indica se a sessão deve ser persistida Tópicos assinados, mensagens recebidas enquanto o cliente está desconectado. o Ao inciar uma Sessão “limpa”, os dados da Sessão anterior são descartados Retain: Indica se a Mensagem deve ser mantida pelo Broker, até uma próxima ser recebida MQTT Box Teste do procotocolo Modelo Publish/Subscribe É uma alternativa ao tradicional modelo Cliente – Servidor, onde o cliente não está conectado diretamente ao servidor/Endpoint. O Publisher ele apenas publica o dado ao broken e não tem informação do cliente, de quantos são, da mesma forma que o subscriber só obtém os dados do broken. Isso faz com que os clientes não tenham contatos entre si e possam ser Publisher, Subscriber ou ambos, já que a comunicação é centrado ao broken. Papel do Broker Cabe ao broker manter o controle dos tópicos criados e assinados, receber todas as publicações, armazena-las nos seus respectivos tópicos e encaminhar para seus assinantes. Ele deve gerenciar a comunicação de acordo com o QoS atribuído, manter as publicações definidas para retenção e enviando para novos clientes, deve manter controle sobre as conexões e desconexões para enviar a will messages, casa tenha sido definida. Por fim, gerenciar toda a segurança. O Broken não manterá histórico de publicação, logo irá descartar a ultima mensagem assim que for entregue a todos subscriber, não terá foco no conteúdo, apenas repassando ele. E por fim não fará gerenciamento de clientes. Caracteristicas da comunicação MQTT Os clientes são alheios uns aos outros, sem conexão física ou lógica, vários publishers podem publicar no tópico e vários subscribers podem assinar o mesmo tópicos. Não á a necessidade de sincronia, ou seja, Publisher e Subscriber executam suas ações em tempos independentes, já o MQTT garante a entrega o mais rápido possível, com foco na entrega não na velocidade. A comunicação é essencialmente assíncrona, tendo que o Publisher apenas publica a mensagem, não se preocupara com sua entrega ( Fire and Forget ) e o subscriber toma conhecimento da Mensagem apenas quando o broken a entrega.
Exemplos: o Casa/sala/temperatura o Casa/sala/umidade o Casa/sala/arcondicionado/modo Separador de nível – “/” Cada nível deve possuir ao menos um caractere Um separador sozinho é considerado um nível Coringas: Utilizado apenas em assinaturas(subscribe) o Nível único - “+” : Pode ser utilizado em qualquer nível, correspondendo a qualquer conteúdo Casa/+/temperatura Casa/sala/temperatura Casa/quarto/temperatura o Nível Múltiplo – “#”: Utilizado apenas no final, em qualquer conteúdo e quantidade de níveis: Casa/# Casa/sala/temperatura Casa/quarto/temperatura Casa/cozinha Ele recebe todas mensagens enviadas pelo broker Tópicos especiais: Iniciam com “$” (sifrão) Não podem receber publicação de Clientes Não podem ser assinados por Coringas Não a formaçização de seu uso Convencionou-se que tópicos iniciando com “$SYS/” fornecem estatísticas internas do broker o $SYS/broker/cliente/total o $SYS/broker/mesage/sent Caracteristicas do QoS Principal característica do MQTT, define o nível de garantia de entrega de uma mensagem ao subscriber Impacta diretamente no fluxo de tráfego O QoS esperado é definido pelo Publisher o Nível máximo de execução do serviço O QoS no recebimento é definido pelo Subscriber o Nível real de execução do serviço o Pode ser inferior ao definido no Publisher Níveis: 0 – At most once (No máximo uma vez) o Mensagem será entregue até uma única vez o Ou nenhuma... o Ele envia e não espera retorno
o Utilizar em conexões estáveis e perca aceitável 1 – At least once (Pelo menos uma vez) o Mensagem será entregue ao menos uma vez o Pode ocorrer entrega duplicada, triplicada. o Ele vai enviando até receber uma confirmação o Utilizar quando todas as mensagens precisam ser recebidas, mesmo que duplicadas e o tráfego e mensagens aceitáveis do que trafego do QoS 2 2 – Exactly once (Exatamente uma vez) o Mensagem será entregue exatamente uma vez o É enviado, o broker confirma, é enviado uma mensagem e encerramento e o broker confirma o encerramento o Utilizar quando a precisão no recebimento da mensagem é crítico Para todos os níveis são iguais para qualquer caminho da mensagem Características do Retain Indica ao Broker para armazenar uma Mensagem Apenas uma Mensagem com Retain por tópico Novos Subscribers receberão a mensagem imediatamente A Mensagem com retains não é necessariamente a ultima do tópico Para alterar uma mensagem com retain, basta publicar outra com retain, que irá sobrescrever a anterior. Para excluir basta publicar sem conteúdo. Persistência de conexão Permite ao Broker e ao Client estarem ciente de seu estado de conexão Quando ocorre uma desconexão o broker encerrra a conexão com o cliente e aceita nova conexão Cabe ao cliente refazer conexão Tempo de “Keep Alive” o Definido pelo cliente durante a conexão o Tempo máximo que o Client pode ficar sem enviar mensagem, definido pelo cliente Requisição PING o Enviada pelo Client ao Broker Sinalizando que o cliente está online o Casa não haja mensagem a ser enviada, o client deve enviar PING antes do tempo de Keep Alive Tempo máximo de Keep Alive o 18h 12m 15s = 65535 – 2 bytes Tempo de Keep Alive 0 desabilita o controle de persistência Responsabilidades o Broker – Desconectar Client e Permitir reconexão o Client – enviar mensagem ou ping em intervalo inferior ao tempo de Keep alive e refazer conexão caso desconecte Última vontade (Last Will Message) Definida pelo Client durante a conexão