Funzionalità MQTT supportate dalla funzionalità broker MQTT di Griglia di eventi di Azure

  • Articolo

MQTT è un protocollo di trasporto di messaggistica publish-subscribe progettato per ambienti vincolati. È efficiente, scalabile e affidabile, che lo rende lo standard gold per la comunicazione negli scenari IoT. Il broker MQTT supporta i client che pubblicano e sottoscrivono messaggi su MQTT v3.1.1, MQTT v3.1.1 su WebSockets, MQTT v5 e MQTT v5 su WebSocket. Il broker MQTT supporta anche la comunicazione MQTT (MQTT 3.1.1 e MQTT 5).

MQTT v5 ha introdotto molti miglioramenti rispetto a MQTT v3.1.1 per offrire una comunicazione più trasparente, trasparente ed efficiente. È stato aggiunto:

  • Migliore segnalazione errori.
  • Client di comunicazione più trasparenti tramite funzionalità come le proprietà utente e il tipo di contenuto.
  • Maggiore controllo per i client sulla comunicazione tramite funzionalità come la scadenza del messaggio e della sessione.
  • Modelli importanti standard come il modello di richiesta-risposta.

flusso di Connessione ion:

I client MQTT devono connettersi tramite TLS 1.2 o TLS 1.3. I tentativi di ignorare questo passaggio hanno esito negativo con la connessione.

Durante la connessione al broker MQTT, usare le porte seguenti durante la comunicazione tramite MQTT:

  • MQTT v3.1.1 e MQTT v5 sulla porta TCP 8883
  • MQTT v3.1.1 su WebSocket e MQTTv5 su WebSocket sulla porta TCP 443.

Il pacchetto CONNECT deve includere le proprietà seguenti:

  • Il campo ClientId è obbligatorio e deve includere il nome della sessione del client. Il nome della sessione deve essere univoco nello spazio dei nomi. È possibile usare il nome di autenticazione client come nome di sessione se ogni client usa una sessione per ogni client. Se un client usa più sessioni, deve usare valori diversi per ClientId per ognuna delle sessioni.
  • Il campo Nome utente è obbligatorio se non è stato selezionato un valore nell'alternativaAuthenticationNameSources durante la creazione dello spazio dei nomi. In tal caso, è necessario specificare il nome di autenticazione del client nel campo Nome utente. Tale nome deve corrispondere al nome di autenticazione specificato e al valore nel campo del certificato del client specificato durante la creazione della risorsa client.

Altre informazioni sull'autenticazione client.

Supporto per più sessioni

Il supporto multisessione consente ai client MQTT dell'applicazione di avere un'implementazione più scalabile e affidabile connettendosi al broker MQTT con più sessioni attive contemporaneamente.

Configurazione dello spazio dei nomi

Prima di usare questa funzionalità, è necessario configurare lo spazio dei nomi per consentire più sessioni per client. Usare la procedura seguente per configurare più sessioni per client nel portale di Azure:

  • Passare allo spazio dei nomi nel portale di Azure.
  • In Configurazione modificare il valore per Numero massimo di sessioni client per nome di autenticazione impostando il numero di sessioni desiderate per client.
  • Seleziona Applica.

Nota

Per la configurazione dell'interfaccia della riga di comando di Azure, aggiornare la proprietà MaxClientSessionsPerAuthenticationName nel payload dello spazio dei nomi con il valore desiderato.

flusso di Connessione ion:

I pacchetti CONNECT per ogni sessione devono includere le proprietà seguenti:

  • Specificare la proprietà Username nel pacchetto CONNECT per indicare il nome di autenticazione client.
  • Specificare la proprietà ClientID nel pacchetto CONNECT per indicare il nome della sessione, ad esempio uno o più valori per ClientID per ogni nome utente.

Ad esempio, le combinazioni seguenti di Username e ClientIds nel pacchetto CONNECT consentono al client "Mgmt-application" di connettersi al broker MQTT su tre sessioni indipendenti:

  • Prima sessione:
    • Nome utente: Mgmt-application
    • ClientId: Mgmt-Session1
  • Seconda sessione:
    • Nome utente: Mgmt-application
    • ClientId: Mgmt-Session2
  • Terza sessione:
    • Nome utente: Mgmt-application
    • ClientId: Mgmt-Session3

Diagramma di un esempio di più sessioni.

Per altre informazioni, vedere Come stabilire più sessioni per un singolo client.

Gestione delle sessioni:

  • Se un client tenta di assumere la sessione attiva di un altro client presentando il nome della sessione con un nome di autenticazione diverso, la richiesta di connessione viene rifiutata con un errore non autorizzato. Ad esempio, se il client B tenta di connettersi alla sessione 123 assegnata in quel momento per il client A, la richiesta di connessione del client B viene rifiutata. Detto questo, se lo stesso client tenta di riconnettersi con gli stessi nomi di sessione e lo stesso nome di autenticazione, è in grado di assumere il controllo della sessione esistente.
  • Se una risorsa client viene eliminata senza terminare la sessione, altri client non possono usare il nome della sessione fino alla scadenza della sessione. Ad esempio, se il client B crea una sessione con nome di sessione 123, il client B viene eliminato, il client A non può connettersi alla sessione 123 fino alla scadenza.
  • Il limite per il numero di sessioni per client si applica alle sessioni online e offline in qualsiasi momento. Si consideri ad esempio uno spazio dei nomi con le sessioni client massime per nome di autenticazione impostato su 1. Se il client A si connette con una sessione permanente 123, il client A non sarà in grado di connettersi con una nuova sessione 456 perché la sessione 123 è ancora attiva anche se è offline. Di conseguenza, è consigliabile riconnettere sempre lo stesso client con gli stessi nomi di sessione statici anziché generare un nuovo nome di sessione con ogni riconnessione.

Funzionalità di MQTT

la funzionalità di broker MQTT di Griglia di eventi di Azure supporta le funzionalità MQTT seguenti:

Qualità del servizio (QoS)

Il broker MQTT supporta QoS 0 e 1, che definiscono la garanzia di recapito dei messaggi nei pacchetti PUBLISH e SUBSCRIBE tra client e broker MQTT. QoS 0 garantisce la consegna al massimo una volta; i messaggi con QoS 0 non vengono riconosciuti dal sottoscrittore né vengono ritrasmessi dal server di pubblicazione. QoS 1 garantisce il recapito at-least-once; i messaggi vengono riconosciuti dal sottoscrittore e vengono ritrasmessi dal server di pubblicazione se non vengono riconosciuti. QoS consente ai clienti di controllare l'efficienza e l'affidabilità della comunicazione.

Sessioni persistenti

Il broker MQTT supporta sessioni persistenti per MQTT v3.1.1 in modo che il broker MQTT mantenga le informazioni sulla sessione di un client in caso di disconnessioni per garantire l'affidabilità della comunicazione. Queste informazioni includono le sottoscrizioni del client e i messaggi QoS 1 non riconosciuti/ non riconosciuti. I client possono configurare una sessione persistente impostando il flag cleanSession nel pacchetto CONNECT su false.

Pulizia della scadenza dell'avvio e della sessione

MQTT v5 ha introdotto le funzionalità di avvio pulito e scadenza della sessione come miglioramento rispetto a MQTT v3.1.1 nella gestione della persistenza della sessione. Clean Start è una funzionalità che consente a un client di avviare una nuova sessione con il broker MQTT, ignorando eventuali dati di sessione precedenti. La scadenza della sessione consente a un client di informare il broker MQTT quando una sessione inattiva viene considerata scaduta e rimossa automaticamente. Nel pacchetto CONNECT un client può impostare clean start flag su true e/o breve intervallo di scadenza della sessione per motivi di sicurezza o per evitare potenziali conflitti di dati che potrebbero essersi verificati durante la sessione precedente. Un client può anche impostare un inizio pulito su false e/o lungo intervallo di scadenza della sessione per garantire l'affidabilità e l'efficienza delle sessioni persistenti.

Configurazione massima dell'intervallo di scadenza della sessione

È possibile configurare l'intervallo di scadenza massimo della sessione consentito per tutti i client che si connettono allo spazio dei nomi griglia di eventi. Per i client MQTT v3.1.1, il limite configurato viene applicato come intervallo di scadenza di sessione predefinito per tutte le sessioni persistenti. Per i client MQTT v5, il limite configurato viene applicato come valore massimo per la proprietà Session Expiry Interval nel pacchetto CONNECT; qualsiasi valore che supera il limite viene regolato. Il valore predefinito per questa proprietà dello spazio dei nomi è 1 ora e può essere esteso fino a 8 ore. Seguire questa procedura per configurare l'intervallo di scadenza massimo della sessione nel portale di Azure:

  • Passare allo spazio dei nomi nel portale di Azure.
  • In Configurazione modificare il valore per l'intervallo massimo di scadenza della sessione in ore in base al limite desiderato.
  • Selezionare Applica.

screenshot per la configurazione massima dell'intervallo di scadenza della sessione.

Overflow della sessione

Il broker MQTT gestisce una coda di messaggi per ogni sessione MQTT attiva non connessa, fino a quando il client non si connette nuovamente con il broker MQTT per ricevere i messaggi nella coda. Se un client non si connette per ricevere i messaggi QOS1 in coda, la coda di sessione inizia ad accumulare i messaggi fino a raggiungere il limite: 100 messaggi o 1 MB. Quando la coda raggiunge il limite durante la durata della sessione, la sessione viene terminata.

Ultimi messaggi Will and Testament (LWT) (anteprima)

Last Will and Testament (LWT) notifica ai client MQTT le interruzioni improvvise di altri client MQTT. È possibile usare LWT per garantire un flusso di comunicazione prevedibile e affidabile tra i client MQTT durante le disconnessioni impreviste, utile per gli scenari in cui le comunicazioni in tempo reale, l'affidabilità del sistema e le azioni coordinate sono fondamentali. I client che collaborano per eseguire attività complesse possono reagire a messaggi LWT l'uno dall'altro modificando il comportamento, ridistribuendo le attività o assumendo determinate responsabilità per mantenere le prestazioni e la stabilità del sistema. Per usare LWT, un client può specificare il messaggio will, verrà argomento e il resto delle proprietà nel pacchetto CONNECT durante la connessione. Quando il client si disconnette improvvisamente, il broker MQTT pubblica il messaggio will a tutti i client che hanno sottoscritto l'argomento will.

Proprietà utente

Il broker MQTT supporta le proprietà utente nei pacchetti MQTT v5 PUBLISH che consentono di aggiungere coppie chiave-valore personalizzate nell'intestazione del messaggio per fornire più contesto sul messaggio. I casi d'uso per le proprietà utente sono versatili. È possibile usare questa funzionalità per includere lo scopo o l'origine del messaggio in modo che il ricevitore possa gestire il messaggio senza analizzare il payload, salvando le risorse di calcolo. Ad esempio, un messaggio con una proprietà utente che indica lo scopo come "avviso" potrebbe attivare una logica di gestione diversa da quella con lo scopo di "informazioni".

Criterio richiesta-risposta

MQTTv5 ha introdotto i campi nell'intestazione del pacchetto MQTT PUBLISH che forniscono il contesto per il messaggio di risposta nel modello request-response. Questi campi includono un argomento di risposta e un ID di correlazione che il risponditore può usare nella risposta senza la configurazione precedente. Le informazioni sulla risposta consentono una comunicazione più efficiente per il modello di richiesta-risposta standard usato negli scenari di comando e controllo.

Diagramma dell'esempio di modello di richiesta-risposta.

Intervallo di scadenza del messaggio:

In MQTT v5, l'intervallo di scadenza del messaggio consente ai messaggi di avere una durata configurabile. L'intervallo di scadenza del messaggio viene definito come intervallo di tempo tra il momento in cui un messaggio viene pubblicato nel broker MQTT e l'ora in cui il broker MQTT deve eliminare il messaggio non recapitato. Questa funzionalità è utile negli scenari in cui i messaggi sono validi solo per una determinata quantità di tempo, ad esempio comandi sensibili al tempo, streaming di dati in tempo reale o avvisi di sicurezza. Impostando un intervallo di scadenza del messaggio, il broker MQTT può rimuovere automaticamente i messaggi obsoleti, assicurandosi che solo le informazioni rilevanti siano disponibili per i sottoscrittori. Se l'intervallo di scadenza di un messaggio è impostato su zero, significa che il messaggio non deve mai scadere.

Alias degli argomenti:

In MQTT v5 gli alias degli argomenti consentono a un client di usare un alias più breve al posto del nome completo dell'argomento nel messaggio pubblicato. Il broker MQTT gestisce un mapping tra l'alias dell'argomento e il nome effettivo dell'argomento. Questa funzionalità consente di risparmiare larghezza di banda di rete e ridurre le dimensioni dell'intestazione del messaggio, in particolare per gli argomenti con nomi lunghi. È utile negli scenari in cui lo stesso argomento viene pubblicato ripetutamente in più messaggi, ad esempio nelle reti del sensore. Il broker MQTT supporta fino a 10 alias di argomento. Un client può usare un campo Alias argomento nel pacchetto PUBLISH per sostituire il nome completo dell'argomento con l'alias corrispondente.

Diagramma dell'esempio di alias dell'argomento.

Controllo del flusso

In MQTT v5 il controllo del flusso fa riferimento al meccanismo per gestire la frequenza e le dimensioni dei messaggi che un client può gestire. Il controllo flusso può essere configurato impostando i parametri Dimensioni massime pacchetto e Ricezione massima nel pacchetto CONNECT. Il parametro Receive Maximum consente al client di limitare il numero di messaggi inviati dal broker al numero di messaggi che il client è in grado di gestire. Il parametro Dimensioni massime pacchetti definisce le dimensioni massime dei pacchetti che il client può ricevere. Il broker MQTT ha un limite di dimensioni del messaggio pari a 512 KiB. Questa funzionalità garantisce affidabilità e stabilità della comunicazione per i dispositivi vincolati con velocità di elaborazione limitata o funzionalità di archiviazione.

Riconoscimenti negativi e pacchetto di disconnessione avviato dal server

Per MQTT v5, il broker MQTT è in grado di inviare riconoscimenti negativi (NACK) e pacchetti di disconnessione avviati dal server che forniscono al client altre informazioni sugli errori per il recapito o la connessione dei messaggi. Queste funzionalità consentono al client di diagnosticare il motivo di un errore ed eseguire azioni di mitigazione appropriate. Il broker MQTT usa i codici motivo definiti nella specifica MQTT v5.

Limitazioni correnti

Il broker MQTT aggiunge altre funzionalità MQTT v5 e MQTT v3.1.1 in futuro per allinearsi maggiormente alle specifiche MQTT. L'elenco seguente illustra in dettaglio le differenze correnti tra le funzionalità supportate dal broker MQTT e le specifiche MQTT:

Limitazioni correnti di MQTTv5

MQTT v5 è attualmente diverso dalla specifica MQTT v5 nei modi seguenti:

  • Le sottoscrizioni condivise non sono ancora supportate.
  • Il flag di conservazione non è ancora supportato.
  • L'intervallo di ritardo non è ancora supportato.
  • Il valore massimo di QoS è 1.
  • La dimensione massima del pacchetto è 512 KiB
  • L'ordinamento dei messaggi non è garantito.
  • Gli identificatori di sottoscrizione non sono supportati.
  • Gli identificatori client assegnati non sono ancora supportati.
  • Il valore massimo dell'alias dell'argomento è 10. Al momento il server non assegna alias di argomento per i messaggi in uscita. I client possono assegnare e usare alias di argomento entro il limite impostato.
  • CONNACK non restituisce la proprietà Response Information anche se la richiesta CONNECT contiene la proprietà Request Response Information.
  • Le proprietà utente in CONNECT, SUBSCRIBE, DISCONNECT, PUBACK, AUTH non vengono usate dal servizio in modo che non siano supportate. Se una di queste richieste include proprietà utente, la richiesta ha esito negativo.
  • Se il server riceve un PUBACK da un client con codice di risposta non riuscito, la connessione viene terminata.
  • Keep Alive Maximum è 1.160 secondi.

Limitazioni correnti di MQTTv3.1.1

MQTT v5 è attualmente diverso dalla specifica MQTT v3.1.1 nei modi seguenti:

  • QoS2 e Retain Flag non sono ancora supportati. Una richiesta di pubblicazione con un flag di conservazione o con QoS2 ha esito negativo e chiude la connessione.
  • L'ordinamento dei messaggi non è garantito.
  • Keep Alive Maximum è 1.160 secondi.

Esempi di codice:

Questo repository contiene esempi di codice C#, C e Python che illustrano come inviare dati di telemetria, inviare comandi e trasmettere avvisi. I certificati creati tramite gli esempi sono adatti per i test, ma non sono adatti per gli ambienti di produzione.

Passaggi successivi:

Altre informazioni su MQTT:

Altre informazioni sul broker MQTT: