Connessione con MQTT tramite il dispositivo AWS IoT SDKs Opzioni di qualità del servizio MQTT (QoS)Sessioni persistenti MQTT Messaggi conservati da MQTT Messaggi MQTT Last Will and Testament (LWT)Utilizzo degli Attributi Connect Caratteristiche supportate da MQTT 5 Proprietà MQTT 5 Codici motivo MQTT AWS IoT differenze rispetto alle specifiche MQTT Gestione delle connessioni MQTT

MQTT

MQTT (Message Queuing Telemetry Transport) è un protocollo di messaggistica leggero e ampiamente adottato, progettato per dispositivi vincolati. Il supporto AWS IoT Core per MQTT si basa sulla specifica MQTT v3.1.1 e la specifica MQTT v5.0, con alcune differenze come documentato in AWS IoT differenze rispetto alle specifiche MQTT. Essendo la versione più recente dello standard, MQTT 5 introduce diverse funzionalità chiave che rendono un sistema basato su MQTT più affidabile, inclusi nuovi miglioramenti della scalabilità, segnalazione degli errori migliorata con risposte codice motivo, timer di scadenza dei messaggi e delle sessioni e intestazioni messaggi utente personalizzate. Per ulteriori informazioni sulle funzionalità supportate da MQTT 5, consultate Funzionalità AWS IoT Core supportate da MQTT 5. AWS IoT Core supporta anche la comunicazione tra versioni MQTT (MQTT 3 e MQTT 5). Un autore MQTT 3 può inviare un messaggio MQTT 3 a un sottoscrittore MQTT 5 che riceverà un messaggio di pubblicazione MQTT 5, e viceversa.

AWS IoT Core supporta connessioni di dispositivi che utilizzano il protocollo MQTT e il protocollo MQTT over WSS e che sono identificate da un ID client. AWS IoT Device SDKs supportano entrambi i protocolli e sono i modi consigliati per connettere i dispositivi a AWS IoT Core. Il AWS IoT dispositivo SDKs supporta le funzioni necessarie ai dispositivi e ai client per connettersi e accedere ai servizi. AWS IoT Il dispositivo SDKs supporta i protocolli di autenticazione richiesti dai AWS IoT servizi e i requisiti di ID di connessione richiesti dal protocollo MQTT e dai protocolli MQTT su WSS. Per informazioni su come connettersi AWS IoT utilizzando il AWS dispositivo SDKs e collegamenti ad esempi delle lingue AWS IoT supportate, vedere. Connessione con MQTT tramite il dispositivo AWS IoT SDKs Per ulteriori informazioni sull’autenticazione e sulla mappatura delle porte per i messaggi MQTT, consulta Protocolli, mappature delle porte e autenticazione.

Sebbene consigliamo di utilizzare il AWS IoT Dispositivo SDKs a cui connettersi AWS IoT, non sono necessari. Se non si utilizza il AWS IoT Dispositivo SDKs, tuttavia, è necessario fornire la necessaria sicurezza di connessione e comunicazione. I client devono inoltre inviare la Estensione TLS di Server Name Indication per impedire che le connessioni vengano rifiutate. I tentativi di connessione che non includono l'SNI vengono rifiutati. Per ulteriori informazioni, vedere Transport Security in AWS IoT. I client che utilizzano utenti e AWS credenziali IAM per autenticare i client devono fornire l'autenticazione Signature Version 4 corretta.

Dopo aver connesso i client, puoi monitorare e gestire le loro connessioni client MQTT utilizzando. APIs Per ulteriori informazioni, consulta Gestione delle connessioni MQTT.

In questo argomento:

Connessione con MQTT tramite il dispositivo AWS IoT SDKs
Opzioni di qualità del servizio MQTT (QoS)
Sessioni persistenti MQTT
Messaggi conservati da MQTT
Messaggi MQTT Last Will and Testament (LWT)
Utilizzo degli Attributi Connect
Caratteristiche supportate da MQTT 5
Proprietà MQTT 5
Codici motivo MQTT
AWS IoT differenze rispetto alle specifiche MQTT
Gestione delle connessioni MQTT

Connessione con MQTT tramite il dispositivo AWS IoT SDKs

Questa sezione contiene collegamenti al AWS IoT dispositivo SDKs e al codice sorgente di programmi di esempio che illustrano come collegare un dispositivo a. AWS IoT Le app di esempio collegate qui mostrano come connettersi AWS IoT utilizzando il protocollo MQTT e MQTT tramite WSS.

Nota

The AWS IoT Device SDKs ha rilasciato un client MQTT 5.

Opzioni di qualità del servizio MQTT (QoS)

AWS IoT e il AWS IoT dispositivo SDKs supporta i livelli di qualità del servizio (QoS) 0 MQTT e. 1 Il protocollo MQTT definisce un terzo livello di QoS, 2 livello, AWS IoT ma non lo supporta. Solo il protocollo MQTT supporta la caratteristica QoS. HTTPS supporta QoS passando un parametro di stringa di query ?qos=qos dove il valore può essere 0 o 1.

Questa tabella descrive come ogni livello QoS influisce sui messaggi pubblicati da e per il broker messaggi.

Con un livello QoS di...	Il messaggio è...	Commenti
QoS livello 0	Inviato zero o più volte	Questo livello deve essere utilizzato per i messaggi inviati tramite collegamenti di comunicazione affidabili o che possono essere persi senza problemi.
Livello QoS 1	Inviato almeno una volta e poi ripetutamente fino a quando non si riceve una risposta `PUBACK`	Il messaggio non viene considerato completo fino a quando il mittente non riceve una risposta `PUBACK` per indicare la riuscita della consegna.

Sessioni persistenti MQTT

Le sessioni persistenti archiviano le sottoscrizioni e i messaggi di un client, con una qualità del servizio (QoS) pari a 1, che non sono stati riconosciuti dal client. Quando il dispositivo si riconnette a una sessione persistente, la sessione riprende, le relative sottoscrizioni vengono reintegrate e i messaggi sottoscritti non riconosciuti ricevuti e archiviati prima della riconnessione vengono inviati al client.

L'elaborazione dei messaggi archiviati viene registrata in CloudWatch metriche e registri. CloudWatch Per informazioni sulle voci scritte in CloudWatch and CloudWatch Logs, vedere e. Parametri del broker di messaggi Voce di log Queued

Creazione di una sessione persistente

In MQTT3, è possibile creare una sessione persistente MQTT inviando un messaggio CONNECT e impostando il flag cleanSession su 0. Se non esiste alcuna sessione per il client che invia il messaggio CONNECT, viene creata una nuova sessione persistente. Se esiste una sessione per il client, il client riprende la sessione esistente. Per creare una sessione pulita, è possibile inviare un messaggio CONNECT e impostare il flag cleanSession su 1. Il broker non memorizzerà alcuno stato della sessione quando il client si disconnette.

In MQTT 5, è possibile gestire le sessioni persistenti impostando il flag Clean Start e Session Expiry Interval. Avvio pulito controlla l'inizio della sessione di connessione e la fine della sessione precedente. Quando si imposta Clean Start = 1, viene creata una nuova sessione e una sessione precedente viene terminata, se esiste. Quando si imposta Clean Start= 0, la sessione di connessione riprende una sessione precedente, se esiste. L'intervallo di scadenza della sessione controlla la fine della sessione di connessione. L'intervallo di scadenza della sessione specifica il tempo, in secondi (numero intero a 4 byte), di persistenza di una sessione dopo la disconnessione. L'impostazione Session Expiry interval=0 causa la terminazione immediata della sessione dopo la disconnessione. Se l'intervallo di scadenza della sessione non è specificato nel messaggio CONNECT, il valore predefinito è 0.

Avvio pulito e scadenza della sessione MQTT 5
Valore proprietà	Descrizione
`Clean Start`= `1`	Crea una nuova sessione e termina una sessione precedente, se una esiste.
`Clean Start`= `0`	Ripristina una sessione, se esiste una sessione precedente.
`Session Expiry Interval`> `0`	Mantiene una sessione.
`Session Expiry interval`= `0`	Non mantiene una sessione.

In MQTT 5, se si imposta Clean Start = 1 e Session Expiry Interval = 0, questo è l'equivalente di una sessione pulita MQTT 3. Se si imposta Clean Start = 0 e Session Expiry Interval> 0, è l'equivalente di una sessione persistente MQTT 3.

Nota

Le sessioni persistenti tra versioni MQTT (MQTT 3 e MQTT 5) non sono supportate. Una sessione persistente MQTT 3 non può essere ripristinata come una sessione MQTT 5, e viceversa.

Operazioni durante una sessione persistente

I dispositivi utilizzano l'attributo sessionPresent nel messaggio CONNACK (Connection Acknowledged) per determinare l'eventuale presenza di una sessione persistente. Se sessionPresent è 1, è presente una sessione persistente e tutti i messaggi archiviati per il client vengono distribuiti al client dopo che il client riceve il CONNACK, come descritto in Traffico dei messaggi dopo la riconnessione a una sessione persistente. Se sessionPresent è impostato su 1, non è necessario che il client esegua di nuovo la sottoscrizione. Se sessionPresent è impostato su 0, non è presente alcuna sessione persistente e il client deve eseguire nuovamente la sottoscrizione nei filtri degli argomenti.

Dopo che il client si unisce ad una sessione persistente, può pubblicare messaggi e sottoscrivere filtri argomento senza ulteriori flag in ogni operazione.

Traffico dei messaggi dopo la riconnessione a una sessione persistente

Una sessione persistente rappresenta una connessione continua tra un cliente e un broker di messaggi MQTT. Quando un client si connette a un broker di messaggi utilizzando una sessione persistente, il broker di messaggi salva tutte le sottoscrizioni che il client effettua durante la connessione. Quando il client si disconnette, il broker di messaggi archivia i messaggi QoS 1 non riconosciuti e i nuovi messaggi QoS 1 pubblicati in argomenti di cui il client ha eseguito la sottoscrizione. I messaggi vengono archiviati in base al limite dell'account. I messaggi che superano il limite verranno eliminati. Per ulteriori informazioni sui limiti dei messaggi persistenti, consulta Endpoint e quote di AWS IoT Core. Quando il client si riconnette alla sessione persistente, tutte le sottoscrizioni vengono ripristinate e tutti i messaggi archiviati vengono inviati al client a una velocità massima di 10 messaggi al secondo. In MQTT 5, se un QoS 1 in uscita con Intervallo di scadenza dei messaggi scade quando un client è offline, dopo la ripresa della connessione, il client non riceverà il messaggio scaduto.

Dopo la riconnessione, i messaggi archiviati vengono inviati al client, a una velocità limitata di 10 messaggi archiviati al secondo, insieme a qualsiasi traffico di messaggi corrente fino a quando il limite di Publish requests per second per connection viene raggiunto. Poiché la velocità di distribuzione dei messaggi archiviati è limitata, ci vorranno alcuni secondi per distribuire tutti i messaggi archiviati se una sessione ha più di 10 messaggi archiviati da distribuire dopo la riconnessione.

Per gli abbonati condivisi, i messaggi verranno messi in coda se almeno un abbonato di un gruppo utilizza una sessione persistente e nessun abbonato è online per ricevere il messaggio QoS 1. La rimozione dalla coda dei messaggi viene effettuata a una velocità massima di 20 messaggi al secondo per abbonato attivo in un gruppo. Per ulteriori informazioni, consulta Accodamento dei messaggi relativi alle sottoscrizioni condivise.

Termine di una sessione persistente

Le sessioni persistenti possono terminare nei modi seguenti:

Il tempo di scadenza della sessione persistente è trascorso. Il timer di scadenza della sessione persistente inizia quando il broker messaggi rileva che un client si è disconnesso, tramite la disconnessione del client o il timeout della connessione.
Il client invia un messaggio CONNECT che imposta il flag cleanSession su 1.
Si disconnette manualmente il client e si cancella la sessione utilizzando DeleteConnection l'API. Per ulteriori informazioni, consulta Gestione delle connessioni MQTT.

In MQTT 3, il valore predefinito del tempo di scadenza delle sessioni persistenti è un'ora e si applica a tutte le sessioni nell'account.

In MQTT 5, è possibile impostare Intervallo di scadenza della sessione per ogni sessione sui pacchetti CONNECT e DISCONNECT.

Per intervallo di scadenza della sessione sul pacchetto DISCONNECT:

Se l'intervallo di scadenza della sessione corrente è impostato su 0, non è possibile impostare un intervallo di scadenza della sessione su un valore maggiore di 0 sul pacchetto DISCONNECT.
Se l'intervallo di scadenza della sessione corrente è maggiore di 0 e si imposta l'intervallo di scadenza della sessione su 0 nel pacchetto DISCONNECT, la sessione verrà terminata su DISCONNECT.
In caso contrario, l'Intervallo di scadenza della sessione sul pacchetto DISCONNECT aggiornerà l'Intervallo di scadenza della sessione corrente.

Nota

I messaggi archiviati in attesa di essere inviati al client al termine di una sessione vengono eliminati; tuttavia, vengono comunque fatturati alla tariffa standard di messaggistica, anche se non è stato possibile inviarli. Per ulteriori informazioni sui prezzi delle prenotazioni, consulta Prezzi di AWS IoT Core. È possibile configurare l'intervallo del tempo di scadenza.

Riconnessione dopo la scadenza di una sessione persistente

Se un client non si riconnette alla sessione persistente prima della scadenza, la sessione termina e i messaggi archiviati vengono eliminati. Quando un client si riconnette dopo la scadenza della sessione e imposta il flag cleanSession su 0, il servizio crea una nuova sessione persistente. Gli abbonamenti o i messaggi della sessione precedente non sono disponibili per questa sessione perché sono stati scartati alla scadenza della sessione precedente.

Addebito dei messaggi di sessione persistente

I messaggi vengono addebitati all'utente Account AWS quando il broker di messaggi invia un messaggio a un cliente o a una sessione persistente offline. Quando un dispositivo offline con una sessione persistente si riconnette e riprende la sessione, i messaggi archiviati vengono recapitati al dispositivo e vengono nuovamente addebitati sul tuo account. Per ulteriori informazioni sui prezzi dei messaggi, consulta AWS IoT Core pricing - Messagging (Prezzi di Amazon IoT Core - Messaggistica).

Si può aumentare il tempo di scadenza predefinito di un’ora della sessione persistente utilizzando il processo di aumento del limite standard. Si noti che l'aumento del tempo di scadenza della sessione potrebbe aumentare gli addebiti dei messaggi. Infatti, il tempo aggiuntivo potrebbe consentire l'archiviazione di più messaggi per il dispositivo offline e tali messaggi aggiuntivi verranno addebitati all'account alla tariffa di messaggistica standard. Il tempo di scadenza della sessione è approssimativo e una sessione potrebbe persistere fino a 30 minuti più a lungo rispetto al limite dell'account; tuttavia, una sessione non può essere inferiore al limite dell'account. Per ulteriori informazioni sui limiti di sessione, consulta Service Quotas di AWS.

Messaggi conservati da MQTT

AWS IoT Core supporta il RETAIN flag descritto nel protocollo MQTT. Quando un client imposta il RETAIN flag su un messaggio MQTT che pubblica, AWS IoT Core salva il messaggio. Può quindi essere inviato a nuovi sottoscrittori, recuperato chiamando l'operazione GetRetainedMessage e visualizzato nella console AWS IoT.

Esempi di utilizzo di messaggi conservati da MQTT

Come messaggio di configurazione iniziale

I messaggi conservati MQTT vengono inviati a un client dopo che il client si è sottoscritto a un argomento. Se desiderate che tutti i client che sottoscrivono un argomento ricevano il messaggio MQTT conservato subito dopo la sottoscrizione, potete pubblicare un messaggio di configurazione con il flag impostato. RETAIN I client sottoscrittori ricevono anche aggiornamenti di tale configurazione ogni volta che viene pubblicato un nuovo messaggio di configurazione.
Come ultimo messaggio di stato noto

I dispositivi possono impostare il RETAIN flag sui messaggi con lo stato attuale in modo da salvarli. AWS IoT Core Quando le applicazioni si connettono o si riconnettono, possono iscriversi a questo argomento e visualizzare l'ultimo stato segnalato subito dopo la sottoscrizione all'argomento del messaggio memorizzato. In questo modo possono evitare di dover attendere il prossimo messaggio dal dispositivo per vedere lo stato corrente.

In questa sezione:

Attività comuni con MQTT ha conservato i messaggi in AWS IoT Core
Messaggi di fatturazione e conservati
Confronto tra i messaggi conservati MQTT e le sessioni persistenti MQTT
MQTT ha mantenuto i messaggi e i Device Shadows AWS IoT

Attività comuni con MQTT ha conservato i messaggi in AWS IoT Core

AWS IoT Core salva i messaggi MQTT con il flag impostato. RETAIN Questi messaggi conservati vengono inviati a tutti i client che hanno sottoscritto l'argomento, come un normale messaggio MQTT, e vengono archiviati anche per essere inviati ai nuovi sottoscrittori all'argomento.

I messaggi conservati MQTT richiedono azioni di policy specifiche per autorizzare i client ad accedervi. Per esempi di utilizzo di policy dei messaggi conservati, consulta Esempi di policy per i messaggi conservati.

Questa sezione descrive le operazioni comuni che comportano messaggi conservati.

Creazione di un messaggio conservato

Il client determina se un messaggio viene conservato quando pubblica un messaggio MQTT. I client possono impostare il RETAIN flag quando pubblicano un messaggio utilizzando un Device SDK. Le applicazioni e i servizi possono impostare il RETAIN flag quando utilizzano l'Publishazione per pubblicare un messaggio MQTT.

Viene conservato un solo messaggio per nome argomento. Un nuovo messaggio con il flag RETAIN impostato pubblicato su un argomento sostituisce qualsiasi messaggio conservato esistente inviato all'argomento in precedenza.

Nota
Non è possibile pubblicare su un argomento riservato con il RETAIN flag impostato.
Iscrizione di un argomento del messaggio conservato

I clienti si iscrivono agli argomenti dei messaggi conservati come qualsiasi altro argomento del messaggio MQTT. Il contrassegno è impostato per i messaggi conservati ricevuti mediante sottoscrizione a un argomento riservatoRETAIN.

I messaggi conservati vengono eliminati AWS IoT Core quando un client pubblica un messaggio conservato con un payload di messaggi da 0 byte nell'argomento del messaggio conservato. I client che hanno sottoscritto l'argomento del messaggio conservato riceveranno anche il messaggio da 0 byte.

La sottoscrizione a un filtro argomento jolly che include un argomento del messaggio conservato consente al client di ricevere messaggi successivi pubblicati sull'argomento del messaggio conservato, ma non recapita il messaggio conservato al momento della sottoscrizione.

Nota
Per ricevere un messaggio conservato al momento della sottoscrizione, il filtro degli argomenti nella richiesta di iscrizione deve corrispondere esattamente all'argomento del messaggio salvato.

Per i messaggi conservati ricevuti al momento della sottoscrizione a un argomento del messaggio mantenuto è impostato il flag. RETAIN I messaggi conservati ricevuti da un cliente abbonato dopo l'abbonamento non lo hanno.
Recupero di un messaggio conservato

I messaggi conservati vengono recapitati automaticamente ai client quando si sottoscrivono all'argomento con il messaggio conservato. Affinché un cliente riceva il messaggio conservato al momento dell'abbonamento, deve sottoscrivere il nome esatto dell'argomento del messaggio conservato. La sottoscrizione a un filtro argomento jolly che include un argomento del messaggio conservato consente al client di ricevere messaggi successivi pubblicati sull'argomento del messaggio conservato, ma non recapita il messaggio conservato al momento della sottoscrizione.

I servizi e le app possono elencare e recuperare i messaggi conservati chiamando ListRetainedMessages e GetRetainedMessage.

A un client non viene impedito di pubblicare messaggi su un argomento del messaggio mantenuto senza impostare il contrassegno. RETAIN Ciò potrebbe causare risultati imprevisti, ad esempio il messaggio conservato che non corrisponde al messaggio ricevuto sottoscrivendo l'argomento.

Con MQTT 5, se in un messaggio conservato l'intervallo di scadenza del messaggio è impostato e il messaggio conservato scade, un nuovo sottoscrittore che effettua la sottoscrizione a quell'argomento non riceverà il messaggio conservato al termine della sottoscrizione.
Elenco di argomenti di messaggio conservati

È possibile elencare i messaggi conservati chiamando ListRetainedMessages e i messaggi conservati possono essere visualizzati nella console AWS IoT.
Ricevere i dettagli del messaggio conservati

È possibile ottenere i dettagli del messaggio conservati chiamando GetRetainedMessage e possono essere visualizzati nella console AWS IoT.
Conservazione di un messaggio Will

I messaggi Will MQTT che vengono creati quando un dispositivo si connette può essere conservato impostando flag Will Retain nel campo Connect Flag bits.
Eliminazione di un messaggio conservato

I dispositivi, le applicazioni e i servizi possono eliminare un messaggio conservato pubblicando un messaggio con il RETAIN flag impostato e un payload di messaggi vuoto (0 byte) sul nome dell'argomento del messaggio salvato da eliminare. Tali messaggi eliminano il messaggio conservato AWS IoT Core, vengono inviati ai client abbonati all'argomento, ma non vengono conservati da. AWS IoT Core

I messaggi conservati possono anche essere eliminati in modo interattivo accedendo al messaggio conservato nella console AWS IoT. Messaggi conservati che vengono eliminati utilizzando la console AWS IoTinviano anche un messaggio a 0 byte ai client che hanno sottoscritto l'argomento del messaggio conservato.

I messaggi conservati non possono essere ripristinati dopo che sono stati eliminati. Un client dovrebbe pubblicare un nuovo messaggio conservato per sostituire il messaggio eliminato.
Debugging e risoluzione dei problemi dei messaggi conservati

La console AWS IoT fornisce diversi strumenti per aiutarti a risolvere i problemi dei messaggi conservati:
- La pagina Messaggi conservati
  
  La pagina Messaggi conservati nella console AWS IoT fornisce un elenco impaginato dei messaggi conservati che sono stati memorizzati dal tuo Account nella regione corrente. In questa pagina, è possibile:
  - Visualizzare i dettagli di ogni messaggio conservato, ad esempio il payload del messaggio, il QoS, l'ora in cui è stato ricevuto.
  - Aggiornare il contenuto di un messaggio conservato.
  - Eliminare un messaggio conservato.
- Il client di test MQTT
  
  La pagina Client di test MQTT nella console AWS IoT può iscriversi e pubblicare argomenti MQTT. L'opzione di pubblicazione consente di impostare il flag RETAIN sui messaggi pubblicati per simulare il comportamento dei dispositivi. È inoltre possibile utilizzare il client di test MQTT per monitorare i messaggi provenienti dai client connessi gestiti tramite l'interfaccia delle connessioni client. Per ulteriori informazioni sulla gestione delle connessioni client, vedereGestione delle connessioni MQTT.
Alcuni risultati imprevisti potrebbero essere il risultato di questi aspetti del modo in cui vengono implementati i messaggi conservati in AWS IoT Core.
- Limiti di messaggi conservati
  
  Quando un account ha archiviato il numero massimo di messaggi conservati, AWS IoT Core restituisce una risposta limitata ai messaggi pubblicati con il set RETAIN e carica un payload superiore a 0 byte fino a quando alcuni messaggi conservati non vengono eliminati e il numero di messaggi conservati non scende al di sotto del limite.
- Ordine di consegna dei messaggi conservati
  
  La sequenza di messaggi conservati e di recapito del messaggio sottoscritto non è garantita.

Messaggi di fatturazione e conservati

La pubblicazione di messaggi con il RETAIN flag impostato da un client, utilizzando la AWS IoT console o chiamando Publishcomporta costi di messaggistica aggiuntivi descritti in Pricing - Messaging.AWS IoT Core

Il recupero dei messaggi conservati da un client, utilizzando la AWS IoT console o tramite chiamata GetRetainedMessagecomporta costi di messaggistica oltre ai normali costi di utilizzo dell'API. I costi aggiuntivi sono descritti nella sezione Prezzi di AWS IoT Core - Messaggistica.

I messaggi Will MQTT che vengono pubblicati quando un dispositivo si disconnette inaspettatamente comportano i costi di messaggistica descritti in Prezzi di AWS IoT Core - Messaggistica.

Per ulteriori informazioni sui prezzi dei messaggi, consulta la sezione Prezzi di AWS IoT Core - Messaggistica.

Confronto tra i messaggi conservati MQTT e le sessioni persistenti MQTT

I messaggi conservati e le sessioni persistenti sono caratteristiche standard di MQTT che consentono ai dispositivi di ricevere messaggi pubblicati mentre erano offline. I messaggi conservati possono essere pubblicati da sessioni persistenti. In questa sezione vengono descritti gli aspetti chiave di queste caratteristiche e come funzionano insieme.

	Messaggi conservati	Sessioni persistenti
Caratteristiche principali	I messaggi conservati possono essere utilizzati per configurare o notificare grandi gruppi di dispositivi dopo la connessione. I messaggi conservati possono essere utilizzati anche quando si desidera che i dispositivi ricevano solo l'ultimo messaggio pubblicato su un argomento dopo una riconnessione.	Le sessioni persistenti sono utili per i dispositivi con connettività intermittente e potrebbero mancare diversi messaggi importanti. I dispositivi possono connettersi a una sessione persistente per ricevere messaggi inviati mentre sono offline.
Examples (Esempi)	I messaggi conservati possono fornire informazioni sulla configurazione dei dispositivi sul loro ambiente quando vengono online. La configurazione iniziale potrebbe includere un elenco di altri argomenti di messaggio a cui deve sottoscrivere o informazioni su come configurare il fuso orario locale.	I dispositivi che si connettono su una rete cellulare con connettività intermittente potrebbero utilizzare sessioni persistenti per evitare di perdere messaggi importanti inviati mentre un dispositivo è fuori copertura di rete o deve spegnere la radio cellulare.
Messaggi ricevuti durante la sottoscrizione iniziale a un argomento	Dopo aver sottoscritto un argomento con un messaggio conservato, viene ricevuto il messaggio conservato più recente.	Dopo aver effettuato la sottoscrizione a un argomento senza un messaggio conservato, non viene ricevuto alcun messaggio finché non viene pubblicato sull'argomento.
Argomenti iscritti dopo la riconnessione	Senza una sessione persistente, il client deve iscriversi agli argomenti dopo la riconnessione.	Gli argomenti sottoscritti vengono ripristinati dopo la riconnessione.
Messaggi ricevuti dopo la riconnessione	Dopo aver sottoscritto un argomento con un messaggio conservato, viene ricevuto il messaggio conservato più recente.	Tutti i messaggi pubblicati con QOS = 1 e sottoscritti con un QOS =1 mentre il dispositivo è stato disconnesso vengono inviati dopo la riconnessione del dispositivo.
Scadenza della sessione/dati	In MQTT 3, i messaggi conservati non scadono. Sono archiviati fino a quando non vengono sostituiti o eliminati. In MQTT 5, i messaggi conservati scadono dopo l'intervallo di scadenza dei messaggi impostato. Per ulteriori informazioni, consulta Scadenza dei messaggi.	Le sessioni persistenti scadono se il client non si riconnette entro il periodo di timeout. Dopo la scadenza di una sessione persistente, vengono eliminati gli abbonamenti e i messaggi salvati del client pubblicati con un QOS = 1 e sottoscritti con un QOS =1 mentre il dispositivo è stato disconnesso. I messaggi scaduti non verranno distribuiti. Per ulteriori informazioni sulle scadenze di sessione con sessioni persistenti, consulta Sessioni persistenti MQTT.

Per informazioni sulle sessioni persistenti, consulta Sessioni persistenti MQTT.

Con i messaggi mantenuti, il client di pubblicazione determina se un messaggio deve essere conservato e recapitato a un dispositivo dopo la connessione, indipendentemente dal fatto che abbia avuto una sessione precedente o meno. La scelta di archiviare un messaggio viene effettuata dall'editore e il messaggio archiviato viene recapitato a tutti i client attuali e futuri che sottoscrivono abbonamenti QoS 0 o QoS 1. I messaggi conservati conservano un solo messaggio su un determinato argomento alla volta.

Quando un account ha archiviato il numero massimo di messaggi conservati, AWS IoT Core restituisce una risposta limitata ai messaggi pubblicati con impostazione RETAIN e payload superiori a 0 byte fino a quando alcuni messaggi conservati non vengono eliminati e il conteggio dei messaggi conservati scende al di sotto del limite.

MQTT ha mantenuto i messaggi e i Device Shadows AWS IoT

I messaggi conservati e i Device Shadow conservano entrambi i dati da un dispositivo, ma si comportano in modo diverso e hanno scopi diversi. In questa sezione vengono descritti somiglianze e differenze.

	Messaggi conservati	Dispositivi ombra
Il payload del messaggio ha una struttura o uno schema predefinito	Come definito dall'implementazione. MQTT non specifica una struttura o uno schema per il payload dei messaggi.	AWS IoT supporta una struttura di dati specifica.
L'aggiornamento del payload del messaggio genera messaggi di evento	La pubblicazione di un messaggio conservato invia il messaggio ai client sottoscritti, ma non genera ulteriori messaggi di aggiornamento.	L'aggiornamento di un Device Shadow produce messaggi di aggiornamento che descrivono la modifica.
Gli aggiornamenti dei messaggi sono numerati	I messaggi conservati non vengono numerati automaticamente.	I documenti Device Shadow hanno numeri di versione e timestamp automatici.
Il payload dei messaggi è collegato a una risorsa oggetto	I messaggi conservati non sono allegati a una risorsa oggetto.	I Device Shadow Device Shadow sono collegati a una risorsa oggetto.
Aggiornamento di singoli elementi del payload del messaggio	I singoli elementi del messaggio non possono essere modificati senza aggiornare l'intero payload del messaggio.	I singoli elementi di un documento Device Shadow possono essere aggiornati senza dover aggiornare l'intero documento Device Shadow.
Il client riceve i dati dei messaggi al momento dell'sottoscrizione	Il client riceve automaticamente un messaggio conservato dopo aver sottoscritto un argomento con un messaggio conservato.	I client possono iscriversi agli aggiornamenti Device Shadow, ma devono richiedere deliberatamente lo stato corrente.
Indicizzazione e ricercabilità	I messaggi conservati non sono indicizzati per la ricerca.	L'indicizzazione del parco istanze indicizza i dati di Device Shadow per la ricerca e l'aggregazione.

Messaggi MQTT Last Will and Testament (LWT)

Last Will and Testament (LWT) è una funzionalità di MQTT. Con LWT, i clienti possono specificare un messaggio che il broker pubblicherà su un argomento definito dal client e invierà a tutti i client che hanno sottoscritto l'argomento quando si verifica una disconnessione non iniziata. Il messaggio specificato dai client è chiamato messaggio LWT o messaggio Will e l'argomento definito dai client viene definito argomento Will. Puoi specificare un messaggio LWT quando un dispositivo si connette al broker. Questi messaggi possono essere conservati impostando il flag Will Retain nel campo Connect Flag bits durante la connessione. Ad esempio, se il flag Will Retain è impostato su 1, un messaggio Will verrà archiviato nel broker nell’argomento Will associato. Per ulteriori informazioni, consulta Messaggi Will.

Quando gestisci le connessioni client, puoi controllare se i messaggi LWT vengono pubblicati quando disconnetti un client. Per ulteriori informazioni, consulta Gestione delle connessioni MQTT.

Il broker memorizzerà i messaggi Will fino a quando non si verificherà una disconnessione non avviata. Quando ciò accade, il broker pubblicherà i messaggi a tutti i clienti che si sono iscritti all’argomento Will per notificare la disconnessione. Se il client si disconnette dal broker con una disconnessione avviata dal client utilizzando il messaggio MQTT DISCONNECT, il broker non pubblicherà i messaggi LWT memorizzati. In tutti gli altri casi, i messaggi LWT verranno inviati. Per un elenco completo degli scenari di disconnessione in cui il broker invierà i messaggi LWT, vediEventi di connessione/disconnessione.

Utilizzo degli Attributi Connect

ConnectAttributes consentono di specificare quali attributi si desidera utilizzare nel messaggio di connessione delle policy IAM, ad esempio PersistentConnect e LastWill. Con ConnectAttributes, puoi creare criteri che non consentono ai dispositivi di accedere alle nuove funzionalità per impostazione predefinita, cosa che può essere utile in caso di compromissione di un dispositivo.

connectAttributes supporta le caratteristiche seguenti:

PersistentConnect: Utilizzo del PersistentConnect per salvare tutte le sottoscrizioni che il client effettua durante la connessione quando essa viene interrotta tra il client e il broker.
LastWill: Utilizzo del LastWill per pubblicare un messaggio nel LastWillTopic quando un client si disconnette in modo imprevisto.

Per impostazione predefinita, la policy dispone di una connessione non persistente e non esistono attributi passati per questa connessione. È necessario specificare una connessione permanente nella policy IAM se si desidera averne una.

Quando si gestiscono le connessioni client, è possibile visualizzare gli attributi di connessione e la configurazione della sessione per i client connessi. Per ulteriori informazioni, consulta Gestione delle connessioni MQTT.

Per esempi di ConnectAttributes, consulta Esempi di policy di connessione.

Caratteristiche supportate da MQTT 5

AWS IoT Core il supporto per MQTT 5 si basa sulla specifica MQTT v5.0 con alcune differenze, come documentato in. AWS IoT differenze rispetto alle specifiche MQTT

AWS IoT Core supporta le seguenti funzionalità MQTT 5:

Abbonamenti condivisi
Avvio pulito e scadenza della sessione
Codice motivo su tutti ACKs
Alias degli argomenti
Scadenza del messaggio
Altre caratteristiche MQTT 5

Abbonamenti condivisi

AWS IoT Core supporta sottoscrizioni condivise sia per MQTT 3.1.1 che per MQTT 5. Gli abbonamenti condivisi consentono a più client di condividere un abbonamento a un argomento e solo un client riceverà i messaggi pubblicati su quell'argomento utilizzando una distribuzione casuale. Le sottoscrizioni condivise possono bilanciare efficacemente il carico dei messaggi MQTT tra più abbonati. Ad esempio, si supponga di avere 1.000 dispositivi che pubblicano sullo stesso argomento e 10 applicazioni di back-end che elaborano tali messaggi. In tal caso, le applicazioni di backend possono sottoscrivere lo stesso argomento e ognuna riceverà in modo casuale i messaggi pubblicati dai dispositivi sull'argomento condiviso. Questo consente effettivamente di "condividere" il carico di tali messaggi. Le sottoscrizioni condivise consentono inoltre una migliore resilienza. Quando un'applicazione di back-end si disconnette, il broker distribuisce il carico agli abbonati rimanenti nel gruppo. Quando tutti gli abbonati si disconnettono, i messaggi vengono messi in coda.

Le funzionalità di accodamento dei messaggi sono disponibili per gli abbonamenti condivisi su entrambe le connessioni MQTT 3.1.1 e MQTT 5 per migliorare l'affidabilità della consegna dei messaggi.

Per utilizzare gli abbonamenti condivisi, i clienti sottoscrivono il filtro degli argomenti di un abbonamento condiviso nel modo seguente:


$share/{ShareName}/{TopicFilter}

$share è una stringa letterale per indicare il filtro di argomenti di una Sottoscrizione condivisa, che deve iniziare con $share.
{ShareName} è una stringa di caratteri per specificare il nome condiviso utilizzato da un gruppo di abbonati. Il filtro per argomenti di un abbonamento condiviso deve contenere un ShareName ed essere seguito dal / carattere. Il {ShareName} non deve includere i seguenti caratteri: /, + o#. La dimensione massima per {ShareName} è di 128 caratteri UTF-8.
{TopicFilter}segue la stessa sintassi del filtro degli argomenti di un abbonamento non condiviso. La dimensione massima per {TopicFilter} è di 256 caratteri UTF-8.
Le due barre obbligatorie (/) per $share/{ShareName}/{TopicFilter} non sono incluse nel limite Numero massimo di barre negli argomenti e nel filtro argomenti.

Le sottoscrizioni uguali {ShareName}/{TopicFilter} appartengono allo stesso gruppo di sottoscrizioni condiviso. Puoi creare più gruppi di abbonamenti condivisi e non superare il limite di sottoscrizioni condivise per gruppo. Per ulteriori informazioni, consulta Endpoint e quote di AWS IoT Core nella Documentazione generale di riferimento di AWS .

Le tabelle seguenti confrontano le sottoscrizioni non condivise e le sottoscrizioni condivise:

Subscription	Descrizione	Esempi di filtro di argomenti
Sottoscrizioni non condivise	Ogni client crea una sottoscrizione separata per ricevere i messaggi pubblicati. Quando un messaggio viene pubblicato su un argomento, tutti gli abbonati a tale argomento ricevono una copia del messaggio.	`sports/tennis sports/#`
Sottoscrizioni condivise	Più client possono condividere una sottoscrizione a un argomento e solo un client riceverà i messaggi pubblicati su tale argomento utilizzando una distribuzione casuale.	`$share/consumer/sports/tennis $share/consumer/sports/#`

Flusso di sottoscrizioni non condivise	Flusso di sottoscrizioni condivise

Note importanti per l'utilizzo degli abbonamenti condivisi

Se il gruppo di sottoscrittori condiviso è composto da sottoscrittori di sessione persistenti, quando tutti gli abbonati del gruppo condiviso sono disconnessi o se alcuni sottoscrittori violano il limite di richieste di pubblicazione al secondo per connessione, tutti i messaggi QoS 1 non riconosciuti e i messaggi QoS 1 non consegnati pubblicati su un gruppo di sottoscrizioni condiviso verranno messi in coda. Per ulteriori informazioni, consulta Accodamento dei messaggi relativi alle sottoscrizioni condivise.
I messaggi QoS 0 pubblicati su un gruppo di sottoscrizioni condiviso verranno eliminati in caso di errore.
Le sottoscrizioni condivise non ricevono messaggi conservati quando si sottoscrivono modelli di argomenti come parte di un gruppo di abbonati condiviso. I messaggi pubblicati su argomenti con sottoscrittori condivisi e con il RETAIN flag impostato vengono recapitati agli abbonati condivisi come qualsiasi altro messaggio di pubblicazione.
Quando le sottoscrizioni condivise contengono caratteri jolly (# o +), potrebbero esserci più sottoscrizioni condivise corrispondenti a un argomento. In tal caso, il broker di messaggi copia il messaggio di pubblicazione e lo invia a un client casuale in ogni abbonamento condiviso corrispondente. Il comportamento jolly degli abbonamenti condivisi può essere spiegato nel diagramma seguente.

In questo esempio, ci sono tre sottoscrizioni condivise corrispondenti all'argomento MQTT di pubblicazione. sports/tennis Il broker di messaggi copia il messaggio pubblicato e lo invia a un client casuale in ciascun gruppo corrispondente.

Client 1 e client 2 condividono la sottoscrizione: $share/consumer1/sports/tennis

Client 3 e client 4 condividono la sottoscrizione: $share/consumer1/sports/#

Client 5 e client 6 condividono la sottoscrizione: $share/consumer2/sports/tennis

Per ulteriori informazioni sui limiti delle sottoscrizioni condivise, consulta AWS IoT Core endpoint e quote nel General Reference.AWS Per testare gli abbonamenti condivisi utilizzando il client AWS IoT MQTT nella console, vedere.AWS IoT Test delle sottoscrizioni condivise nel client MQTT È inoltre possibile visualizzare a quali argomenti sono abbonati i client connessi, incluse le sottoscrizioni condivise, utilizzando le funzionalità di gestione della connessione client. Per ulteriori informazioni, consulta Gestione delle connessioni MQTT. Per ulteriori informazioni sugli abbonamenti condivisi, vedere Sottoscrizioni condivise della specifica 2.0. MQTTv5

Abbonamenti condivisi, accodamento dei messaggi

Per migliorare l'affidabilità della consegna dei messaggi, gli abbonamenti condivisi includono funzionalità di accodamento dei messaggi che archiviano i messaggi quando non sono disponibili abbonati online. Quando un gruppo di sottoscrizioni condiviso contiene almeno un membro con una sessione persistente, la funzionalità di accodamento è abilitata per il gruppo. Quando si distribuiscono messaggi, i membri online vengono selezionati come destinatari. I messaggi QoS 1 vengono messi in coda quando nessun membro viene trovato online o quando gli abbonati superano il limite. Publish requests per second per connection I messaggi in coda vengono recapitati quando i membri esistenti riprendono le sessioni permanenti o nuovi membri si uniscono al gruppo. I messaggi in coda vengono recapitati fino a 20 messaggi in coda al secondo per abbonato attivo del gruppo, insieme a tutti gli altri messaggi recapitati all'abbonato in base agli abbonamenti.

Per impostazione predefinita, la conservazione dei messaggi in coda segue la quota. Persistent Session expiry period Tuttavia, se nel messaggio di pubblicazione in entrata è impostato un MEI (Message Expiry Interval), il MEI ha la precedenza. Quando è presente, il MEI determina il periodo di conservazione dei messaggi, indipendentemente dal periodo di scadenza della sessione persistente.

Le velocità di coda dei messaggi sono limitate in base alla Queued messages per second per accountquota e il numero di messaggi è limitato dalla quota. Maximum number of queued messages per shared subscription group

Quando questi limiti vengono superati, vengono conservati solo i messaggi che erano già in coda prima di raggiungere il limite. I nuovi messaggi in arrivo che supererebbero i limiti vengono eliminati. Il sistema non sostituisce i vecchi messaggi in coda con quelli più recenti.

L'accodamento dei messaggi viene registrato in metriche e registri. CloudWatch CloudWatch Per informazioni sulle voci scritte in CloudWatch and CloudWatch Logs, vedere e. Parametri del broker di messaggi Voce di log Queued I messaggi in coda vengono comunque fatturati alla tariffa di messaggistica standard. Per ulteriori informazioni sui prezzi delle prenotazioni, consulta Prezzi di AWS IoT Core.

Ciclo di vita della sessione in un gruppo di sottoscrizioni condiviso

Quando una sessione pulita si iscrive a un gruppo, diventa un membro online del gruppo. Quando annulla l'iscrizione o si disconnette, la sessione pulita abbandona il gruppo.

Quando una sessione persistente si iscrive a un gruppo, diventa un membro online del gruppo. Quando si disconnette, rimane comunque nel gruppo, ma ne diventa un membro offline. Quando si riconnette, diventa nuovamente un membro online. La sessione persistente lascia il gruppo quando annulla esplicitamente l'iscrizione o quando scade dopo la disconnessione.

Avvio pulito e scadenza della sessione

È possibile utilizzare Avvio pulito e Scadenza della sessione per gestire le sessioni persistenti con maggiore flessibilità. Un flag Avvio pulito indica se la sessione deve iniziare senza utilizzare una sessione esistente. Un intervallo di scadenza della sessione indica per quanto tempo mantenere la sessione dopo una disconnessione. L'intervallo di scadenza della sessione può essere modificato al momento della disconnessione. Per ulteriori informazioni, consulta Sessioni persistenti MQTT.

Codice motivo su tutti ACKs

È possibile eseguire il debug o elaborare i messaggi di errore più facilmente utilizzando i codici motivo. I codici motivo vengono restituiti dal broker di messaggi in base al tipo di interazione con il broker (sottoscrizione, pubblicazione, conferma). Per ulteriori informazioni, consulta Codici motivo MQTT. Per un elenco completo dei codici motivo MQTT, consulta Specifiche MQTT v5.

Alias degli argomenti

È possibile sostituire un nome argomento con un alias argomento, che è un numero intero a due byte. L'utilizzo degli alias degli argomenti può ottimizzare la trasmissione dei nomi degli argomenti per ridurre potenzialmente i costi dei dati sui servizi di dati misurati. AWS IoT Core ha un limite predefinito di 8 alias tematici. Per ulteriori informazioni, consulta Endpoint e quote di AWS IoT Core nella Documentazione generale di riferimento di AWS .

Scadenza del messaggio

È possibile aggiungere valori di scadenza del messaggio ai messaggi pubblicati. Questi valori rappresentano l'intervallo di scadenza dei messaggi (MEI) in secondi. Se i messaggi non sono stati inviati ai sottoscrittori entro tale intervallo, il messaggio scadrà e verrà rimosso. Se non si imposta il valore di scadenza del messaggio, il messaggio non scadrà.

In uscita, il sottoscrittore riceverà un messaggio con il tempo rimanente nell'intervallo di scadenza. Ad esempio, se per un messaggio di pubblicazione in entrata è impostata una scadenza del messaggio di 30 secondi e il messaggio viene instradato al sottoscrittore dopo 20 secondi, il campo di scadenza del messaggio verrà aggiornato a 10. È possibile che il messaggio ricevuto dal sottoscrittore abbia un MEI aggiornato pari a 0. Questo perché non appena il tempo rimanente è pari o inferiore a 999 ms, verrà aggiornato a 0.

In AWS IoT Core, il MEI minimo è 1. Se l'intervallo è impostato su 0 dal lato client, verrà modificato su 1. L'intervallo massimo di scadenza del messaggio è 604800 (7 giorni). Qualsiasi valore superiore a questo verrà modificato nel valore massimo.

Nella comunicazione tra versioni, il comportamento della scadenza del messaggio viene deciso dalla versione MQTT del messaggio di pubblicazione in entrata. Ad esempio, un messaggio con scadenza inviato da una sessione connessa tramite MQTT5 può scadere per i dispositivi abbonati alle sessioni. MQTT3 Nella tabella seguente viene elencato in che modo la scadenza del messaggio supporta i seguenti tipi di messaggi di pubblicazione:

Tipo di messaggio di pubblicazione	Message Expiry Interval
Pubblicazione regolare	Se un server non riesce a recapitare il messaggio entro il tempo specificato, il messaggio scaduto verrà rimosso e non verrà ricevuto dal sottoscrittore. Ciò include situazioni come quando un dispositivo non effettua il back-up dei messaggi QoS 1.
Mantenimento	Se un messaggio conservato scade e un nuovo client effettua la sottoscrizione all'argomento, il client non riceverà il messaggio al momento della sottoscrizione.
Conclusivo	L'intervallo per i messaggi conclusivi inizia dopo che il client si disconnette e il server tenta di distribuire il messaggio conclusivo ai suoi sottoscrittori.
Messaggi in coda	Se un QoS 1 in uscita con intervallo di scadenza dei messaggi scade quando un client è offline, dopo la ripresa della sessione persistente, il client non riceverà il messaggio scaduto.

Altre caratteristiche MQTT 5

Disconnessione server

Quando si verifica una disconnessione, il server può inviare in modo proattivo al client un messaggio DISCONNECT per segnalare la chiusura della connessione con un codice motivo della disconnessione.

Richiesta/Risposta

Gli autori possono richiedere che il destinatario invii una risposta a un argomento specificato dall'autore al momento della ricezione.

Dimensione massima del pacchetto

Client e server possono specificare in modo indipendente la dimensione massima dei pacchetti supportati.

Formato payload e tipo di contenuto

È possibile specificare il formato payload (binario, testo) e il tipo di contenuto quando viene pubblicato un messaggio. Questi dati vengono inoltrati al destinatario del messaggio.

Proprietà MQTT 5

Le proprietà MQTT 5 sono importanti aggiunte allo standard MQTT per supportare nuove funzionalità MQTT 5 come Session Expiry e il pattern. Request/Response In AWS IoT Core, è possibile creare regole in grado di inoltrare le proprietà nei messaggi in uscita o utilizzare HTTP Publish per pubblicare messaggi MQTT con alcune delle nuove proprietà.

Nella tabella seguente sono elencate tutte le proprietà MQTT 5 supportate. AWS IoT Core

Proprietà	Descrizione	Input type (Tipo input)	Pacchetto
Payload Format Indicator	Un valore booleano che indica se il payload è formattato come UTF-8.	Byte	PUBLISH, CONNECT
Content Type	Una stringa UTF-8 che descrive il contenuto del payload.	Stringa UTF-8	PUBLISH, CONNECT
Response Topic	Una stringa UTF-8 che descrive l'argomento su cui il destinatario deve pubblicare come parte del flusso di richiesta-risposta. L'argomento non deve contenere caratteri jolly.	Stringa UTF-8	PUBLISH, CONNECT
Correlation Data	Dati binari utilizzati dal mittente del messaggio di richiesta per identificare a quale richiesta è destinato il messaggio di risposta.	Binario	PUBLISH, CONNECT
User Property	Una coppia di stringhe UTF-8. Questa proprietà può essere visualizzata più volte in un pacchetto. I destinatari riceveranno le coppie chiave-valore nello stesso ordine in cui vengono inviate.	Una coppia di stringhe UTF-8	CONNECT, PUBLISH, Will Properties, SUBSCRIBE, DISCONNECT, UNSUBSCRIBE
Message Expiry Interval	Un numero intero a 4 byte che rappresenta l'intervallo di scadenza del messaggio in secondi. Se assente, il messaggio non scade.	Numero intero a 4 byte	PUBLISH, CONNECT
Session Expiry Interval	Un numero intero a 4 byte che rappresenta l'intervallo di scadenza della sessione in secondi. AWS IoT Core supporta un massimo di 7 giorni, con un massimo predefinito di un'ora. Se il valore impostato supera il valore massimo del tuo account, AWS IoT Core restituirà il valore corretto nel CONNACK.	Numero intero a 4 byte	CONNECT, CONNACK, DISCONNECT
Assigned Client Identifier	Un ID client casuale generato da AWS IoT Core quando un ID client non è specificato dai dispositivi. L'ID cliente casuale deve essere un nuovo identificatore del cliente che non viene utilizzato da nessun'altra sessione attualmente gestita dal broker.	Stringa UTF-8	CONNACK
Server Keep Alive	Un numero intero a 2 byte che rappresenta il tempo keep alive assegnato dal server. Il server eseguirà la disconnessione del client se il client è inattivo per un periodo superiore al tempo keep alive.	Numero intero a 2 byte	CONNACK
Request Problem Information	Un valore booleano che indica se la Reason String o User Properties vengono inviate in caso di errori.	Byte	CONNECT
Receive Maximum	Un numero intero a 2 byte che rappresenta il numero massimo di pacchetti PUBLISH QOS > 0 che possono essere inviati senza ricevere un PUBACK.	Numero intero a 2 byte	CONNECT, CONNACK
Topic Alias Maximum	Questo valore indica il valore massimo che verrà accettato come un alias argomento. Il valore predefinito è 0.	Numero intero a 2 byte	CONNECT, CONNACK
Maximum QoS	Il valore massimo di QoS supportato. AWS IoT Core L'impostazione predefinita è 1. AWS IoT Core non supporta QoS 2.	Byte	CONNACK
Retain Available	Un valore booleano che indica se il broker di messaggi supporta i AWS IoT Core messaggi conservati. Il valore di default è 1.	Byte	CONNACK
Maximum Packet Size	La dimensione massima del pacchetto che AWS IoT Core accetta e invia. Non può superare i 128 KB.	Numero intero a 4 byte	CONNECT, CONNACK
Wildcard Subscription Available	Un valore booleano che indica se il broker di AWS IoT Core messaggi supporta Wildcard Subscription Available. Il valore di default è 1.	Byte	CONNACK
Subscription Identifier Available	Un valore booleano che indica se il broker di AWS IoT Core messaggi supporta Subscription Identifier Available. Il valore predefinito è 0.	Byte	CONNACK

Codici motivo MQTT

MQTT 5 introduce una migliore segnalazione degli errori con risposte al codice motivo. AWS IoT Core può restituire i codici causali inclusi, a titolo esemplificativo ma non esaustivo, i seguenti raggruppati per pacchetti. Per un elenco completo dei codici motivo supportati da MQTT 5, consulta Specifiche MQTT v5.

Codici motivo CONNACK
Valore	Hex	Nome del codice motivo	Descrizione
0	0x00	Riuscito	La connessione è accettata.
128	0x80	Unspecified error (Errore non specificato)	Il server non desidera rivelare il motivo dell'errore o nessuno degli altri codici motivo è valido.
133	0x85	Client Identifier not valid (Identificatore client non valido)	L'identificatore client è una stringa valida ma non è consentito dal server.
134	0x86	Bad User Name or Password (Nome utente o password errati)	Il server non accetta il nome utente o la password specificati dal client.
135	0x87	Not authorized (Non autorizzato)	Il client non è autorizzato a connettersi.
144	0x90	Topic Name invalid (Nome argomento non valido)	Il formato del nome argomento conclusivo è corretto ma non è accettato dal server.
151	0x97	Quota superata	È stato superato un limite imposto di implementazione o amministrativo.
155	0x9B	QoS not supported (QoS non supportato)	Il server non supporta il QoS impostato in Will QoS.

Codici motivo PUBACK
Valore	Hex	Nome del codice motivo	Descrizione
0	0x00	Riuscito	Il messaggio è accettato. La pubblicazione del messaggio QoS 1 avanza.
128	0x80	Unspecified error (Errore non specificato)	Il ricevitore non accetta la pubblicazione, ma non vuole rivelare il motivo o questo non corrisponde a uno degli altri valori.
135	0x87	Not authorized (Non autorizzato)	Il PUBLISH non è autorizzato.
144	0x90	Topic Name invalid (Nome argomento non valido)	Il nome dell'argomento non è malformato, ma non è accettato dal client o dal server.
145	0x91	Packet identifier in use (Identificatore pacchetto in uso)	L'identificatore pacchetto è già in uso. Ciò potrebbe indicare una mancata corrispondenza nello stato della sessione tra il client e il server.
151	0x97	Quota superata	È stato superato un limite imposto di implementazione o amministrativo.

Codici motivo DISCONNECT
Valore	Hex	Nome del codice motivo	Descrizione
129	0x81	Malformed Packet (Pacchetto non conforme)	Il pacchetto ricevuto non è conforme a questa specifica.
130	0x82	Protocol Error (Errore di protocollo)	È stato ricevuto un pacchetto imprevisto o non in ordine.
135	0x87	Not authorized (Non autorizzato)	La richiesta non è autorizzata.
139	0x8B	Server shutting down (Arresto del server)	Il server è in fase di arresto.
141	0x8D	Keep Alive timeout (Timeout Keep Alive)	La connessione è stata chiusa perché non è stato ricevuto alcun pacchetto per 1,5 volte il tempo Keep Alive.
142	0x8E	Session taken over (Sessione acquisita)	Un'altra connessione che utilizza lo stesso ClientID è stata connessa, causando la chiusura di questa connessione.
143	0x8F	Topic Filter invalid (Filtro argomenti non valido)	Il formato del filtro argomenti è corretto ma non è accettato dal server.
144	0x90	Topic Name invalid (Nome argomento non valido)	Il formato del nome argomento è corretto ma non è accettato da questo client o dal server.
147	0x93	Receive Maximum exceeded (Ricezione massima superata)	Il client o il server hanno ricevuto più della pubblicazione Receive Maximum (Ricezione massima) per la quale non hanno inviato PUBACK o PUBCOMP.
148	0x94	Topic Alias invalid (Alias argomento non valido)	Il client o il server hanno ricevuto un pacchetto PUBLISH contenente un alias argomento maggiore dell'alias argomento massimo che ha inviato nel pacchetto CONNECT o CONNACK.
151	0x97	Quota superata	È stato superato un limite imposto di implementazione o amministrativo.
152	0x98	Administrative action (Operazione amministrativa)	La connessione viene chiusa a causa di un'operazione amministrativa.
155	0x9B	QoS not supported (QoS non supportato)	Il client ha specificato un QoS maggiore del QoS specificato in un QoS massimo in CONNACK.
161	0xA1	Subscription Identifiers not supported (Identificatori sottoscrizione non supportati)	Il server non supporta gli identificatori sottoscrizione; la sottoscrizione non è accettata.

Codici motivo SUBACK
Valore	Hex	Nome del codice motivo	Descrizione
0	0x00	Granted QoS 0 (QoS concesso 0)	La sottoscrizione è accettata e il QoS massimo inviato sarà QoS 0. Potrebbe essere un QoS inferiore a quello richiesto.
1	0x01	Granted QoS 1 (QoS concesso 1)	La sottoscrizione è accettata e il QoS massimo inviato sarà QoS 1. Potrebbe essere un QoS inferiore a quello richiesto.
128	0x80	Unspecified error (Errore non specificato)	La sottoscrizione non è accettata e il server non desidera rivelare il motivo o nessuno degli altri codici motivo è valido.
135	0x87	Not authorized (Non autorizzato)	Il client non è autorizzato a effettuare questa sottoscrizione.
143	0x8F	Topic Filter invalid (Filtro argomenti non valido)	Il formato del filtro argomenti è corretto ma non è consentito per questo client.
145	0x91	Packet Identifier in use (Identificatore pacchetto in uso)	L'identificatore pacchetto specificato è già in uso.
151	0x97	Quota superata	È stato superato un limite imposto di implementazione o amministrativo.

Codici motivo UNSUBACK
Valore	Hex	Nome del codice motivo	Descrizione
0	0x00	Riuscito	La sottoscrizione viene eliminata.
128	0x80	Unspecified error (Errore non specificato)	L'annullamento della sottoscrizione non può essere completata e il server non desidera rivelare il motivo o nessuno degli altri codici motivo è valido.
143	0x8F	Topic Filter invalid (Filtro argomenti non valido)	Il formato del filtro argomenti è corretto ma non è consentito per questo client.
145	0x91	Packet Identifier in use (Identificatore pacchetto in uso)	L'identificatore pacchetto specificato è già in uso.

AWS IoT differenze rispetto alle specifiche MQTT

L'implementazione del broker di messaggi è basata sulla specifica MQTT v3.1.1 e la specifica MQTT v5.0 ma è diversa dalle specifiche per quanto riguarda le considerazioni seguenti:

AWS IoT non supporta i seguenti pacchetti per MQTT 3: PUBREC, PUBREL e PUBCOMP.
AWS IoT non supporta i seguenti pacchetti per MQTT 5: PUBREC, PUBREL, PUBCOMP e AUTH.
AWS IoT non supporta il reindirizzamento del server MQTT 5.
AWS IoT supporta solo i livelli di qualità del servizio (QoS) MQTT 0 e 1. AWS IoT non supporta la pubblicazione o l'abbonamento con QoS di livello 2. Il broker di messaggi non invia un messaggio PUBACK o SUBACK quando è richiesto un livello QoS 2.
In AWS IoT, la sottoscrizione a un argomento con livello QoS 0 significa che un messaggio viene recapitato zero o più volte. È possibile che un messaggio venga recapitato più di una volta. I messaggi recapitati più di una volta potrebbero essere inviati con un ID pacchetto diverso. In questi casi, il flag DUP non è impostato.
Nel rispondere a una richiesta di connessione, il broker di messaggi invia un messaggio CONNACK. Questo messaggio contiene un flag per indicare se la connessione sta riprendendo una sessione precedente.
Prima di inviare pacchetti di controllo aggiuntivi o una richiesta di disconnessione, il client deve attendere che broker di messaggi di AWS IoT riceva il messaggio CONNACK.
Quando un client sottoscrive un argomento, può verificarsi un ritardo tra il momento in cui il broker di messaggi invia un messaggio SUBACK e il momento in cui il client inizia a ricevere nuovi messaggi corrispondenti.
Quando un client utilizza il carattere jolly # nel filtro argomento per sottoscrivere un argomento, tutte le stringhe al livello e al di sotto del livello nella gerarchia degli argomenti vengono abbinate. Tuttavia, l'argomento principale non è corrispondente. Ad esempio, una sottoscrizione all'argomento sensor/# riceve messaggi pubblicati sugli argomenti sensor/, sensor/temperature, sensor/temperature/room1, ma non messaggi pubblicati su sensor. Per ulteriori informazioni sull'utilizzo di caratteri jolly, vedi Filtri per i nomi degli argomenti.
Il broker di messaggi usa l'ID client per identificare ogni client. L'ID client viene passato dal client al broker di messaggi come parte del payload MQTT. Due client con lo stesso ID client non possono essere connessi contemporaneamente al broker di messaggi. Quando un client si connette al broker di messaggi tramite un ID client usato da un altro client, viene accettata la connessione del nuovo client e il client connesso in precedenza viene disconnesso. È inoltre possibile disconnettere manualmente i client utilizzando. APIs Per ulteriori informazioni, consulta Gestione delle connessioni MQTT.
In rari casi, il broker di messaggi può inviare di nuovo lo stesso messaggio PUBLISH logico con un ID pacchetto diverso.
La sottoscrizione ai filtri degli argomenti che contengono un carattere jolly non può ricevere messaggi conservati. Per ricevere un messaggio conservato, la richiesta di sottoscrizione deve contenere un filtro argomento che corrisponda esattamente all'argomento del messaggio conservato.
Il broker di messaggi non garantisce l'ordine di ricezione dei messaggi e delle conferme.
AWS IoT può avere limiti diversi dalle specifiche. Per ulteriori informazioni, consulta quote e limiti del broker di messaggistica e del protocollo AWS IoT Core nella Guida di riferimento di AWS IoT .
Il flag MQTT DUP non è supportato.

Gestione delle connessioni MQTT

AWS IoT Core fornisce APIs assistenza nella gestione delle connessioni MQTT, inclusa la possibilità di disconnettere i client e gestirne le sessioni. Queste funzionalità offrono un maggiore controllo sulla flotta di AWS IoT clienti e aiutano a risolvere i problemi di connessione.

DeleteConnection API

Utilizzate l'DeleteConnectionAPI per disconnettere i dispositivi MQTT AWS IoT Core specificando il relativo client. IDs Quando disconnetti un client, lo AWS IoT Core disconnette dal broker di messaggi e, facoltativamente, puoi pulire lo stato della sessione e sopprimere il AWS IoT Core messaggio Last Will and Testament (LWT).

Quando chiami l'DeleteConnectionAPI, AWS IoT Core esegue diverse azioni per garantire una disconnessione pulita. AWS IoT Core invia innanzitutto un messaggio di disconnessione MQTT al client per terminare la sessione MQTT. Il servizio chiude quindi il socket sottostante. TCP/TLS

Il broker di messaggi invia un DISCONNECT pacchetto al dispositivo e pubblica un evento del ciclo di vita con il motivo della disconnessione. API_INITIATED_DISCONNECT Ciò consente di identificare quando una disconnessione è stata avviata tramite l'API anziché dal client o a causa di problemi di rete. È possibile monitorare questi eventi per scopi di visibilità, risoluzione dei problemi e controllo. Ad esempio, è possibile utilizzare AWS IoT regole per elaborare questi eventi per tenere traccia di quando e perché i client sono stati disconnessi.

Se si imposta il cleanSession parametro sutrue, AWS IoT Core rimuove lo stato della sessione del client, inclusi tutti gli abbonamenti e i messaggi in coda. Se si pulisce una sessione, la sessione persistente viene interrotta. Se il client era una sessione persistente e il preventWillMessage parametro è impostato sufalse, il servizio invia il messaggio LWT, se disponibile, utile durante le operazioni di manutenzione pianificate.

Quando si chiama l'DeleteConnectionAPI, il processo di disconnessione inizia immediatamente, ma il momento esatto in cui il client riconosce la disconnessione può variare in base alle condizioni della rete e all'implementazione del client. La maggior parte dei client rileva la disconnessione entro pochi secondi, ma in alcuni casi con una connettività di rete scadente, il client potrebbe impiegare più tempo a riconoscere che è stata disconnessa.

Nota

Forzando la disconnessione, un client deve autenticarsi nuovamente e autorizzarsi nuovamente con un nuovo stato di sessione. La chiamata API di per sé non impedisce la riconnessione dei client. Se lo si desidera, è inoltre necessario modificare le credenziali o la politica di un client prima di emettere la DeleteConnection chiamata API.

Per informazioni sui prezzi, consultare Prezzi di AWS IoT Core.

Casi d'uso

L'DeleteConnectionAPI è utile per gestire i client che si comportano male e che presentano comportamenti problematici o consumano risorse eccessive. Forzando la disconnessione, puoi assicurarti che i client ristabiliscano le connessioni con l'autenticazione e l'autorizzazione corrette, il che può aiutare a risolvere i problemi di consumo di risorse.

Anche gli scenari di reindirizzamento dei client traggono vantaggio da questa API. Quando devi reindirizzare i client su diversi endpoint oppure Regioni AWS puoi disconnetterli a livello di codice e farli ricollegare a un altro endpoint modificando le impostazioni DNS. AWS IoT Core Questa API può aiutare a risolvere connessioni bloccate o eliminare stati di sessione problematici che potrebbero impedire il normale funzionamento.

Parametri dell'API

L'DeleteConnectionAPI accetta i seguenti parametri:

ClientID (obbligatorio): L'identificatore univoco del client MQTT da disconnettere. Questo è specificato nel percorso dell'URL. L'ID client non può iniziare con il simbolo del dollaro ($).

Nota
Il client MQTT IDs può contenere caratteri non validi nelle richieste HTTP. Quando si utilizza l'DeleteConnectionAPI, è necessario codificare l'URL (codifica in percentuale) tutti i caratteri dell'ID client validi in MQTT ma non in HTTP. Ciò include caratteri speciali come spazi, barre (/) e caratteri UTF-8. Ad esempio, uno spazio diventa %20, una barra in avanti diventa %2F e il carattere UTF-8 ü diventa %C 3% BC. La codifica corretta garantisce che il client IDs MQTT venga trasmesso correttamente nella chiamata API basata su HTTP.
CleanSession (opzionale): Specifica se rimuovere lo stato della sessione del client durante la disconnessione. Imposta su per true eliminare tutte le informazioni sulla sessione, incluse le sottoscrizioni e i messaggi in coda. Impostato per false preservare lo stato della sessione. Per impostazione predefinita, è impostato su false (mantiene lo stato della sessione). Per le sessioni pulite questo parametro verrà ignorato.
preventWillMessage (facoltativo): Controlla se AWS IoT Core invia il messaggio Last Will and Testament (LWT), se disponibile, al momento della disconnessione. Impostato per impedire l'invio del true messaggio LWT. Impostato per consentire l'falseinvio. Per impostazione predefinita, è impostato su false (invia LWT se disponibile).

Sintassi dell'API

L'DeleteConnectionAPI utilizza il seguente formato di richiesta HTTP:


DELETE /connections/<clientId>?cleanSession=<cleanSession>&preventWillMessage=<preventWillMessage> HTTP/1.1

Richieste di esempio:


// Basic disconnect (preserves session, allows LWT message)
DELETE /connections/myDevice123 HTTP/1.1

// Disconnect and clear session
DELETE /connections/myDevice123?cleanSession=TRUE HTTP/1.1

// Disconnect, clear session, and prevent LWT message
DELETE /connections/myDevice123?cleanSession=TRUE&preventWillMessage=TRUE HTTP/1.1

Le richieste riuscite restituiscono HTTP 200 OK senza corpo di risposta.

Nota

Il nome del servizio utilizzato da AWS Signature Version 4 per firmare le richieste è: iotdevicegateway. Puoi trovare il tuo endpoint usando il comando. aws iot describe-endpoint --endpoint-type iot:Data-ATS

Autorizzazioni richieste

Per utilizzare l'DeleteConnectionAPI, è necessaria la seguente autorizzazione IAM:


iot:DeleteConnection

Puoi estendere questa autorizzazione a un cliente specifico IDs utilizzando politiche basate sulle risorse. Per esempio:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:DeleteConnection",
            "Resource": "arn:aws:iot:region:account:client/myDevice*"
        }
    ]
}

Considerazioni importanti

I client disconnessi possono tentare immediatamente di riconnettersi a meno che non sia stata implementata una logica aggiuntiva per impedire la riconnessione. L'operazione di disconnessione interrompe solo la connessione corrente e non impedisce la riconnessione di una connessione. Se devi impedire la riconnessione, prendi in considerazione l'implementazione della logica lato client o la disabilitazione delle credenziali di un dispositivo.

I limiti di velocità si applicano all'API come parte della limitazione di velocità standard dell'API. AWS IoT Core Quando pianifichi operazioni di disconnessione in blocco, assicurati di tenere conto di questi limiti e di implementare una logica di ripetizione dei tentativi e strategie di batch appropriate per evitare limitazioni. Per ulteriori informazioni, consulta Endpoint e quote per AWS IoT Core.

Risposte agli errori

L'DeleteConnectionAPI può restituire le seguenti risposte di errore:

InvalidRequestException: La richiesta non è valida. Ciò può verificarsi se il formato dell'ID client non è valido, contiene un prefisso con il simbolo del dollaro ($) o se mancano i parametri obbligatori.
ResourceNotFoundException: L'ID client specificato non esiste o non è attualmente connesso e non dispone di una sessione persistente.
UnauthorizedException: Non hai le autorizzazioni necessarie per eseguire questa operazione. Assicurati di disporre dell'iot:DeleteConnectionautorizzazione richiesta.
ForbiddenException: Il chiamante non è autorizzato a effettuare la richiesta. Ciò potrebbe verificarsi a causa di autorizzazioni IAM insufficienti o di restrizioni politiche basate sulle risorse.
ThrottlingException: La velocità supera il limite. Riduci la frequenza delle chiamate API e implementa una logica di riprova appropriata con backoff esponenziale.
InternalFailureException: Si è verificato un errore imprevisto. Riprova la richiesta dopo un breve ritardo.
ServiceUnavailableException: Il servizio è temporaneamente non disponibile. Riprova la richiesta dopo un breve ritardo.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Protocolli di dispositivo di comunicazione

Pubblicazione HTTPS

MQTT

In questo argomento:

Connessione con MQTT tramite il dispositivo AWS IoT SDKs

Nota

Nota

Importante

Opzioni di qualità del servizio MQTT (QoS)

Sessioni persistenti MQTT

Creazione di una sessione persistente

Nota

Operazioni durante una sessione persistente

Traffico dei messaggi dopo la riconnessione a una sessione persistente

Termine di una sessione persistente

Nota

Riconnessione dopo la scadenza di una sessione persistente

Addebito dei messaggi di sessione persistente

Messaggi conservati da MQTT

Esempi di utilizzo di messaggi conservati da MQTT

Come messaggio di configurazione iniziale

Come ultimo messaggio di stato noto

In questa sezione:

Attività comuni con MQTT ha conservato i messaggi in AWS IoT Core

Creazione di un messaggio conservato

Nota

Iscrizione di un argomento del messaggio conservato

Nota

Recupero di un messaggio conservato

Elenco di argomenti di messaggio conservati

Ricevere i dettagli del messaggio conservati

Conservazione di un messaggio Will

Eliminazione di un messaggio conservato

Debugging e risoluzione dei problemi dei messaggi conservati

La pagina Messaggi conservati

Il client di test MQTT

Limiti di messaggi conservati

Ordine di consegna dei messaggi conservati

Messaggi di fatturazione e conservati

Confronto tra i messaggi conservati MQTT e le sessioni persistenti MQTT

MQTT ha mantenuto i messaggi e i Device Shadows AWS IoT

Messaggi MQTT Last Will and Testament (LWT)

Utilizzo degli Attributi Connect

Caratteristiche supportate da MQTT 5

AWS IoT Core supporta le seguenti funzionalità MQTT 5:

Abbonamenti condivisi

Abbonamenti condivisi, accodamento dei messaggi

Avvio pulito e scadenza della sessione

Codice motivo su tutti ACKs

Alias degli argomenti

Scadenza del messaggio

Altre caratteristiche MQTT 5

Proprietà MQTT 5

Codici motivo MQTT

AWS IoT differenze rispetto alle specifiche MQTT

Gestione delle connessioni MQTT

DeleteConnection API

Nota

Casi d'uso

Parametri dell'API

Nota

Sintassi dell'API

Nota

Autorizzazioni richieste

Considerazioni importanti

Risposte agli errori