MQTT - AWS IoT Core

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

MQTT

O MQTT (Message Queuing Telemetry Transport) é um protocolo de mensagens leve e amplamente adotado, projetado para dispositivos restritos. AWS IoT Coreo suporte para MQTT é baseado na especificação MQTT v3.1.1 e na especificação MQTT v5.0, com algumas diferenças, conforme documentado emAWS IoTdiferenças das especificações do MQTT. Como a versão mais recente do padrão, o MQTT 5 apresenta vários recursos importantes que tornam um sistema baseado em MQTT mais robusto, incluindo novos aprimoramentos de escalabilidade, relatórios de erros aprimorados com respostas de código de motivo, temporizadores de expiração de mensagens e sessões e cabeçalhos personalizados de mensagens de usuários. Para obter mais informações sobre os recursosAWS IoT Core suportados pelo MQTT 5, consulte Recursos suportados pelo MQTT 5. AWS IoT Coretambém suporta comunicação entre versões MQTT (MQTT 3 e MQTT 5). Um editor do MQTT 3 pode enviar uma mensagem MQTT 3 para um assinante do MQTT 5 que receberá uma mensagem de publicação do MQTT 5 e vice-versa.

AWS IoT Coresuporta conexões de dispositivos que usam o protocolo MQTT e o protocolo MQTT sobre WSS e que são identificadas por um ID de cliente. ElesSDKs de dispositivo da AWS IoT suportam ambos os protocolos e são as formas recomendadas de conectar dispositivosAWS IoT Core. Os SDKs deAWS IoT dispositivos suportam as funções necessárias para que dispositivos e clientes se conectem e acessemAWS IoT serviços. Os SDKs do dispositivo oferecem suporte aos protocolos de autenticação exigidosAWS IoT pelos serviços e aos requisitos de ID de conexão exigidos pelo protocolo MQTT e pelos protocolos MQTT sobre WSS. Para obter informações sobre como se conectar aoAWS IoT uso dos SDKs doAWS dispositivo e links para exemplos dosAWS IoT idiomas suportados, consulteConectando-se com o MQTT usando os SDKs doAWS IoT dispositivo. Para obter mais informações sobre métodos de autenticação e mapeamentos de portas para mensagens MQTT, consulteProtocolos, mapeamentos de porta e autenticação.

Embora seja recomendável usar os SDKs doAWS IoT dispositivo para se conectarAWS IoT, eles não são necessários. No entanto, se você não usar os SDKs doAWS IoT dispositivo, deverá fornecer a segurança de conexão e comunicação necessária. Os clientes devem enviar a extensão TLS do Server Name Indication (SNI) na solicitação de conexão. As tentativas de conexão que não incluam o SNI são recusadas. Para obter mais informações, consulte Segurança de transporte no AWS IoT. Os clientes que usam usuários eAWS credenciais do IAM para autenticar clientes devem fornecer a autenticação correta do Signature versão 4.

Conectando-se com o MQTT usando os SDKs doAWS IoT dispositivo

Esta seção contém links para os SDKs doAWS IoT dispositivo e para o código-fonte de programas de amostra que ilustram como conectar um dispositivo aoAWS IoT. Os aplicativos de amostra vinculados aqui mostram como se conectarAWS IoT usando o protocolo MQTT e o MQTT via WSS.

nota

OsAWS IoT Device SDKs lançaram um cliente MQTT 5 em versão prévia para desenvolvedores. Durante o período de pré-visualização, podemos fazer alterações incompatíveis com versões anteriores nas APIs públicas, e os clientes de serviço nos SDKs deAWS IoT dispositivos continuarem usando o cliente MQTT 3.1.1.

C++

Usando o SDK do dispositivoAWS IoT C++ para conectar dispositivos

Python

Usando oAWS IoT Device SDK para Python para conectar dispositivos

JavaScript

Usando o SDK doAWS IoT dispositivo JavaScript para conectar dispositivos

Java

Usando oAWS IoT Device SDK for Java para conectar dispositivos

Embedded C

Usando oAWS IoT Device SDK for Embedded C para conectar dispositivos

Importante

Esse SDK é destinado ao uso por desenvolvedores experientes de software embarcado.

Opções de Qualidade de serviço (QoS) do MQTT

AWS IoTe os SDKs doAWS IoT dispositivo suportam os níveis de Qualidade de Serviço (QoS) do MQTT01 e. O protocolo MQTT define um terceiro nível de QoS2, nível, masAWS IoT não o suporta. Somente o protocolo MQTT suporta o recurso de QoS. O HTTPS suporta QoS passando um parâmetro de sequência de consulta?qos=qos em que o valor pode ser 0 ou 1.

Esta tabela descreve como cada nível de QoS afeta as mensagens publicadas para e pelo agente de mensagens.

Com um nível de QoS de...

A mensagem é...

Comentários

QoS nível 0

Enviado zero ou mais vezes

Esse nível deve ser usado para mensagens enviadas por meio de links de comunicação confiáveis ou que podem ser perdidas sem problemas.

QoS nível 1

Enviado pelo menos uma vez e, em seguida, repetidamente até que umaPUBACK resposta seja recebida

A mensagem não é considerada completa até que o remetente receba umaPUBACK resposta que indique uma entrega bem-sucedida.

Sessões persistentes do MQTT

As sessões persistentes armazenam as assinaturas e mensagens de um cliente, com uma qualidade de serviço (QoS) de 1, que não foram reconhecidas pelo cliente. Quando um dispositivo desconectado se reconecta a uma sessão persistente, a sessão é retomada, suas assinaturas são restabelecidas e o dispositivo envia mensagens inscritas recebidas antes da reconexão que não foram confirmadas pelo cliente.

Criar uma sessão persistente

No MQTT 3, você cria uma sessão persistente do MQTT enviando umaCONNECT mensagem e definindo ocleanSession sinalizador como0. Se não existir nenhuma sessão para o cliente que está enviando aCONNECT mensagem, uma nova sessão persistente será criada. Se já existir uma sessão para o cliente, o cliente retoma a sessão existente. Para criar uma sessão limpa, você envia umaCONNECT mensagem e define acleanSession bandeira como1, e o corretor não armazenará nenhum estado da sessão quando o cliente se desconectar.

No MQTT 5, você lida com sessões persistentes definindo aClean Start bandeiraSession Expiry Interval e. O Clean Start controla o início da sessão de conexão e o final da sessão anterior. Quando você defineClean Start =1, uma nova sessão é criada e uma sessão anterior é encerrada se existir. Quando você defineClean Start =0, a sessão de conexão retoma uma sessão anterior, se ela existir. O intervalo de expiração da sessão controla o final da sessão de conexão. O intervalo de expiração da sessão especifica o tempo, em segundos (número inteiro de 4 bytes), em que uma sessão persistirá após a desconexão. A configuraçãoSession Expiry interval =0 faz com que a sessão seja encerrada imediatamente após a desconexão. Se o intervalo de expiração da sessão não for especificado na mensagem CONNECT, o padrão será 0.

Início limpo do MQTT 5 e expiração da sessão
Valor da propriedade Descrição
Clean Start= 1 Cria uma nova sessão e encerra uma sessão anterior, se houver uma.
Clean Start= 0 Retoma uma sessão se existir uma sessão anterior.
Session Expiry Interval> 0 Persiste em uma sessão.
Session Expiry interval= 0 Não persiste em uma sessão.

No MQTT 5, se você definirClean Start =1 eSession Expiry Interval =0, isso equivale a uma sessão limpa do MQTT 3. Se você definirClean Start =0 eSession Expiry Interval >0, isso equivale a uma sessão persistente do MQTT 3.

nota

As sessões persistentes da versão Cross MQTT (MQTT 3 e MQTT 5) não são suportadas. Uma sessão persistente do MQTT 3 não pode ser retomada como uma sessão do MQTT 5 e vice-versa.

Operações durante uma sessão persistente

Os clientes usam osessionPresent atributo na mensagem de conexão confirmada (CONNACK) para determinar se uma sessão persistente está presente. Em casosessionPresent1 afirmativo, uma sessão persistente está presente e todas as mensagens armazenadas para o cliente são entregues ao cliente imediatamente após o cliente receber aCONNACK, conforme descrito em Tráfego de mensagens após a reconexão com uma sessão persistente. Em casosessionPresent1 afirmativo, o cliente não precisa se inscrever novamente. No entanto, sesessionPresent estiver0, nenhuma sessão persistente está presente e o cliente deve se inscrever novamente em seus filtros de tópicos.

Depois que o cliente entra em uma sessão persistente, ele pode publicar mensagens e assinar filtros de tópicos sem nenhum sinalizador adicional em cada operação.

Tráfego de mensagens após a reconexão com uma sessão persistente

Uma sessão persistente representa uma conexão contínua entre um cliente e um agente de mensagens MQTT. Quando um cliente se conecta ao agente de mensagens usando uma sessão persistente, o agente de mensagens salva todas as assinaturas que o cliente faz durante a conexão. Quando o cliente se desconecta, o agente de mensagens armazena mensagens de QoS não confirmadas e novas mensagens de QoS 1 publicadas em tópicos nos quais o cliente está inscrito. As mensagens são armazenadas de acordo com o limite da conta. As mensagens que excederem o limite serão descartadas. Para obter mais informações sobre limites persistentes de mensagens, consulte AWS IoT Coreendpoints e cotas. Quando o cliente se reconecta à sessão persistente, todas as assinaturas são restabelecidas e todas as mensagens armazenadas são enviadas ao cliente a uma taxa máxima de 10 mensagens por segundo. No MQTT 5, se um QoS1 de saída com o intervalo de expiração da mensagem expirar quando um cliente estiver off-line, depois que a conexão for retomada, o cliente não receberá a mensagem expirada.

Após a reconexão, as mensagens armazenadas são enviadas ao cliente, a uma taxa limitada a 10 mensagens armazenadas por segundo, junto com qualquer tráfego de mensagens atual até que o Publish requests per second per connectionlimite seja atingido. Como a taxa de entrega das mensagens armazenadas é limitada, serão necessários alguns segundos para entregar todas as mensagens armazenadas se uma sessão tiver mais de 10 mensagens armazenadas para serem entregues após a reconexão.

Encerrar uma sessão persistente

As sessões persistentes podem ser encerradas das seguintes maneiras:

  • O tempo de expiração da sessão persistente termina. O cronômetro de expiração persistente da sessão começa quando o agente de mensagens detecta que um cliente se desconectou, seja pela desconexão do cliente ou pelo tempo limite da conexão.

  • O cliente envia umaCONNECT mensagem que define acleanSession bandeira como1.

No MQTT 3, o valor padrão do tempo de expiração das sessões persistentes é uma hora, e isso se aplica a todas as sessões na conta.

No MQTT 5, você pode definir o intervalo de expiração da sessão para cada sessão nos pacotes CONNECT e DISCONNECT.

Para o intervalo de expiração da sessão no pacote DISCONNECT:

  • Se a sessão atual tiver um intervalo de expiração de sessão de 0, você não poderá definir o intervalo de expiração da sessão como maior que 0 no pacote DISCONNECT.

  • Se a sessão atual tiver um intervalo de expiração de sessão maior que 0 e você definir o intervalo de expiração da sessão como 0 no pacote DISCONNECT, a sessão será encerrada em DISCONNECT.

  • Caso contrário, o intervalo de expiração da sessão no pacote DISCONNECT atualizará o intervalo de expiração da sessão atual.

nota

As mensagens armazenadas à espera de serem enviadas ao cliente quando uma sessão termina são descartadas; no entanto, elas ainda são cobradas de acordo com a taxa padrão de mensagens, mesmo que não possam ser enviadas. Para obter mais informações sobre preços de mensagens, consulte AWS IoT CorePreços. Você pode configurar o intervalo de tempo de expiração.

Reconexão após a expiração de uma sessão persistente

Se um cliente não se reconectar à sessão persistente antes de ela expirar, a sessão será encerrada e as mensagens armazenadas serão descartadas. Quando um cliente se reconecta após a expiração da sessão com umcleanSession sinalizador para0, o serviço cria uma nova sessão persistente. Todas as assinaturas ou mensagens da sessão anterior não estão disponíveis para esta sessão porque foram descartadas quando a sessão anterior expirou.

Cobranças de mensagens de sessão persistentes

As mensagens são cobradasConta da AWS quando o agente de mensagens envia uma mensagem para um cliente ou uma sessão persistente offline. Quando um dispositivo offline com uma sessão persistente se reconecta e retoma sua sessão, as mensagens armazenadas são entregues no dispositivo e cobradas em sua conta novamente. Para obter mais informações sobre preços de mensagens, consulte AWS IoT CorePreços - Mensagens.

O tempo de expiração padrão da sessão persistente de uma hora pode ser aumentado usando o processo padrão de aumento de limite. Observe que aumentar o tempo de expiração da sessão pode aumentar as cobranças de suas mensagens porque o tempo adicional pode permitir que mais mensagens sejam armazenadas no dispositivo off-line e essas mensagens adicionais seriam cobradas em sua conta de acordo com a taxa padrão de mensagens. O tempo de expiração da sessão é aproximado e uma sessão pode persistir por até 30 minutos a mais do que o limite da conta; no entanto, uma sessão não será menor do que o limite da conta. Para obter mais informações sobre limites de sessão, consulte AWSService Quotas.

Mensagens retidas do MQTT

AWS IoT Coresuporta o sinalizador RETAIN descrito no protocolo MQTT. Quando um cliente define o sinalizador RETAIN em uma mensagem MQTT que ele publica,AWS IoT Core salva a mensagem. Em seguida, ele pode ser enviado para novos assinantes, recuperado chamando a GetRetainedMessageoperação e visualizado no AWS IoTconsole.

Exemplos de uso de mensagens retidas do MQTT
  • Como mensagem de configuração inicial

    As mensagens retidas do MQTT são enviadas a um cliente depois que o cliente se inscreve em um tópico. Se você quiser que todos os clientes que assinam um tópico recebam a mensagem retida do MQTT imediatamente após a assinatura, você pode publicar uma mensagem de configuração com o sinalizador RETAIN definido. Os clientes assinantes também recebem atualizações dessa configuração sempre que uma nova mensagem de configuração é publicada.

  • Como a última mensagem de estado conhecida

    Os dispositivos podem definir o sinalizador RETAIN nas mensagens do estado atual paraAWS IoT Core salvá-las. Quando os aplicativos se conectam ou se reconectam, eles podem se inscrever neste tópico e obter o último estado relatado imediatamente após se inscreverem no tópico da mensagem retida. Dessa forma, eles podem evitar a necessidade de esperar até a próxima mensagem do dispositivo para ver o estado atual.

Tarefas comuns com mensagens retidas do MQTT emAWS IoT Core

AWS IoT Coresalva mensagens MQTT com o conjunto de sinalizadores RETAIN. Essas mensagens retidas são enviadas a todos os clientes que se inscreveram no tópico, como uma mensagem normal do MQTT, e também são armazenadas para serem enviadas aos novos assinantes do tópico.

As mensagens retidas do MQTT exigem ações políticas específicas para autorizar os clientes a acessá-las. Para obter exemplos de uso de políticas de mensagens retidas, consulteExemplos de política de mensagens retidas.

Esta seção descreve operações comuns que envolvem mensagens retidas.

  • Criação de uma mensagem retida

    O cliente determina se uma mensagem é retida ao publicar uma mensagem MQTT. Os clientes podem definir o sinalizador RETAIN ao publicarem uma mensagem usando um SDK do dispositivo. Aplicativos e serviços podem definir o sinalizador RETAIN quando usam a Publishação para publicar uma mensagem MQTT.

    Somente uma mensagem por nome de tópico é mantida. Uma nova mensagem com o sinalizador RETAIN definido como publicado em um tópico substitui qualquer mensagem retida existente que tenha sido enviada ao tópico anteriormente.

    OBSERVAÇÃO: você não pode publicar em um tópico reservado com o sinalizador RETAIN definido.

  • Inscrever-se em um tópico de mensagem retido

    Os clientes assinam tópicos de mensagens retidos como fariam com qualquer outro tópico de mensagem do MQTT. As mensagens retidas recebidas ao se inscrever em um tópico de mensagem retida têm o sinalizador RETAIN definido.

    As mensagens retidas são excluídasAWS IoT Core quando um cliente publica uma mensagem retida com uma carga de mensagem de 0 bytes no tópico da mensagem retida. Os clientes que se inscreveram no tópico da mensagem retida também receberão a mensagem de 0 byte.

    A assinatura de um filtro curinga de tópico que inclui um tópico de mensagem retida permite que o cliente receba mensagens subsequentes publicadas no tópico da mensagem retida, mas ele não entrega a mensagem retida no momento da assinatura.

    OBSERVAÇÃO: Para receber uma mensagem retida no momento da assinatura, o filtro de tópico na solicitação de assinatura deve corresponder exatamente ao tópico da mensagem retida.

    As mensagens retidas recebidas ao se inscrever em um tópico de mensagem retida têm o sinalizador RETAIN definido. As mensagens retidas que são recebidas por um cliente assinante após a assinatura, não o são.

  • Recuperando uma mensagem retida

    As mensagens retidas são entregues aos clientes automaticamente quando eles assinam o tópico com a mensagem retida. Para que um cliente receba a mensagem retida no momento da assinatura, ele deve assinar o nome exato do tópico da mensagem retida. A assinatura de um filtro de tópico curinga que inclui um tópico de mensagem retida permite que o cliente receba mensagens subsequentes publicadas no tópico da mensagem retida, mas ele não entrega a mensagem retida no momento da assinatura.

    Serviços e aplicativos podem listar e recuperar mensagens retidas ligando para ListRetainedMessagesGetRetainedMessagee.

    Um cliente não está impedido de publicar mensagens em um tópico de mensagem retida sem definir o sinalizador RETAIN. Isso pode causar resultados inesperados, como a mensagem retida não corresponder à mensagem recebida ao se inscrever no tópico.

    Com o MQTT 5, se uma mensagem retida tiver o intervalo de expiração da mensagem definido e a mensagem retida expirar, um novo assinante que se inscrever nesse tópico não receberá a mensagem retida após a assinatura bem-sucedida.

  • Listando tópicos de mensagens retidas

    Você pode listar as mensagens retidas ligando ListRetainedMessagese as mensagens retidas podem ser visualizadas no AWS IoTconsole.

  • Obter detalhes da mensagem retida

    Você pode obter detalhes da mensagem retidos ligando GetRetainedMessagee eles podem ser visualizados no AWS IoTconsole.

  • Retendo uma mensagem de testamento

    As mensagens do MQTT Will criadas quando um dispositivo se conecta podem ser retidas definindo aWill Retain bandeira noConnect Flag bits campo.

  • Excluir mensagem retida

    Dispositivos, aplicativos e serviços podem excluir uma mensagem retida publicando uma mensagem com o sinalizador RETAIN definido e uma carga de mensagem vazia (0 bytes) no nome do tópico da mensagem retida a ser excluída. Essas mensagens excluem a mensagem retida deAWS IoT Core, são enviadas aos clientes com uma assinatura do tópico, mas não são retidas porAWS IoT Core.

    As mensagens retidas também podem ser excluídas interativamente acessando a mensagem retida no AWS IoTconsole. As mensagens retidas que são excluídas usando o AWS IoTconsole também enviam uma mensagem de 0 byte aos clientes que se inscreveram no tópico da mensagem retida.

    As mensagens retidas não podem ser restauradas após serem excluídas. Um cliente precisaria publicar uma nova mensagem retida para substituir a mensagem excluída.

  • Depuração e solução de problemas de mensagens retidas

    O AWS IoTconsole fornece várias ferramentas para ajudar você a solucionar problemas de mensagens retidas:

    • A página Mensagens retidas

      A página Mensagens retidas noAWS IoT console fornece uma lista paginada das mensagens retidas que foram armazenadas pela sua Conta na região atual. Nessa página, é possível:

      • Veja os detalhes de cada mensagem retida, como a carga útil da mensagem, a QoS e a hora em que ela foi recebida.

      • Atualize o conteúdo de uma mensagem retida.

      • Exclua uma mensagem retida.

    • O cliente de teste MQTT

      A página do cliente de teste MQTT noAWS IoT console pode se inscrever e publicar tópicos do MQTT. A opção de publicação permite que você defina o sinalizador RETAIN nas mensagens que você publica para simular como seus dispositivos podem se comportar.

    Alguns resultados inesperados podem ser o resultado desses aspectos de como as mensagens retidas são implementadas emAWS IoT Core.

    • Limites de mensagens mantidos

      Quando uma conta armazena o número máximo de mensagens retidas,AWS IoT Core retorna uma resposta limitada às mensagens publicadas com o conjunto RETAIN e cargas maiores que 0 bytes até que algumas mensagens retidas sejam excluídas e a contagem de mensagens retidas fique abaixo do limite.

    • Pedido de entrega de mensagens retido

      A sequência da mensagem retida e da entrega da mensagem assinada não é garantida.

Faturamento e mensagens retidas

A publicação de mensagens com a bandeira RETAIN definida por um cliente, usando oAWS IoT console ou ligando Publishgera cobranças adicionais de mensagens descritas em AWS IoT CorePreços - Mensagens.

A recuperação de mensagens retidas por um cliente, usando oAWS IoT console ou ligando GetRetainedMessagegera cobranças de mensagens, além das taxas normais de uso da API. As cobranças adicionais estão descritas em AWS IoT CorePreços - Mensagens.

As mensagens do MQTT Will publicadas quando um dispositivo se desconecta inesperadamente incorrerão em cobranças de mensagens descritas em AWS IoT CorePreços - Mensagens.

Para obter mais informações sobre os custos de mensagens, consulte AWS IoT CorePreços - Mensagens.

Comparando mensagens retidas do MQTT e sessões persistentes do MQTT

Mensagens retidas e sessões persistentes são recursos padrão do MQTT que possibilitam que os dispositivos recebam mensagens que foram publicadas enquanto estavam offline. As mensagens retidas podem ser publicadas a partir de sessões persistentes. Esta seção descreve os principais aspectos desses recursos e como eles funcionam juntos.

Mensagens retidas

Sessões persistentes

Recursos principais

As mensagens retidas podem ser usadas para configurar ou notificar grandes grupos de dispositivos após a conexão.

As mensagens retidas também podem ser usadas quando você deseja que os dispositivos recebam somente a última mensagem publicada em um tópico após uma reconexão.

As sessões persistentes são úteis para dispositivos que têm conectividade intermitente e podem perder várias mensagens importantes.

Os dispositivos podem se conectar a uma sessão persistente para receber mensagens enviadas enquanto estão off-line.

Exemplos

As mensagens retidas podem fornecer informações de configuração dos dispositivos sobre seu ambiente quando eles ficam on-line. A configuração inicial pode incluir uma lista de outros tópicos de mensagens nos quais ela deve se inscrever ou informações sobre como ela deve configurar seu fuso horário local.

Os dispositivos que se conectam por meio de uma rede celular com conectividade intermitente podem usar sessões persistentes para evitar a perda de mensagens importantes enviadas enquanto um dispositivo está fora da cobertura da rede ou precisa desligar o rádio celular.

Mensagens recebidas na assinatura inicial de um tópico

Depois de assinar um tópico com uma mensagem retida, a mensagem retida mais recente é recebida.

Depois de assinar um tópico sem uma mensagem retida, nenhuma mensagem é recebida até que uma seja publicada no tópico.

Tópicos inscritos após a reconexão

Sem uma sessão persistente, o cliente deve assinar os tópicos após a reconexão.

Os tópicos inscritos são restaurados após a reconexão.

Mensagens recebidas após a reconexão

Depois de assinar um tópico com uma mensagem retida, a mensagem retida mais recente é recebida.

Todas as mensagens publicadas com QOS = 1 e assinadas com QOS =1 enquanto o dispositivo estava desconectado são enviadas após a reconexão do dispositivo.

Expiração de dados/sessão

No MQTT 3, as mensagens retidas não expiram. Eles são armazenados até serem substituídos ou excluídos. No MQTT 5, as mensagens retidas expiram após o intervalo de expiração da mensagem definido. Para obter mais informações, consulte Mensagem de expiração.

As sessões persistentes expiram se o cliente não se reconectar dentro do período de tempo limite. Depois que uma sessão persistente expira, as assinaturas do cliente e as mensagens salvas que foram publicadas com QOS = 1 e assinadas com QOS =1 enquanto o dispositivo estava desconectado são excluídas. As mensagens expiradas não serão entregues. Para obter mais informações sobre expirações de sessão com sessões persistentes, consulteSessões persistentes do MQTT.

Para obter informações sobre sessões persistentes, consulteSessões persistentes do MQTT.

Com as mensagens retidas, o cliente de publicação determina se uma mensagem deve ser retida e entregue a um dispositivo após a conexão, independentemente de ter ocorrido uma sessão anterior ou não. A escolha de armazenar uma mensagem é feita pelo editor e a mensagem armazenada é entregue a todos os clientes atuais e future que assinam com assinaturas de QoS 0 ou QoS 1. As mensagens retidas mantêm apenas uma mensagem sobre um determinado tópico por vez.

Quando uma conta armazena o número máximo de mensagens retidas,AWS IoT Core retorna uma resposta limitada às mensagens publicadas com o conjunto RETAIN e cargas maiores que 0 bytes até que algumas mensagens retidas sejam excluídas e a contagem de mensagens retidas fique abaixo do limite.

MQTT reteve mensagens eAWS IoT Device Shadows

As mensagens retidas e as sombras do dispositivo retêm dados de um dispositivo, mas se comportam de maneira diferente e servem a propósitos diferentes. Esta seção descreve suas semelhanças e diferenças.

Mensagens retidas

Sombras de dispositivos

O payload de mensagens tem uma estrutura ou esquema predefinido

Conforme definido pela implementação. O MQTT não especifica uma estrutura ou esquema para sua carga de mensagens.

AWS IoTsuporta uma estrutura de dados específica.

A atualização da carga da mensagem gera mensagens de eventos

A publicação de uma mensagem retida envia a mensagem aos clientes inscritos, mas não gera mensagens de atualização adicionais.

A atualização de um Device Shadow produz mensagens de atualização que descrevem a alteração.

As atualizações de mensagens estão numeradas

As mensagens retidas não são numeradas automaticamente. Os documentos do Device Shadow têm números de versão e carimbos de data e hora automáticos.

A carga útil da mensagem está anexada a um recurso

As mensagens retidas não são anexadas a um recurso.

As sombras do dispositivo são anexadas a um recurso de coisa.

Atualização de elementos individuais da carga da mensagem

Elementos individuais da mensagem não podem ser alterados sem atualizar toda a carga da mensagem.

Elementos individuais de um documento Device Shadow podem ser atualizados sem a necessidade de atualizar todo o documento Device Shadow.

O cliente recebe dados da mensagem após a assinatura

O cliente recebe automaticamente uma mensagem retida depois de se inscrever em um tópico com uma mensagem retida.

Os clientes podem assinar as atualizações do Device Shadow, mas devem solicitar o estado atual deliberadamente.

Indexação e capacidade de pesquisa

As mensagens retidas não são indexadas para pesquisa.

A indexação da frota indexa os dados do Device Shadow para pesquisa e agregação.

Usar o ConnectAttributes

ConnectAttributespermitem que você especifique quais atributos você deseja usar em sua mensagem de conexão em suas políticas do IAM, comoPersistentConnectLastWill e. Com oConnectAttributes, você pode criar políticas que não forneçam aos dispositivos acesso a novos recursos por padrão, o que pode ser útil se um dispositivo for comprometido.

O connectAttributes oferece suporte aos seguintes recursos:

PersistentConnect

Use oPersistentConnect recurso para salvar todas as assinaturas feitas pelo cliente durante a conexão quando a conexão entre o cliente e o corretor for interrompida.

LastWill

Use oLastWill recurso para publicar uma mensagem noLastWillTopic quando um cliente se desconectar inesperadamente.

Por padrão, sua política tem uma conexão não persistente e não há atributos passados para essa conexão. Você deve especificar uma conexão persistente em sua política do IAM se quiser ter uma.

Para obterConnectAttributes exemplos, consulte Exemplos de políticas de Connect.

Recursos compatíveis com o MQTT 5

AWS IoT Coreo suporte para o MQTT 5 é baseado na especificação MQTT v5.0 com algumas diferenças, conforme documentado emAWS IoTdiferenças das especificações do MQTT.

Importante

No momento, não há suporte para assinaturas compartilhadas.

Uma lista dos recursos do MQTT 5AWS IoT Core compatíveis inclui:

Início limpo e expiração da sessão

Você pode usar o Clean Start e o Session Expiry para lidar com suas sessões persistentes com mais flexibilidade. Um sinalizador Clean Start indica se a sessão deve ser iniciada sem usar uma sessão existente. Um intervalo de expiração da sessão indica por quanto tempo manter a sessão após uma desconexão. O intervalo de expiração da sessão pode ser modificado na desconexão. Para obter mais informações, consulte Sessões persistentes do MQTT.

Código de motivo em todos os ACKs

Você pode depurar ou processar mensagens de erro com mais facilidade usando os códigos de motivo. Os códigos de motivo são retornados pelo agente de mensagens com base no tipo de interação com o corretor (assinar, publicar, confirmar). Para obter mais informações, consulte Códigos de motivos do MQTT. Para obter uma lista completa dos códigos de motivo do MQTT, consulte a especificação MQTT v5.

Aliases de tópicos

Você pode substituir o nome de um tópico por um alias de tópico, que é um número inteiro de dois bytes. O uso de aliases de tópicos pode otimizar a transmissão de nomes de tópicos para reduzir potencialmente os custos de dados em serviços de dados limitados. AWS IoT Coretem um limite padrão de 8 aliases de tópicos. Para obter mais informações, consulte AWS IoT Coreendpoints e cotas da ReferênciaAWS Geral.

Expiração da mensagem

Você pode adicionar valores de expiração de mensagens às mensagens publicadas. Esses valores representam o intervalo de expiração da mensagem em segundos. Se as mensagens não tiverem sido enviadas aos assinantes dentro desse intervalo, a mensagem expirará e será removida. Se você não definir o valor de expiração da mensagem, a mensagem não expirará.

Na saída, o assinante receberá uma mensagem com o tempo restante restante no intervalo de expiração. Por exemplo, se uma mensagem de publicação recebida tiver uma mensagem expirada de 30 segundos e for encaminhada para o assinante após 20 segundos, o campo de expiração da mensagem será atualizado para 10. É possível que a mensagem recebida pelo assinante tenha um MEI atualizado de 0. Isso ocorre porque, assim que o tempo restante for de 999 ms ou menos, ele será atualizado para 0.

EmAWS IoT Core, o intervalo mínimo de expiração da mensagem é 1. Se o intervalo for definido como 0 do lado do cliente, ele será ajustado para 1. O intervalo máximo de expiração da mensagem é 604800 (7 dias). Qualquer valor maior do que isso será ajustado para o valor máximo.

Na comunicação entre versões, o comportamento da expiração da mensagem é decidido pela versão MQTT da mensagem de publicação recebida. Por exemplo, uma mensagem com expiração de mensagem enviada por uma sessão conectada via MQTT5 pode expirar para dispositivos inscritos com sessões MQTT3. A tabela abaixo lista como a expiração de mensagens oferece suporte aos seguintes tipos de mensagens de publicação:

Tipo de mensagem de publicação Intervalo de expiração da mensagem
Publicação regular Se um servidor não entregar a mensagem dentro do tempo especificado, a mensagem expirada será removida e o assinante não a receberá. Isso inclui situações como quando um dispositivo não está publicando suas mensagens de QoS 1.
Reter Se uma mensagem retida expirar e um novo cliente assinar o tópico, o cliente não receberá a mensagem após a assinatura.
Vontade mais recente O intervalo para as últimas mensagens de testamento começa depois que o cliente se desconecta e o servidor tenta entregar a última mensagem de vontade aos assinantes.
Mensagens na fila Se um QoS1 de saída com intervalo de expiração de mensagem expirar quando um cliente estiver off-line, depois que a sessão persistente for retomada, o cliente não receberá a mensagem expirada.

Desconexão do servidor

Quando ocorre uma desconexão, o servidor pode enviar proativamente ao cliente uma DESCONEXÃO para notificar o encerramento da conexão com um código de motivo para a desconexão.

Solicitação/Resposta

Os editores podem solicitar que uma resposta seja enviada pelo destinatário para um tópico especificado pelo editor no momento da recepção.

Tamanho máximo do pacote

O cliente e o servidor podem especificar de forma independente o tamanho máximo do pacote que eles suportam.

Formato de carga e tipo de conteúdo

Você pode especificar o formato da carga (binário, texto) e o tipo de conteúdo quando uma mensagem é publicada. Eles são encaminhados para o destinatário da mensagem.

Propriedades do MQTT 5

As propriedades do MQTT 5 são adições importantes ao padrão MQTT para dar suporte aos novos recursos do MQTT 5, como a expiração da sessão e o padrão de solicitação/resposta. NoAWS IoT Core, você pode criar regras que possam encaminhar as propriedades nas mensagens de saída ou usar o HTTP Publish para publicar mensagens MQTT com algumas das novas propriedades.

A tabela a seguir lista todas as propriedades do MQTT 5AWS IoT Core compatíveis.

Propriedade Descrição Tipo de entrada Pacote
Indicador de formato da carga útil Um valor booleano que indica se a carga está formatada como UTF-8. Byte PUBLICAR, CONECTAR
Tipo de conteúdo Uma string UTF-8 que descreve o conteúdo da carga. Sequência de caracteres UTF-8 PUBLICAR, CONECTAR
Tópico de resposta Uma string UTF-8 que descreve o tópico no qual o receptor deve publicar como parte do fluxo de solicitação-resposta. O tópico não deve ter caracteres curinga. Sequência de caracteres UTF-8 PUBLICAR, CONECTAR
Dados de correlação Dados binários usados pelo remetente da mensagem de solicitação para identificar para qual solicitação a mensagem de resposta se destina. Binário PUBLICAR, CONECTAR
Propriedade do usuário Um par de strings UTF-8. Essa propriedade pode aparecer várias vezes em um pacote. Os destinatários receberão os pares de chave-valor na mesma ordem em que são enviados. Par de cordas UTF-8 CONECTAR, PUBLICAR, Will Properties, ASSINAR, DESCONECTAR, CANCELAR A ASSINATURA
Intervalo de expiração da mensagem Um número inteiro de 4 bytes que representa o intervalo de expiração da mensagem em segundos. Se estiver ausente, a mensagem não expira. Número inteiro de 4 bytes PUBLICAR, CONECTAR
Intervalo de expiração da sessão

Um número inteiro de 4 bytes que representa o intervalo de expiração da sessão em segundos. AWS IoT Coresuporta no máximo 7 dias, com um máximo padrão de uma hora. Se o valor definido exceder o máximo da sua conta,AWS IoT Core retornará o valor ajustado no CONNACK.

Número inteiro de 4 bytes CONECTAR, CONECTAR, DESCONECTAR
Identificador de cliente atribuído Um ID de cliente aleatório geradoAWS IoT Core quando um ID de cliente não é especificado pelos dispositivos. O ID aleatório do cliente deve ser um novo identificador de cliente que não seja usado por nenhuma outra sessão gerenciada atualmente pelo corretor. Sequência de caracteres UTF-8 CONNACK
Servidor Keep Alive Um número inteiro de 2 bytes que representa o tempo de manutenção atribuído pelo servidor. O servidor desconectará o cliente se ele ficar inativo por mais tempo do que o tempo de manutenção. Número inteiro de 2 bytes CONNACK
Solicitar informações sobre o problema Um valor booleano que indica se a sequência de caracteres do motivo ou as propriedades do usuário são enviadas no caso de falhas. Byte CONNECT
Receção máxima Um número inteiro de 2 bytes que representa o número máximo de pacotes PUBLISH QOS > 0 que podem ser enviados sem receber um PUBACK. Número inteiro de 2 bytes CONECTAR, CONECTAR
Máximo de alias do tópico Esse valor indica o valor mais alto que será aceito como um alias de tópico. O padrão é 0. Número inteiro de 2 bytes CONECTAR, CONECTAR
QoS máxima O valor máximo de QoS queAWS IoT Core suporta. O padrão é 1. AWS IoT Corenão suporta QoS2. Byte CONNACK
Manter disponível

Um valor booleano que indica se o agente deAWS IoT Core mensagens suporta mensagens retidas. O padrão é 1.

Byte CONNACK
Tamanho máximo do pacote O tamanho máximo do pacote queAWS IoT Core aceita e envia. Não pode exceder 128 KB. Número inteiro de 4 bytes CONECTAR, CONECTAR
Assinatura Wildcard disponível

Um valor booleano que indica se o agente deAWS IoT Core mensagens oferece suporte à assinatura Wildcard Available. O padrão é 1.

Byte CONNACK
Identificador de assinatura disponível

Um valor booleano que indica se o agente deAWS IoT Core mensagens oferece suporte ao Identificador de Assinatura Disponível. O padrão é 0.

Byte CONNACK

Códigos de motivos do MQTT

O MQTT 5 introduz relatórios de erros aprimorados com respostas do código de motivo. AWS IoT Corepode retornar códigos de motivo, incluindo, mas não se limitando aos seguintes, agrupados por pacotes. Para obter uma lista completa dos códigos de motivo suportados pelo MQTT 5, consulte as especificações do MQTT 5.

Códigos de motivo do CONNACK
Valor Feitiço Nome do código do motivo Descrição
0 0x00 Bem-sucedida A conexão é aceita.
128 0x80 Erro não especificado O servidor não deseja revelar o motivo da falha ou nenhum dos outros motivos pelos quais os códigos se aplicam.
133 0x85 Identificador de cliente não válido O identificador do cliente é uma string válida, mas não é permitido pelo servidor.
134 0x86 Nome de usuário ou senha incorretos O servidor não aceita o nome de usuário ou a senha especificados pelo cliente.
135 0x87 Não autorizado O cliente não está autorizado a se conectar.
144 0x90 Nome do tópico inválido O nome do tópico do testamento está formado corretamente, mas não é aceito pelo servidor.
151 0x97 Cota excedida Um limite de implementação ou imposto administrativo foi excedido.
155 0x9B QoS sem suporte O servidor não suporta o QoS definido em Will QoS.
Códigos de motivo do PUBACK
Valor Feitiço Nome do código do motivo Descrição
0 0x00 Bem-sucedida A mensagem foi aceita. A publicação da mensagem de QoS 1 continua.
128 0x80 Erro não especificado O destinatário não aceita a publicação, mas não quer revelar o motivo ou ela não corresponde a um dos outros valores.
135 0x87 Não autorizado O PUBLISH não está autorizado.
144 0x90 Nome do tópico inválido O nome do tópico não está mal formado, mas não é aceito pelo cliente ou servidor.
145 0x91 Identificador de pacote em uso O identificador do pacote já está em uso. Isso pode indicar uma incompatibilidade no estado da sessão entre o cliente e o servidor.
151 0x97 Cota excedida Um limite de implementação ou imposto administrativo foi excedido.
Códigos de motivo da DESCONEXÃO
Valor Feitiço Nome do código do motivo Descrição
129 0x81 Pacote malformado O pacote recebido não está em conformidade com essa especificação.
130 0x82 Erro de protocolo Um pacote inesperado ou fora de ordem foi recebido.
135 0x87 Não autorizado A solicitação não está autorizada.
139 0x8B Desligamento do servidor O servidor está sendo desligado.
141 0x8D Tempo limite do Keep Alive A conexão está fechada porque nenhum pacote foi recebido por 1,5 vezes o tempo de Keep Alive.
142 0x8E Sessão assumida Outra conexão usando o mesmo ClientID foi conectada, fazendo com que essa conexão fosse fechada.
143 0x8F Filtro de tópicos inválido O filtro de tópicos está formado corretamente, mas não é aceito pelo servidor.
144 0x90 Nome do tópico inválido O nome do tópico está formado corretamente, mas não é aceito por esse cliente ou servidor.
147 0x93 Maximum (Máximo de recepção O cliente ou servidor recebeu mais do que a publicação Receive Maximum para a qual não enviou PUBACK ou PUBCOMP.
148 0x94 Alias do tópico inválido O cliente ou servidor recebeu um pacote PUBLISH contendo um alias de tópico maior do que o alias máximo de tópico enviado no pacote CONNECT ou CONNACK.
151 0x97 Cota excedida Um limite de implementação ou imposto administrativo foi excedido.
152 0x98 Ação administrativa A conexão foi encerrada devido a uma ação administrativa.
155 0x9B QoS sem suporte O cliente especificou uma QoS maior que a QoS especificada em uma QoS máxima no CONNACK.
161 0xA1 Identificadores de assinatura não suportados O servidor não oferece suporte a identificadores de assinatura; a assinatura não é aceita.
Códigos de motivo do SUBACK
Valor Feitiço Nome do código do motivo Descrição
0 0x00 QoS concedido 0 A assinatura é aceita e o QoS máximo enviado será QoS 0. Isso pode ser um QoS menor do que o solicitado.
1 0x01 QoS 1 concedido A assinatura é aceita e o QoS máximo enviado será QoS 1. Isso pode ser um QoS menor do que o solicitado.
128 0x80 Erro não especificado A assinatura não é aceita e o Servidor não deseja revelar o motivo ou nenhum dos outros Códigos de Motivo se aplica.
135 0x87 Não autorizado O cliente não está autorizado a fazer esta assinatura.
143 0x8F Filtro de tópicos inválido O filtro de tópicos está formado corretamente, mas não é permitido para este cliente.
145 0x91 Identificador de pacote em uso O identificador de pacote especificado já está em uso.
151 0x97 Cota excedida Um limite de implementação ou imposto administrativo foi excedido.
Códigos de motivo do UNSUBACK
Valor Feitiço Nome do código do motivo Descrição
0 0x00 Bem-sucedida A assinatura é excluída.
128 0x80 Erro não especificado O cancelamento da assinatura não pôde ser concluído e o Servidor não deseja revelar o motivo ou nenhum dos outros Códigos de Motivo se aplica.
143 0x8F Filtro de tópicos inválido O filtro de tópicos está formado corretamente, mas não é permitido para este cliente.
145 0x91 Identificador de pacote em uso O identificador de pacote especificado já está em uso.

AWS IoTdiferenças das especificações do MQTT

A implementação do agente de mensagens é baseada na especificação MQTT v3.1.1 e na especificação MQTT v5.0, mas difere das especificações das seguintes maneiras:

  • AWS IoTnão suporta os seguintes pacotes para MQTT 3: PUBREC, PUBREL e PUBCOMP.

  • AWS IoTnão suporta os seguintes pacotes para MQTT 5: PUBREC, PUBREL, PUBCOMP e AUTH.

  • AWS IoTnão suporta o redirecionamento do servidor MQTT 5.

  • AWS IoTsuporta somente os níveis 0 e 1 de qualidade de serviço (QoS) do MQTT. AWS IoTnão suporta publicação ou assinatura com QoS nível 2. Quando o nível 2 de QoS é solicitado, o agente de mensagens não envia um PUBACK ou SUBACK.

  • No AWS IoT, a assinatura de um tópico com nível 0 da QoS significa que uma mensagem é entregue zero ou mais vezes. Uma mensagem pode ser entregue mais de uma vez. As mensagens entregues mais de uma vez podem ser enviadas com outro ID de pacote. Nesses casos, o sinalizador DUP não é definido.

  • Ao responder a uma solicitação de conexão, o operador de mensagens envia uma mensagem CONNACK. Essa mensagem contém um sinalizador para indicar se a conexão está retomando uma sessão anterior.

  • Antes de enviar pacotes de controle adicionais ou uma solicitação de desconexão, o cliente deve esperar que a mensagem CONNACK seja recebida em seu dispositivo pelo agente deAWS IoT mensagens.

  • Quando um cliente se inscreve em um tópico, pode haver uma demora entre o momento em que o operador envia uma mensagem SUBACK e o momento em que o cliente começa a receber novas mensagens correspondentes.

  • Quando um cliente usa o caractere curinga# no filtro de tópico para assinar um tópico, todas as sequências de caracteres em seu nível e abaixo dele na hierarquia de tópicos são correspondidas. No entanto, o tópico principal não é compatível. Por exemplo, uma assinatura do tópicosensor/# recebe mensagens publicadas nos tópicossensor/,,sensor/temperaturesensor/temperature/room1, mas não mensagens publicadas emsensor. Para obter mais informações sobre curingas, consulteFiltros de tópicos.

  • O operador de mensagens usa o ID do cliente para identificar cada cliente. O ID do cliente é transmitido do cliente para o operador de mensagens como parte da carga útil do MQTT. Dois clientes com o mesmo ID de cliente não podem ser conectados simultaneamente ao agente de mensagens. Quando um cliente se conecta ao agente de mensagens usando um ID que outro cliente está usando, a nova conexão do cliente é aceita e o cliente conectado anteriormente é desconectado.

  • Em raras ocasiões, o operador de mensagens pode reenviar a mesma mensagem lógica PUBLISH com um ID de pacote diferente.

  • A assinatura de filtros de tópicos que contêm um caractere curinga não pode receber mensagens retidas. Para receber uma mensagem retida, a solicitação de inscrição deve conter um filtro de tópico que corresponda exatamente ao tópico da mensagem retida.

  • O agente de mensagens não garante a ordem em que as mensagens e o ACK são recebidos.

  • AWS IoTpodem ter limites diferentes das especificações. Para obter mais informações, consulte os limites e cotas do intermediário deAWS IoT Core mensagens e do protocolo do Guia deAWS IoT referência.