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

MQTTÉ um protocolo de sistema de mensagens leve amplamente adotado projetado para dispositivos com restrições.AWS IoTsuporte para MQTT é baseado noEspecificação MQTT v3.1.1, com algumas diferenças. Para obter informações sobre comoAWS IoTDifere da especificação MQTT v3.1.1, consulteAWS IoTDiferenças da especificação MQTT versão 3.1.1.

AWS IoT Coresuporta conexões de dispositivo que usam o protocolo MQTT e o protocolo MQTT sobre WSS e que são identificados por umID de cliente. OSDKs de dispositivo da AWS IoTsuporta ambos os protocolos e são as formas recomendadas de conectar dispositivos aAWS IoT. OAWS IoTOs SDKs de dispositivos suportam as funções necessárias para que dispositivos e clientes se conectem e acessemAWS IoT CoreServiços da . Os Device SDKs suportam os protocolos de autenticação que oAWS IoTos serviços exigem e os requisitos de ID de conexão que o protocolo MQTT e os protocolos MQTT sobre WSS exigem. Para obter informações sobre como se conectar aoAWS IoTUsando oAWSSDKs de dispositivos e links para exemplos deAWS IoTNos idiomas compatíveis, consulteConectando com o MQTT usando oAWS IoTSDKs de dispositivo da. Para obter mais informações sobre os métodos de autenticação e os mapeamentos de porta para mensagens MQTT, consulteProtocolos, mapeamentos de porta e autenticação.

Embora recomendamos usar oAWS IoTSDKs de dispositivo para se conectarAWS IoT, eles não são obrigatórios. Se você não usar oAWS IoTOs SDKs do dispositivo, no entanto, você deve fornecer a segurança de conexão e comunicação necessária. Os clientes devem enviar oExtensão TLS da Server Name Indication (SNI)na solicitação de conexão. Tentativas de conexão que não incluem o SNI são recusadas. Para obter mais informações, consulte Segurança de transporte no AWS IoT. Clientes que usam usuários do IAM eAWScredenciais para autenticar clientes devem fornecer o corretoSignature versão 4Autenticação.

Conectando com o MQTT usando oAWS IoTSDKs de dispositivo da

Esta seção contém links para aAWS IoTSDKs de dispositivos e para o código-fonte de programas de amostra que ilustram como conectar um dispositivo aAWS IoT. Os aplicativos de amostra vinculados aqui mostram como se conectar aoAWS IoTUsando o protocolo MQTT e MQTT sobre WSS.

C++

Usar oAWS IoTSDK de dispositivo C++ para conectar dispositivos

Python

Usar oAWS IoTSDK de dispositivo para Python para conectar dispositivos

JavaScript

Usar oAWS IoTSDK de dispositivo da para JavaScript Para conectar dispositivos

Java

Usar oAWS IoTSDK de dispositivo para Java para conectar dispositivos

Embedded C

Usar oAWS IoTSDK de dispositivo da para C incorporado para conectar dispositivos

Importante

Este SDK destina-se ao uso por desenvolvedores experientes de software incorporado.

Opções de qualidade de serviço (QoS) MQTT

AWS IoTO e aAWS IoTOs SDKs do dispositivo oferecem suporte aoNíveis de qualidade de serviço (QoS) MQTT0e1. O protocolo MQTT define um terceiro nível de QoS, nível2, masAWS IoTO não oferece suporte a ele. Somente o protocolo MQTT suporta o recurso QoS. HTTPS suporta QoS passando um parâmetro de string de consulta?qos=qosonde o valor pode ser 0 ou 1.

Esta tabela descreve como cada nível de QoS afeta as mensagens publicadas para e pelo corretor 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 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é umPUBACKresposta é recebida

A mensagem não é considerada completa até que o remetente receba umPUBACKresposta para indicar entrega bem-sucedida.

Usar sessões persistentes do MQTT

Sessões persistentes armazenam 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 as mensagens inscritas recebidas antes da reconexão e que não foram reconhecidas pelo cliente são enviadas ao cliente.

Criando uma sessão persistente

Você cria uma sessão persistente do MQTT ao enviar umCONNECTmensagem e configuração docleanSessionSinalizador para0. Se nenhuma sessão existir para o cliente enviar aCONNECTmensagem, uma nova sessão persistente é criada. Se uma sessão já existir para o cliente, o cliente retomará a sessão existente.

Operações durante uma sessão persistente

Os clientes usam osessionPresentatributo na conexão confirmada (CONNACK) mensagem para determinar se uma sessão persistente está presente. SesessionPresenté1Uma sessão persistente está presente e quaisquer mensagens armazenadas para o cliente são entregues ao cliente imediatamente após o cliente receber oCONNACK, conforme descrito emTráfego de mensagens após a reconexão com uma sessão persistente. SesessionPresenté1, não há necessidade de o cliente reenviar. No entanto, sesessionPresenté0, nenhuma sessão persistente está presente e o cliente deve se inscrever novamente em seus filtros de tópico.

Depois que o cliente ingressa em uma sessão persistente, ele poderá publicar mensagens e assinar filtros de tópico 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 da usando uma sessão persistente, o agente de mensagens salva todas as inscrições 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 excedam esse limite serão descartadas. Para obter mais informações sobre limites de mensagens persistentes, consulteAWS IoT CoreEndpoints e cotas do. Quando o cliente se conecta novamente à sessão persistente, todas as inscrições são restabelecidas e todas as mensagens armazenadas são enviadas ao cliente a uma taxa máxima de 10 mensagens por segundo.

Após a reconexão, as mensagens armazenadas são enviadas para o cliente, a uma taxa limitada a 10 mensagens armazenadas por segundo, juntamente com qualquer tráfego de mensagens atual até oPublish requests per second per connectionLimite é atingido. Como a taxa de entrega das mensagens armazenadas é limitada, levará vários 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.

Encerrando uma sessão persistente

As seguintes condições descrevem como as sessões persistentes podem terminar.

  • Quando o tempo de expiração da sessão persistente decorre. O temporizador de expiração de sessão persistente começa quando o agente de mensagens detecta que um cliente foi desconectado, seja pela desconexão do cliente ou pelo tempo limite da conexão.

  • Quando o cliente envia umCONNECTmensagem que define ocleanSessionSinalizador para1.

nota

As mensagens armazenadas aguardando para serem enviadas ao cliente quando uma sessão termina são descartadas; no entanto, elas ainda são cobradas na taxa de mensagens padrão, mesmo que não pudessem ser enviadas. Para obter mais informações sobre definição de preço de mensagens, consulteAWS IoT CoreDefinição de preç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 expirar, a sessão será encerrada e suas mensagens armazenadas serão descartadas. Quando um cliente se reconecta após a sessão expirar com umcleanSessionSinalizador para0, o serviço cria uma nova sessão persistente. Quaisquer 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 mensagem de sessão persistente

As mensagens são cobradas em seuConta da AWSquando o corretor de mensagens envia uma mensagem para um cliente ou uma sessão persistente offline. Quando um dispositivo off-line com uma sessão persistente se reconecta e retoma sua sessão, as mensagens armazenadas são entregues ao dispositivo e cobradas em sua conta novamente. Para obter mais informações sobre definição de preço de mensagens, consulteAWS IoT Corepreços - Mensagens.

O tempo de expiração da sessão persistente padrão de uma hora pode ser aumentado usando o processo de aumento de limite padrão. Observe que aumentar o tempo de expiração da sessão pode aumentar as cobranças de mensagens porque o tempo adicional pode permitir que mais mensagens sejam armazenadas para o dispositivo off-line e essas mensagens adicionais seriam cobradas na sua conta na taxa de mensagens padrão. 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 que o limite da conta. Para obter mais informações sobre limites de sessão, consulteAWSCotas de serviço do.

Usar mensagens retidas do MQTT

AWS IoT Coresuporta o sinalizador RETAIN descrito emMQTT v3.1.1. Quando um cliente define o sinalizador RETAIN em uma mensagem MQTT publicada,AWS IoT Coresalva a mensagem. Ele pode então ser enviado para novos assinantes, recuperado chamando oGetRetainedMessageoperação, e visualizado naAWS IoTconsole.AWS IoT Corearmazena mensagens retidas por três anos após a última vez em que foram atualizadas ou acessadas. Após três anos, as mensagens são excluídas.

Exemplos de uso de mensagens retidas do MQTT

  • Como mensagem de configuração inicial

    As mensagens retidas da MQTT são enviadas a um cliente depois que o cliente assina um tópico. Se você quiser que todos os clientes que assinam um tópico recebam a mensagem mantida 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 última mensagem de estado conhecida

    Os dispositivos podem definir o sinalizador RETAIN em mensagens de estado atual para queAWS IoT Coreos salvará. 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 inscrever no tópico da mensagem retida. Dessa forma, eles podem evitar ter que 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 sinalizador RETAIN definido. EstesMensagens retidassão enviados para todos os clientes que se inscreveram no tópico, como uma mensagem MQTT normal, e eles também são armazenados para serem enviados para novos assinantes do tópico.

As mensagens retidas do MQTT exigem ações de política 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.

  • Criando uma mensagem retida

    O cliente determina se uma mensagem é mantida quando publica uma mensagem MQTT. Os clientes podem definir o sinalizador RETAIN quando publicarem uma mensagem usando umSDK de dispositivo da. Aplicativos e serviços podem definir o sinalizador RETAIN quando eles usam oPublishaçãopara publicar uma mensagem MQTT.

    Apenas uma mensagem por nome de tópico é mantida. Uma nova mensagem com o sinalizador RETAIN publicado em um tópico substitui qualquer mensagem mantida existente enviada para o tópico anteriormente.

    OBSERVAÇÃO: Você não pode publicar em umTópico reservadocom o sinalizador RETAIN definido.

  • Assinatura de um tópico de mensagem retida

    Os clientes assinam tópicos de mensagens retidas como fariam com qualquer outro tópico de mensagem MQTT. As mensagens retidas recebidas por assinatura de um tópico de mensagem retida têm o sinalizador RETAIN definido.

    As mensagens retidas são excluídas doAWS IoT Corequando um cliente publica uma mensagem retida com uma carga útil 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 bytes.

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

    OBSERVAÇÃO: Para receber uma mensagem retida após a 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 assinar um tópico de mensagem retida têm o sinalizador RETAIN definido. Mensagens retidas recebidas por um cliente assinante após a assinatura, não.

  • Recuperando uma mensagem retida

    As mensagens retidas são entregues aos clientes automaticamente quando eles se inscrevem no tópico com a mensagem retida. Para que um cliente receba a mensagem retida após a assinatura, ele deve se inscrever no nome exato do tópico da mensagem retida. Assinar 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 não entrega a mensagem retida após a assinatura.

    Serviços e aplicativos podem listar e recuperar mensagens retidas chamandoListRetainedMessageseGetRetainedMessage.

    Um cliente não é impedido de publicar mensagens em um tópico de mensagem retidasemdefinindo o sinalizador RETAIN. Isso pode causar resultados inesperados, como a mensagem retida não corresponder à mensagem recebida assinando o tópico.

  • Listando tópicos de mensagens retidas

    Você pode listar mensagens retidas chamandoListRetainedMessagese as mensagens retidas podem ser visualizadas naAWS IoTconsole.

  • Obtendo detalhes da mensagem retida

    Você pode obter detalhes da mensagem retida ligandoGetRetainedMessagee eles podem ser visualizados noAWS IoTconsole.

  • Mantendo uma mensagem de testamento

    MQTTWillmensagensque são criados quando um dispositivo se conecta pode ser mantido definindo oWill RetainSinalizador noConnect Flag bitscampo.

  • Excluir uma 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) para o nome do tópico da mensagem retida a ser excluída. Essas mensagens excluem a mensagem retida deAWS IoT Core, são enviados para clientes com uma assinatura do tópico, mas eles não são retidos porAWS IoT Core.

    As mensagens retidas também podem ser excluídas interativamente acessando a mensagem retida naAWS IoTconsole. Mensagens retidas que são excluídas usando oAWS IoTconsoletambém envia uma mensagem de 0 bytes para 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 tomar o lugar da mensagem excluída.

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

    OAWS IoTconsoleFornece várias ferramentas para ajudá-lo a solucionar problemas de mensagens retidas:

    • OMensagens retidaspágina

      OMensagens retidasna página doAWS IoTconsole fornece uma lista paginada das mensagens retidas que foram armazenadas por sua Conta na Região atual. Nessa página, é possível:

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

      • Atualize o conteúdo de uma mensagem retida.

      • Exclua uma mensagem retida.

    • OCliente de teste MQTT

      OCliente de teste MQTTna página doAWS IoTO console pode assinar e publicar em tópicos do MQTT. A opção de publicação permite que você defina o sinalizador RETAIN nas mensagens publicadas 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 retidos

      Quando uma conta tiver armazenado o número máximo de mensagens retidas,AWS IoT Coreretorna uma resposta limitada às mensagens publicadas com o conjunto RETAIN e cargas úteis 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 mensagem retida

      A sequência de mensagens retidas e entrega de mensagens inscritas não é garantida.

Mensagens de cobrança e retidas

Publicando mensagens com o sinalizador RETAIN definido a partir de um cliente, usandoAWS IoTconsole ou chamandoPublishincorre em cobranças adicionais de mensagens descritas emAWS IoT Corepreços - Mensagens.

Recuperando mensagens retidas por um cliente, usandoAWS IoTconsole ou chamandoGetRetainedMessageincorre em cobranças de mensagens além das cobranças normais de uso da API. As cobranças adicionais são descritas emAWS IoT Corepreços - Mensagens.

MQTTWillmensagensque são publicados quando um dispositivo se desconecta inesperadamente incorrem em cobranças de mensagens descritas emAWS IoT Corepreços - Mensagens.

Para obter mais informações sobre custos de mensagens, consulteAWS 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 3.1.1 que permitem que os dispositivos recebam mensagens publicadas enquanto estavam off-line. Mensagens retidas podem ser publicadas a partir de sessões persistentes. Esta seção descreve os principais aspectos desses recursos e como eles funcionam em conjunto.

Mensagens retidas

Sessões persistentes

Mensagens retidas em sessões persistentes

Recursos principais

As mensagens retidas podem ser usadas para configurar ou notificar grandes grupos de dispositivos depois que eles se conectam.

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

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 estiverem off-line.

As mensagens retidas podem ser usadas em sessões regulares e persistentes.

Exemplos

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

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

O dispositivo celular na amostra de sessão persistente pode usar uma mensagem retida para receber sua configuração inicial em sua conexão inicial.

Mensagens recebidas na assinatura inicial de um tópico

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

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

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

Tópicos inscritos após a reconexão

Sem uma sessão persistente, o cliente deve se inscrever em tópicos após a reconexão.

Tópicos inscritos são restaurados após a reconexão.

Tópicos inscritos são restaurados após a reconexão.

Mensagens recebidas após a reconexão

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

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

Todas as mensagens publicadas com um QOS = 1 e inscritas com um QOS =1 que foram enviadas enquanto o dispositivo foi desconectado são enviadas após a reconexão do dispositivo.

Mensagens retidas atualizadas de tópicos nos quais o cliente foi inscrito também são enviadas ao cliente.

Se mais de uma mensagem retida tiver sido publicada em um tópico enquanto o cliente estava offline, ele poderá receber várias mensagens armazenadas retidas para esse tópico depois de reconectar.

Validade de dados/sessão

As mensagens retidas não expiram. Eles são armazenados até serem substituídos ou excluídos.

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 um QOS = 1 e inscritas com um QOS =1 enquanto o dispositivo foi desconectado são excluídas.

Para obter mais informações sobre expirações de sessão com sessões persistentes, consulteUsar sessões persistentes do MQTT.

As mensagens retidas não expiram. Eles são armazenados até serem substituídos ou excluídos, mesmo que sejam enviados de dentro de uma sessão persistente que expirou. Depois que uma sessão persistente expira, as assinaturas do cliente e as mensagens salvas que foram publicadas com um QOS = 1 e inscritas com um QOS =1 enquanto o dispositivo foi desconectado são excluídas.

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

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

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

MQTT manteve mensagens eAWS IoTSombras de dispositivos

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

Mensagens retidas

Sombras de dispositivos

A carga útil da mensagem tem uma estrutura ou esquema predefinidos

Conforme definido pela implementação. O MQTT não especifica uma estrutura ou esquema para a carga útil da mensagem.

AWS IoTsuporta uma estrutura de dados específica.

Atualizar a carga útil da mensagem gera mensagens de evento

Publicar uma mensagem retida envia a mensagem para clientes inscritos, mas não gera mensagens de atualização adicionais.

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

As atualizações de mensagens são numeradas

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

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

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

Sombras de dispositivos são anexadas a um recurso de coisa.

Atualizando elementos individuais da carga útil 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 de mensagens após a assinatura

O cliente recebe automaticamente uma mensagem retida depois de assinar um tópico com uma mensagem retida.

Os clientes podem se inscrever nas atualizações do Device Shadow, mas devem solicitar o estado atual deliberadamente.

Indexação e pesquisa

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

Índices de indexação de frota dados Device Shadow para pesquisa e agregação.

Usar ConnectAttribut

ConnectAttributespermite especificar quais atributos você deseja usar em sua mensagem de conexão em suas políticas do IAM, comoPersistentConnecteLastWill. comConnectAttributes, você pode criar políticas que não dão aos dispositivos acesso a novos recursos por padrão, o que pode ser útil se um dispositivo estiver comprometido.

O connectAttributes oferece suporte aos seguintes recursos:

PersistentConnect

Usar aPersistentConnectPara salvar todas as inscrições que o cliente faz durante a conexão quando a conexão entre o cliente e o agente é interrompido.

LastWill

Usar aLastWillPara publicar uma mensagem noLastWillTopicquando um cliente se desconecta inesperadamente.

Por padrão, sua política tem 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 oConnectAttributesExemplos, consulteExemplos de política de conexão.

AWS IoTDiferenças da especificação MQTT versão 3.1.1

A implementação do corretor de mensagens é baseada naEspecificação MQTT v3.1.1, mas ela difere da especificação das seguintes maneiras:

  • AWS IoTSuporta apenas os níveis 0 e 1 da MQTT da qualidade de serviço (QoS).AWS IoTnão suporta publicação ou assinatura com QoS nível 2. Quando o nível 2 da 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 aguardar que a mensagem CONNACK seja recebida em seu dispositivo a partir doAWS IoTAgente de 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 da para assinar um tópico, todas as strings de caracteres em e abaixo de seu nível na hierarquia de tópicos são correspondidas. No entanto, o tópico pai não corresponde. Por exemplo, uma assinatura do tópicosensor/#recebe mensagens publicadas nos tópicossensor/,sensor/temperature,sensor/temperature/room1, mas não mensagens publicadas parasensor. 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 mesma ID de cliente não podem ser conectados simultaneamente ao operador 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 assinatura 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.