MQTT-funktioner som stöds av Azure Event Grid MQTT-koordinatorn

Message Queuing Telemetry Transport (MQTT) är ett transportprotokoll för meddelandeöverföring som har utformats för begränsade miljöer. MQTT är effektivt, skalbart och tillförlitligt, vilket gör det populärt för kommunikation i IoT-scenarier (Internet of Things). MQTT-asynkron meddelandekö stöder klienter som publicerar och prenumererar på meddelanden via MQTT v3.1.1, MQTT v3.1.1 via WebSocket, MQTT v5 och MQTT v5 via WebSocket. MQTT-asynkron meddelandekö stöder även kommunikation mellan MQTT-versioner (MQTT 3.1.1 och MQTT 5).

MQTT-mäklaren i Azure Event Grid stöder även enheter och tjänster som skickar MQTT-meddelanden via HTTPS, vilket förenklar integreringen med icke-MQTT-klienter. Med Event Grid kan du bland annat skicka MQTT-meddelanden till molnet för dataanalys, lagring och visualiseringar. Den här funktionen är för närvarande i förhandsversion.

MQTT v5 introducerade många förbättringar jämfört med MQTT v3.1.1 för att leverera en mer sömlös, transparent och effektiv kommunikation. Den lade till:

• Bättre felrapportering.
• Mer transparent kommunikation till klienter via funktioner som användaregenskaper och innehållstyp.
• Mer kontroll till klienter över kommunikationen via funktioner som meddelande och sessions förfallodatum.
• Viktiga standardmönster som mönstret för begäran-svar.

Anslutningsflöde

Dina MQTT-klienter måste ansluta via TLS (Transport Layer Security) 1.2 eller TLS 1.3. Försök att hoppa över det här steget misslyckas med anslutningen.

När du ansluter till MQTT-asynkron meddelandekö använder du följande portar under kommunikationen via MQTT:

• MQTT v3.1.1 och MQTT v5 på TCP-port 8883
• MQTT v3.1.1 över WebSocket och MQTT v5 via WebSocket på TCP-port 443

CONNECT-paketet bör innehålla följande egenskaper:

• Fältet ClientId krävs och det bör innehålla sessionsnamnet för klienten. Sessionsnamnet måste vara unikt i namnområdet. Du kan använda namnet på klientautentiseringen som sessionsnamn om varje klient använder en session per klient. Om en klient använder flera sessioner måste den använda olika värden för ClientId var och en av sina sessioner.
• Fältet Username krävs om du inte valde ett värde i alternativeAuthenticationNameSources när namnområdet skapades. I så fall måste du ange klientens autentiseringsnamn i fältet Username . Det namnet måste matcha det angivna autentiseringsnamnet och värdet i klientens certifikatfält som angavs när klientresursen skapades.

Läs mer om klientautentisering.

Stöd för flera sessioner

Stöd för flera sessioner gör det möjligt för ditt program MQTT-klienter att ha en mer skalbar och tillförlitlig implementering genom att ansluta till MQTT-koordinatorn med flera aktiva sessioner samtidigt.

Namnområdeskonfiguration

Innan du använder den här funktionen måste du konfigurera namnområdet så att flera sessioner per klient tillåts. Följ dessa steg för att konfigurera flera sessioner per klient i Azure-portalen:

1. Gå till namnområdet i Azure Portal.
2. Under Konfiguration ändrar du värdet för Maximalt antal klientsessioner per autentiseringsnamn till det antal sessioner per klient som du vill använda.
3. Välj Använd.

Anslutningsflöde

CONNECT-paketen för varje session bör innehålla följande egenskaper:

• Username Ange egenskapen i CONNECT-paketet för att ange ditt klientautentiseringsnamn.
• ClientID Ange egenskapen i CONNECT-paketet för att ange sessionsnamnet, till exempel om det finns ett eller flera värden för klient-ID:t för varje användarnamn.

Följande kombinationer av Username och ClientId i CONNECT-paketet gör det till exempel möjligt för klienten Mgmt-application att ansluta till MQTT-asynkron meddelandekö över tre oberoende sessioner:

• Första sessionen:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session1
• Andra sessionen:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session2
• Tredje sessionen:
  • Username: Mgmt-application
  • ClientId: Mgmt-Session3

Mer information finns i Upprätta flera sessioner för en enskild klient.

Hantera sessioner

• Om en klient försöker ta över en annan klients aktiva session genom att presentera sitt sessionsnamn med ett annat autentiseringsnamn avvisas anslutningsbegäran med ett obehörigt fel. Om till exempel klient B försöker ansluta till session 123 som tilldelades vid den tidpunkten för klient A, avvisas klient B:s anslutningsbegäran. Men om samma klient försöker återansluta med samma sessionsnamn och samma autentiseringsnamn kan den ta över den befintliga sessionen.
• Om en klientresurs tas bort utan att sessionen avslutas kan andra klienter inte använda sitt sessionsnamn förrän sessionen upphör att gälla. Om till exempel klient B skapar en session med sessionsnamnet 123 och sedan klient B tas bort, kan klient A inte ansluta till session 123 förrän den upphör att gälla.
• Gränsen för antalet sessioner per klient gäller för online- och offlinesessioner när som helst. Överväg till exempel ett namnområde med maximalt antal klientsessioner per autentiseringsnamn inställt på 1. Klient A ansluter till en beständig session 123 och kopplas sedan från. Klient A kan inte ansluta till en ny session 456 eftersom dess session 123 fortfarande är aktiv även om den är offline. Därför rekommenderar vi att samma klient alltid återansluter med samma statiska sessionsnamn i stället för att generera ett nytt sessionsnamn med varje återanslutning.

MQTT-funktioner

Event Grid MQTT-asynkron meddelandekö stöder följande MQTT-funktioner.

Tjänstkvalitet

MQTT-koordinatorn stöder QoS-nivåerna (Quality of Service) 0 och 1, som definierar garantin för meddelandeleverans på PUBLISH- och SUBSCRIBE-paket mellan klienter och MQTT-koordinatorn.

• QoS 0 garanterar leverans högst en gång: Prenumeranten bekräftar inte meddelanden med QoS 0 och utgivaren översänder dem inte igen.
• QoS 1 garanterar leverans minst en gång: Prenumeranten bekräftar meddelanden och utgivaren överför dem igen om de inte bekräftas.

Med QoS kan dina klienter kontrollera effektiviteten och tillförlitligheten i kommunikationen.

Beständiga sessioner

MQTT-mäklaren stöder beständiga sessioner för MQTT v3.1.1 så att MQTT-koordinatorn bevarar information om en klients session när den kopplas från för att säkerställa kommunikationens tillförlitlighet. Den här informationen omfattar klientens prenumerationer och missade eller obemärkta QoS 1-meddelanden. Klienter kan konfigurera en beständig session genom att ange cleanSession flaggan i CONNECT-paketet till false.

Rensa start och sessionen upphör att gälla

MQTT v5 introducerade funktionerna för ren start och sessionsförfallotid som en förbättring jämfört med MQTT v3.1.1 i hanteringen av sessionspersistence. Med ren start kan en klient starta en ny session med MQTT-asynkron meddelandekö efter att tidigare sessionsdata har ignorerats. Med sessionsförfallodatum kan en klient informera MQTT-asynkron meddelandekö när en inaktiv session anses ha upphört att gälla och tas bort automatiskt.

I CONNECT-paketet kan en klient ange Clean Start flaggan till true. En klient kan också ange ett kort intervall för sessionens förfallodatum av säkerhetsskäl eller för att undvika eventuella datakonflikter som kan ha inträffat under föregående session. En klient kan också ange Clean Start flaggan till false eller ett långt sessionsintervall för förfallodatum för att säkerställa tillförlitligheten och effektiviteten för beständiga sessioner.

Maximal konfiguration av förfallointervall för sessionen

Du kan konfigurera det maximala sessions förfallointervallet som tillåts för alla klienter som ansluter till Event Grid-namnområdet. För MQTT v3.1.1-klienter tillämpas den konfigurerade gränsen som standardintervall för sessionsförfallodatum för alla beständiga sessioner. För MQTT v5-klienter tillämpas den konfigurerade gränsen som det maximala värdet för egenskapen sessionsförfallointervall i CONNECT-paketet. Alla värden som överskrider gränsen justeras. Standardvärdet för den här namnområdesegenskapen är en timme och kan sträcka sig upp till åtta timmar. Följ dessa steg om du vill konfigurera maximalt intervall för sessionens förfallodatum i Azure-portalen:

1. Gå till namnområdet i Azure Portal.
2. Under Konfiguration ändrar du värdet för Maximalt sessionsförfallointervall i timmar till den gräns som du vill använda.
3. Välj Använd.

Sessionsspill

MQTT-koordinatorn underhåller en kö med meddelanden för varje aktiv MQTT-session som inte är ansluten tills klienten ansluter med MQTT-asynkron meddelandekö igen för att ta emot meddelandena i kön. Om en klient inte ansluter för att ta emot QoS 1-meddelanden i kö ackumuleras meddelanden i sessionskön tills den når gränsen på 100 meddelanden eller 1 MB. När kön når sin gräns under sessionens livslängd avslutas sessionen.

Meddelanden från Last Will och Testamente

Last Will and Testament (LWT) meddelar dina MQTT-klienter med plötsliga frånkopplingar av andra MQTT-klienter. Du kan använda LWT för att säkerställa förutsägbart och tillförlitligt kommunikationsflöde mellan MQTT-klienter under oväntade frånkopplingar. Den här funktionen är värdefull för scenarier där kommunikation i realtid, systemtillförlitlighet och samordnade åtgärder är viktiga. Klienter som samarbetar för att utföra komplexa uppgifter kan reagera på LWT-meddelanden från varandra genom att justera deras beteende, omdistribuera uppgifter eller ta över vissa ansvarsområden för att upprätthålla systemets prestanda och stabilitet.

Om du vill använda LWT kan en klient ange will-meddelandet, will-ämnet och resten av Will-egenskaperna i CONNECT-paketet under anslutningen. När klienten plötsligt kopplas från publicerar MQTT-koordinatorn Will-meddelandet till alla klienter som prenumererar på will-ämnet. För att minska bruset från fluktuerande frånkopplingar kan klienten ange fördröjningsintervallet till ett värde som är större än noll. I så fall, om klienten kopplar från plötsligt men återställer anslutningen innan fördröjningsintervallet upphör att gälla, publiceras inte Will-meddelandet.

Användaregenskaper

MQTT-asynkron meddelandekö stöder användaregenskaper på MQTT v5 PUBLISH-paket som du kan använda för att lägga till anpassade nyckel/värde-par i meddelandehuvudet för att ge mer kontext om meddelandet. Användningsfallen för användaregenskaper är mångsidiga. Du kan använda den här funktionen för att inkludera syftet med eller ursprunget för meddelandet så att mottagaren kan hantera meddelandet utan att parsa nyttolasten, vilket sparar databehandlingsresurser. Ett meddelande med en användaregenskap som anger dess syfte som en "varning" kan till exempel utlösa en annan hanteringslogik än ett med syftet med "information".

Mönster för begärandesvar

MQTT v5 introducerade fält i MQTT PUBLISH-paketrubriken som ger kontext för svarsmeddelandet i mönstret för begäran-svar. De här fälten innehåller ett svarsämne och ett korrelations-ID som svararen kan använda i svaret utan föregående konfiguration. Svarsinformationen möjliggör effektivare kommunikation för standardmönstret för begäran-svar som används i kommando- och kontrollscenarier.

Meddelandets giltighetstid

I MQTT v5 tillåter meddelandets förfallointervall att meddelanden har en konfigurerbar livslängd. Intervallet för meddelandeförfallodatum definieras som tidsintervallet mellan den tid då ett meddelande publiceras till MQTT-asynkron meddelandekö och den tid då asynkron meddelandekö måste ignorera det olevererade meddelandet. Den här funktionen är användbar i scenarier där meddelanden endast är giltiga under en viss tid, till exempel tidskänsliga kommandon, dataströmning i realtid eller säkerhetsaviseringar. Genom att ange ett intervall för meddelandeförfallodatum kan MQTT-asynkron meddelandekö automatiskt ta bort inaktuella meddelanden. Det här steget säkerställer att endast relevant information är tillgänglig för prenumeranter. Om ett meddelandes förfallointervall är inställt på noll innebär det att meddelandet aldrig ska upphöra att gälla.

Ämnesalias

I MQTT v5 tillåter ämnesalias att en klient använder ett kortare alias i stället för det fullständiga ämnesnamnet i det publicerade meddelandet. MQTT-asynkron meddelandekö upprätthåller en mappning mellan ämnesaliaset och det faktiska ämnesnamnet. Den här funktionen kan spara nätverksbandbredd och minska storleken på meddelanderubriken, särskilt för ämnen med långa namn. Det är användbart i scenarier där samma ämne publiceras upprepade gånger i flera meddelanden, till exempel i sensornätverk. MQTT-asynkron meddelandekö stöder upp till 10 ämnesalias. En klient kan använda ett Topic Alias fält i PUBLISH-paketet för att ersätta det fullständiga ämnesnamnet med motsvarande alias.

Flödeskontroll

I MQTT v5 refererar flödeskontroll till mekanismen för att hantera hastigheten och storleken på meddelanden som en klient kan hantera. Konfigurera flödeskontroll genom att ange parametrarna Maximum Packet Size och Receive Maximum i CONNECT-paketet. Med Receive Maximum parametern kan klienten begränsa antalet meddelanden som skickas av asynkron meddelandekö till antalet meddelanden som klienten kan hantera. Parametern Maximum Packet Size definierar den maximala storleken på paket som klienten kan ta emot. MQTT-asynkron meddelandestorleksgräns på 512 KiB. Den här funktionen säkerställer kommunikationens tillförlitlighet och stabilitet för begränsade enheter med begränsad bearbetningshastighet eller lagringsfunktioner.

Negativa bekräftelser och serverinitierat frånkopplingspaket

För MQTT v5 kan MQTT-koordinatorn skicka negativa bekräftelser och serverinitierade frånkopplingspaket som ger klienten mer information om fel vid meddelandeleverans eller anslutning. Dessa funktioner hjälper klienten att diagnostisera orsaken bakom ett fel och vidta lämpliga åtgärder för att mildra problemet. MQTT-koordinatorn använder de orsakskoder som definieras i MQTT v5-specifikationen.

Meddelandeordning

MQTT v5 säkerställer leverans av meddelanden i ordning inom varje ämne och varje klient när QoS nivå 1 används, vilket är avgörande för arbetsflöden som kräver sekvensintegritet. Det är idealiskt för scenarier som telemetri, kommandokörning och tidsseriedata.

Det garanterar dock inte beställning i olika ämnen eller när meddelanden skickas med varierande QoS-nivåer. Om du vill veta mer kontaktar du oss på askmqtt@microsoft.com.

Tilldelade klientidentifierare

MQTT v5 introducerar stöd för tilldelade klientidentifierare, vilket gör att MQTT-koordinatorn kan generera och returnera ett unikt klient-ID när klienten inte tillhandahåller något. MQTT-koordinatorstöd för den här funktionen säkerställer sömlös klientregistrering och minskar behovet av att klienter hanterar sina egna identifierare. Det är särskilt användbart i scenarier där klientetablering är dynamiskt eller när enheter inte har någon förkonfigurerad identitet. Tilldelade klient-ID:er kan hämtas från CONNACK-svaret och återanvändas för framtida sessioner för att upprätthålla konsekvent identifiering.

Hantera klientidentifierare och sessionsgränser i MQTT

• Med tilldelade klientidentifierare kan klienter ansluta utan att ange fördefinierade identifierare, vilket aktiverar tillfälliga eller beständiga sessioner.
• Klienter kan undvika att bli utelåst genom att använda korta intervall för sessionsförfallotid under den första anslutningen och spara den tilldelade klientidentifieraren för framtida användning.
• För uppdateringar eller återställning av inbyggd programvara bör klienter antingen behålla sin kända klientidentifierare eller använda blygsamma intervall för sessionsutfallodatum för att undvika långvariga utelåsningar.
• Namnområdeskonfiguration kan öka sessionsgränserna per klient för att minimera störningar under uppdateringar eller återställningar.

Aktuella begränsningar

MQTT-koordinatorn lägger till fler MQTT v5- och MQTT v3.1.1-funktioner i framtiden för att anpassa sig mer till MQTT-specifikationerna. I följande lista beskrivs de aktuella skillnaderna mellan funktioner som stöds av MQTT-koordinatorn och MQTT-specifikationerna.

Aktuella begränsningar för MQTT v5

MQTT v5 skiljer sig för närvarande från MQTT v5-specifikationen på följande sätt:

• Delade prenumerationer stöds inte ännu.
• Maximalt fördröjningsintervall för Will är 300.
• Högsta QoS är 1.
• Maximal paketstorlek är 512 KiB.
• Prenumerationsidentifierare stöds inte.
• Maximalt ämnesalias är 10. Servern tilldelar för närvarande inga ämnesalias för utgående meddelanden. Klienter kan tilldela och använda ämnesalias inom den angivna gränsen.
• CONNACK returnerar Response Information inte egenskapen även om CONNECT-begäran innehåller Request Response Information egenskapen.
• Användaregenskaper för CONNECT-, SUBSCRIBE-, DISCONNECT-, PUBACK- och AUTH-paket används inte av tjänsten, så de stöds inte. Om någon av dessa begäranden innehåller användaregenskaper misslyckas begäran.
• Om servern tar emot ett PUBACK-paket från en klient med en nonsuccess-svarskod avslutas anslutningen.
• Keep Alive max är 1 160 sekunder.

Aktuella begränsningar för MQTTv3.1.1

MQTT v5 skiljer sig för närvarande från MQTT v3.1.1-specifikationen på följande sätt:

• QoS 2 stöds inte. En publiceringsbegäran med en RETAIN flagga eller med en QoS 2 misslyckas och stänger anslutningen.
• Keep Alive max är 1 160 sekunder.

Kodexempel

Den här lagringsplatsen innehåller C#-, C- och Python-kodexempel som visar hur du skickar telemetri, skickar kommandon och skickar aviseringar. Certifikaten som skapas via exemplen är lämpliga för testning, men de passar inte för produktionsmiljöer.

Relaterat innehåll

Mer information om MQTT finns i MQTT v5-specifikationen. Mer information om MQTT-koordinatorn finns i:

• Klientautentisering
• Upprätta flera sessioner för en enskild klient