Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # CoreMQTT-Demos **Wichtig** Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie [hier beginnen](freertos-getting-started-modular.md), wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. [Leitfaden zur Migration des Amazon-FreerTOS Github-Repositorys](github-repo-migration.md) Diese Demos können Ihnen helfen, den Umgang mit der CoreMQTT-Bibliothek zu erlernen. **Topics** + [Demo zur gegenseitigen CoreMQTT-Authentifizierung](mqtt-demo-ma.md) + [Demo zur gemeinsamen Nutzung von CoreMQTT-Agenten](mqtt-demo-cs.md) # Demo zur gegenseitigen CoreMQTT-Authentifizierung **Wichtig** Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie [hier beginnen](freertos-getting-started-modular.md), wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. [Leitfaden zur Migration des Amazon-FreerTOS Github-Repositorys](github-repo-migration.md) ## Einführung Das Demo-Projekt zur gegenseitigen Authentifizierung von CoreMQTT zeigt Ihnen, wie Sie mithilfe von TLS eine Verbindung zu einem MQTT-Broker mit gegenseitiger Authentifizierung zwischen dem Client und dem Server herstellen. [Diese Demo verwendet eine MbedTLS-basierte Transportschnittstellenimplementierung, um eine server- und clientauthentifizierte TLS-Verbindung herzustellen, und demonstriert den Subscribe-Publish-Workflow von MQTT auf QoS-1-Ebene.](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#_Toc442180914) Es abonniert einen Themenfilter, veröffentlicht dann Themen, die dem Filter entsprechen, und wartet auf den Empfang dieser Nachrichten vom Server auf QoS-1-Ebene. Dieser Zyklus der Veröffentlichung auf dem Broker und dem Empfang derselben Nachricht vom Broker wird auf unbestimmte Zeit wiederholt. Nachrichten in dieser Demo werden mit QoS 1 gesendet, was mindestens eine Lieferung gemäß der MQTT-Spezifikation garantiert. **Anmerkung** Folgen Sie den Schritten unter, um die FreeRTOS-Demos einzurichten und auszuführen. [Erste Schritte mit FreeRTOS](freertos-getting-started.md) ## Quellcode Die Demo-Quelldatei ist benannt `mqtt_demo_mutual_auth.c` und befindet sich im `freertos/demos/coreMQTT/` Verzeichnis und auf der Website. [ GitHub](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c) ## Funktionalität Die Demo erstellt eine einzelne Anwendungsaufgabe, die eine Reihe von Beispielen durchläuft, die zeigen, wie eine Verbindung zum Broker hergestellt, ein Thema auf dem Broker abonniert, ein Thema auf dem Broker veröffentlicht und schließlich die Verbindung zum Broker getrennt wird. Die Demo-Anwendung abonniert und veröffentlicht dasselbe Thema. Jedes Mal, wenn die Demo eine Nachricht an den MQTT-Broker veröffentlicht, sendet der Broker dieselbe Nachricht zurück an die Demo-Anwendung. Bei erfolgreichem Abschluss der Demo wird eine Ausgabe generiert, die der folgenden Abbildung ähnelt. ![\[Ausgabe des MQTT-Demo-Terminals bei erfolgreichem Abschluss\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/coremqtt-mad-output.png) Die AWS IoT Konsole generiert eine Ausgabe, die der folgenden Abbildung ähnelt. ![\[Ausgabe der MQTT-Demo-Konsole bei erfolgreichem Abschluss\]](http://docs.aws.amazon.com/de_de/freertos/latest/userguide/images/coremqtt-mad-console.png) ## Wiederholen Sie die Logik mit exponentiellem Backoff und Jitter Die [ prvBackoffForWiederholungsfunktion](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L671-L717) zeigt, wie fehlgeschlagene Netzwerkoperationen mit dem Server, z. B. TLS-Verbindungen oder MQTT-Abonnementanfragen, mit exponentiellem Backoff und Jitter wiederholt werden können. Die Funktion berechnet die Backoff-Periode für den nächsten Wiederholungsversuch und führt die Backoff-Verzögerung durch, wenn die Wiederholungsversuche noch nicht ausgeschöpft sind. Da die Berechnung der Backoff-Periode die Generierung einer Zufallszahl erfordert, verwendet die Funktion das Modul, um die Zufallszahl zu generieren. PKCS11 Die Verwendung des PKCS11 Moduls ermöglicht den Zugriff auf einen True Random Number Generator (TRNG), sofern die Herstellerplattform dies unterstützt. Wir empfehlen, den Zufallszahlengenerator mit einer gerätespezifischen Entropiequelle auszustatten, um die Wahrscheinlichkeit von Kollisionen durch Geräte bei erneuten Verbindungsversuchen zu verringern. ## Verbindung zum MQTT-Broker herstellen Die [ prvConnectToServerWithBackoffRetries](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L721-L782)Funktion versucht, eine gegenseitig authentifizierte TLS-Verbindung zum MQTT-Broker herzustellen. Wenn die Verbindung fehlschlägt, versucht sie es nach einer Backoff-Periode erneut. Die Backoff-Periode wird exponentiell erhöht, bis die maximale Anzahl von Versuchen oder die maximale Backoff-Periode erreicht ist. Die `BackoffAlgorithm_GetNextBackoff` Funktion liefert einen exponentiell steigenden Backoff-Wert und kehrt zurück, `RetryUtilsRetriesExhausted` wenn die maximale Anzahl von Versuchen erreicht wurde. Die `prvConnectToServerWithBackoffRetries` Funktion gibt einen Fehlerstatus zurück, wenn die TLS-Verbindung zum Broker nach der konfigurierten Anzahl von Versuchen nicht hergestellt werden kann. Die MQTTConnection WithBroker Funktion [PrvCreate](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L785-L848) demonstriert, wie eine MQTT-Verbindung zu einem MQTT-Broker mit einer sauberen Sitzung hergestellt wird. Sie verwendet die TLS-Transportschnittstelle, die in der Datei implementiert ist. `FreeRTOS-Plus/Source/Application-Protocols/platform/freertos/transport/src/tls_freertos.c` Denken Sie daran, dass wir die Keep-Alive-Sekunden für den Broker festlegen. `xConnectInfo` Die nächste Funktion zeigt, wie die TLS-Transportschnittstelle und die Zeitfunktion mithilfe der Funktion in einem MQTT-Kontext eingestellt werden. `MQTT_Init` Sie zeigt auch, wie eine Event-Callback-Funktion pointer (`prvEventCallback`) gesetzt wird. Dieser Callback wird für die Meldung eingehender Nachrichten verwendet. ## Ein MQTT-Thema abonnieren Die MQTTSubscribe WithBackoffRetries Funktion [prv](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L871-L969) demonstriert, wie man einen Themenfilter auf dem MQTT-Broker abonniert. Das Beispiel zeigt, wie ein Themenfilter abonniert wird, aber es ist möglich, eine Liste von Themenfiltern in demselben Abonnement-API-Aufruf zu übergeben, um mehr als einen Themenfilter zu abonnieren. Falls der MQTT-Broker die Abonnementanfrage ablehnt, versucht das Abonnement außerdem erneut, mit exponentiellem Backoff, für. `RETRY_MAX_ATTEMPTS` ## So veröffentlichen Sie in einem Thema Die [MQTTPublishToTopicprv-Funktion](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L972-L1004) demonstriert, wie Sie zu einem Thema auf dem MQTT-Broker veröffentlichen. ## Empfangen eingehender Nachrichten Die Anwendung registriert eine Rückruffunktion für Ereignisse, bevor sie eine Verbindung zum Broker herstellt, wie zuvor beschrieben. Die `prvMQTTDemoTask` Funktion ruft die `MQTT_ProcessLoop` Funktion auf, um eingehende Nachrichten zu empfangen. Wenn eine eingehende MQTT-Nachricht empfangen wird, ruft sie die von der Anwendung registrierte Event-Callback-Funktion auf. Die [ prvEventCallback](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L1139-L1154)Funktion ist ein Beispiel für eine solche Event-Callback-Funktion. `prvEventCallback`untersucht den Typ des eingehenden Pakets und ruft den entsprechenden Handler auf. Im folgenden Beispiel ruft die Funktion entweder die Verarbeitung `prvMQTTProcessIncomingPublish()` eingehender Veröffentlichungsnachrichten oder die Verarbeitung von Bestätigungen (ACK) `prvMQTTProcessResponse()` auf. ## Verarbeitung eingehender MQTT-Veröffentlichungspakete Die MQTTProcess IncomingPublish Funktion [prv](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L1108-L1135) demonstriert, wie ein vom MQTT-Broker veröffentlichtes Paket verarbeitet wird. ## Abmeldung von einem Thema Der letzte Schritt im Workflow besteht darin, das Abonnement des Themas zu kündigen, sodass der Broker keine veröffentlichten Nachrichten von sendet. `mqttexampleTOPIC` Hier ist die Definition der Funktion [prv MQTTUnsubscribe FromTopic](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT/mqtt_demo_mutual_auth.c#L1007-L1043). ## Änderung der in der Demo verwendeten Root-CA Standardmäßig verwenden die FreeRTOS-Demos das Amazon Root CA 1-Zertifikat (RSA 2048-Bit-Schlüssel), um sich beim Server zu authentifizieren. AWS IoT Core Es ist möglich, andere [CA-Zertifikate für die Serverauthentifizierung](https://docs.aws.amazon.com/iot/latest/developerguide/server-authentication.html#server-authentication-certs) zu verwenden, einschließlich des Amazon Root CA 3-Zertifikats (ECC 256-Bit-Schlüssel). Um die Root-CA für die Demo zur gegenseitigen CoreMQTT-Authentifizierung zu ändern: 1. Öffnen Sie die Datei `freertos/vendors/vendor/boards/board/aws_demos/config_files/mqtt_demo_mutual_auth_config.h` in einem Texteditor. 1. Suchen Sie in der Datei nach der folgenden Zeile. ``` * #define democonfigROOT_CA_PEM "...insert here..." ``` Entfernen Sie den Kommentar zu dieser Zeile und verschieben Sie sie gegebenenfalls über das Ende ` */` des Kommentarblocks hinaus. 1. Kopieren Sie das CA-Zertifikat, das Sie verwenden möchten, und fügen Sie es dann in den `"...insert here..."` Text ein. Das Ergebnis sollte wie folgt aussehen: ``` #define democonfigROOT_CA_PEM "-----BEGIN CERTIFICATE-----\n"\ "MIIBtjCCAVugAwIBAgITBmyf1XSXNmY/Owua2eiedgPySjAKBggqhkjOPQQDAjA5\n"\ "MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6b24g\n"\ "Um9vdCBDQSAzMB4XDTE1MDUyNjAwMDAwMFoXDTQwMDUyNjAwMDAwMFowOTELMAkG\n"\ "A1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJvb3Qg\n"\ "Q0EgMzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCmXp8ZBf8ANm+gBG1bG8lKl\n"\ "ui2yEujSLtf6ycXYqm0fc4E7O5hrOXwzpcVOho6AF2hiRVd9RFgdszflZwjrZt6j\n"\ "QjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSr\n"\ "ttvXBp43rDCGB5Fwx5zEGbF4wDAKBggqhkjOPQQDAgNJADBGAiEA4IWSoxe3jfkr\n"\ "BqWTrBqYaGFy+uGh0PsceGCmQ5nFuMQCIQCcAu/xlJyzlvnrxir4tiz+OpAUFteM\n"\ "YyRIHN8wfdVoOw==\n"\ "-----END CERTIFICATE-----\n" ``` 1. (Optional) Sie können die Stammzertifizierungsstelle für andere Demos ändern. Wiederholen Sie die Schritte 1 bis 3 für jede `freertos/vendors/vendor/boards/board/aws_demos/config_files/demo-name_config.h` Datei. # Demo zur gemeinsamen Nutzung von CoreMQTT-Agenten **Wichtig** Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie [hier beginnen](freertos-getting-started-modular.md), wenn Sie ein neues Projekt erstellen. Wenn Sie bereits ein vorhandenes FreeRTOS-Projekt haben, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, finden Sie weitere Informationen unter. [Leitfaden zur Migration des Amazon-FreerTOS Github-Repositorys](github-repo-migration.md) ## Einführung Das Demo-Projekt CoreMQTT Connection Sharing zeigt Ihnen, wie Sie mit einer Multithread-Anwendung eine Verbindung zum AWS MQTT-Broker mithilfe von TLS mit gegenseitiger Authentifizierung zwischen dem Client und dem Server herstellen können. [Diese Demo verwendet eine MbedTLS-basierte Transportschnittstellenimplementierung, um eine server- und clientauthentifizierte TLS-Verbindung herzustellen, und demonstriert den Subscribe-Publish-Workflow von MQTT auf QoS 1-Ebene.](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#_Toc442180914) Die Demo abonniert einen Themenfilter, veröffentlicht Themen, die dem Filter entsprechen, und wartet dann auf den Empfang dieser Nachrichten vom Server auf QoS 1-Ebene. Dieser Zyklus, bei dem die Veröffentlichung auf dem Broker und die gleiche Nachricht vom Broker zurückgesendet wird, wird für jede erstellte Aufgabe mehrmals wiederholt. Nachrichten in dieser Demo werden mit QoS 1 gesendet, was mindestens eine Lieferung gemäß der MQTT-Spezifikation garantiert. **Anmerkung** Folgen Sie den Schritten unter, um die FreeRTOS-Demos einzurichten und auszuführen. [Erste Schritte mit FreeRTOS](freertos-getting-started.md) Diese Demo verwendet eine Thread-sichere Warteschlange, in der Befehle für die Interaktion mit der MQTT-API gespeichert werden. In dieser Demo gibt es zwei Aufgaben, die Sie beachten sollten. + Eine (Haupt-) Aufgabe des MQTT-Agenten verarbeitet die Befehle aus der Befehlswarteschlange, während andere Aufgaben sie in die Warteschlange einreihen. Diese Aufgabe tritt in eine Schleife ein, in der sie Befehle aus der Befehlswarteschlange verarbeitet. Wenn ein Terminierungsbefehl eingeht, wird diese Aufgabe aus der Schleife ausbrechen. + Eine Demo-Subpub-Aufgabe erstellt ein Abonnement für ein MQTT-Thema, erstellt dann Veröffentlichungsvorgänge und schiebt sie in die Befehlswarteschlange. Diese Veröffentlichungsvorgänge werden dann von der MQTT-Agent-Aufgabe ausgeführt. Die Demo-Subpub-Aufgabe wartet, bis die Veröffentlichung abgeschlossen ist, was durch die Ausführung des Callbacks zur Befehlsvervollständigung angezeigt wird, und gibt dann eine kurze Verzögerung ein, bevor sie mit der nächsten Veröffentlichung beginnt. Diese Aufgabe zeigt Beispiele dafür, wie Anwendungsaufgaben die CoreMQTT-Agenten-API verwenden würden. Für eingehende Veröffentlichungsnachrichten ruft der CoreMQTT-Agent eine einzige Callback-Funktion auf. Diese Demo beinhaltet auch einen Abonnement-Manager, der es Aufgaben ermöglicht, einen Callback anzugeben, der für eingehende Veröffentlichungsnachrichten zu Themen aufgerufen werden soll, die sie abonniert haben. Der eingehende Veröffentlichungsrückruf des Agenten in dieser Demo ruft den Abonnementmanager auf, um Veröffentlichungen für alle Aufgaben, für die ein Abonnement registriert wurde, aufzufächern. In dieser Demo wird eine TLS-Verbindung mit gegenseitiger Authentifizierung für die Verbindung verwendet. AWS Wenn das Netzwerk während der Demo unerwartet unterbrochen wird, versucht der Client, mithilfe der exponentiellen Backoff-Logik erneut eine Verbindung herzustellen. Wenn der Client die Verbindung erfolgreich wiederherstellt, der Broker die vorherige Sitzung jedoch nicht fortsetzen kann, abonniert der Client dieselben Themen wie in der vorherigen Sitzung erneut. ### Single-Threading oder Multithreading-fähig Es gibt zwei CoreMQTT-Nutzungsmodelle: Singlethread und Multithread (Multitasking). Das Single-Thread-Modell verwendet die CoreMQTT-Bibliothek ausschließlich von einem Thread aus und erfordert, dass Sie wiederholte explizite Aufrufe in der MQTT-Bibliothek tätigen. Multithread-Anwendungsfälle können stattdessen das MQTT-Protokoll im Hintergrund innerhalb einer Agenten- (oder Daemon-) Aufgabe ausführen, wie in der hier dokumentierten Demo gezeigt. Wenn Sie das MQTT-Protokoll in einer Agententask ausführen, müssen Sie keinen MQTT-Status explizit verwalten oder die API-Funktion aufrufen. `MQTT_ProcessLoop` Wenn Sie eine Agententask verwenden, können sich außerdem mehrere Anwendungsaufgaben eine einzige MQTT-Verbindung teilen, ohne dass Synchronisationsprimitive wie Mutexe erforderlich sind. ## Quellcode Die Demo-Quelldateien sind benannt `mqtt_agent_task.c` `simple_sub_pub_demo.c` und befinden sich im `freertos/demos/coreMQTT_Agent/` Verzeichnis und auf der Website. [GitHub](https://github.com/aws/amazon-freertos/tree/main/demos/coreMQTT_Agent/) ## Funktionalität Diese Demo erstellt mindestens zwei Aufgaben: eine primäre, die Anfragen für MQTT-API-Aufrufe verarbeitet, und eine konfigurierbare Anzahl von Unteraufgaben, die diese Anfragen erstellen. In dieser Demo erstellt die Hauptaufgabe die Unteraufgaben, ruft die Verarbeitungsschleife auf und bereinigt sie anschließend. Die Hauptaufgabe erstellt eine einzelne MQTT-Verbindung zum Broker, die von den Unteraufgaben gemeinsam genutzt wird. Die Unteraufgaben erstellen ein MQTT-Abonnement beim Broker und veröffentlichen dann Nachrichten an diesen. Jede Unteraufgabe verwendet ein eigenes Thema für ihre Veröffentlichungen. ## Hauptaufgabe Die Hauptaufgabe der Anwendung, [ RunCoreMQTTAgentDemo](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT_Agent/mqtt_agent_task.c#L435-L480), richtet eine MQTT-Sitzung ein, erstellt die Unteraufgaben und führt die Verarbeitungsschleife [ MQTTAgent\$1](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT_Agent/mqtt_agent_task.c#L856) aus, CommandLoop bis ein Abschlussbefehl empfangen wird. Wenn das Netzwerk unerwartet unterbrochen wird, stellt die Demo im Hintergrund wieder eine Verbindung zum Broker her und stellt die Abonnements beim Broker wieder her. Nachdem die Verarbeitungsschleife beendet wurde, wird die Verbindung zum Broker getrennt. ### Befehle Wenn Sie eine CoreMQTT-Agenten-API aufrufen, erstellt sie einen Befehl, der an die Warteschlange der Agentenaufgabe gesendet wird, in der sie verarbeitet wird. `MQTTAgent_CommandLoop()` Zum Zeitpunkt der Erstellung des Befehls können optionale Callback- und Kontextparameter für die Fertigstellung übergeben werden. Sobald der entsprechende Befehl abgeschlossen ist, wird der Abschluss-Callback mit dem übergebenen Kontext und allen Rückgabewerten, die als Ergebnis des Befehls erstellt wurden, aufgerufen. Die Signatur für den Abschluss-Callback lautet wie folgt: ``` typedef void (* MQTTAgentCommandCallback_t )( void * pCmdCallbackContext, MQTTAgentReturnInfo_t * pReturnInfo ); ``` [Der Kontext der Befehlsvervollständigung ist benutzerdefiniert; für diese Demo lautet er: struct. MQTTAgent CommandContext](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT_Agent/simple_sub_pub_demo.c#L105-L115) Befehle gelten als abgeschlossen, wenn: + Abonniert, kündigt und veröffentlicht mit QoS > 0: Sobald das entsprechende Bestätigungspaket empfangen wurde. + Alle anderen Operationen: Sobald die entsprechende CoreMQTT-API aufgerufen wurde. Alle vom Befehl verwendeten Strukturen, einschließlich Veröffentlichungsinformationen, Abonnementinformationen und Abschlusskontexten, müssen im Gültigkeitsbereich bleiben, bis der Befehl abgeschlossen ist. Eine aufrufende Aufgabe darf keine der Strukturen eines Befehls wiederverwenden, bevor der Abschluss-Callback aufgerufen wurde. Beachten Sie, dass der Completion-Callback, da er vom MQTT-Agenten aufgerufen wird, im Thread-Kontext der Agentenaufgabe ausgeführt wird, nicht mit der Aufgabe, die den Befehl erstellt hat. Prozessübergreifende Kommunikationsmechanismen, wie Aufgabenbenachrichtigungen oder Warteschlangen, können verwendet werden, um der aufrufenden Aufgabe zu signalisieren, dass der Befehl abgeschlossen ist. ### Die Befehlsschleife ausführen Befehle werden kontinuierlich in verarbeitet`MQTTAgent_CommandLoop()`. Wenn es keine Befehle gibt, die verarbeitet werden müssen, wartet die Schleife, bis maximal einer `MQTT_AGENT_MAX_EVENT_QUEUE_WAIT_TIME` zur Warteschlange hinzugefügt wird, und wenn kein Befehl hinzugefügt wird, wird eine einzelne Iteration von `MQTT_ProcessLoop()` ausgeführt. Dadurch wird sichergestellt, dass MQTT Keep-Alive verwaltet wird und dass alle eingehenden Veröffentlichungen auch dann empfangen werden, wenn sich keine Befehle in der Warteschlange befinden. Die Befehlsschleifenfunktion wird aus den folgenden Gründen zurückkehren: + Ein Befehl gibt außerdem einen beliebigen Statuscode zurück`MQTTSuccess`. Der Fehlerstatus wird von der Befehlsschleife zurückgegeben, sodass Sie entscheiden können, wie Sie damit umgehen möchten. In dieser Demo wird die TCP-Verbindung wieder hergestellt und es wird versucht, die Verbindung wiederherzustellen. Wenn ein Fehler auftritt, kann eine Wiederverbindung im Hintergrund erfolgen, ohne dass andere Aufgaben, die MQTT verwenden, eingreifen müssen. + Ein Befehl zum Trennen der Verbindung (von`MQTTAgent_Disconnect`) wird verarbeitet. Die Befehlsschleife wird beendet, sodass die TCP-Verbindung getrennt werden kann. + Ein Terminierungsbefehl (von`MQTTAgent_Terminate`) wird verarbeitet. Dieser Befehl markiert außerdem jeden Befehl, der sich noch in der Warteschlange befindet oder auf ein Bestätigungspaket wartet, als Fehler mit dem Rückgabecode. `MQTTRecvFailed` ### Abonnement-Manager Da die Demo mehrere Themen verwendet, ist ein Abonnement-Manager eine bequeme Möglichkeit, abonnierte Themen mit eindeutigen Rückrufen oder Aufgaben zu verknüpfen. Der Abonnementmanager in dieser Demo ist Single-Thread-fähig und sollte daher nicht von mehreren Aufgaben gleichzeitig verwendet werden. In dieser Demo werden Abonnement-Manager-Funktionen nur von Callback-Funktionen aufgerufen, die an den MQTT-Agenten übergeben werden, und nur im Thread-Kontext der Agentenaufgabe ausgeführt. ## Einfache Aufgabe zum Abonnieren und Veröffentlichen Jede Instanz von [ prvSimpleSubscribePublishTask](https://github.com/aws/amazon-freertos/blob/main/demos/coreMQTT_Agent/simple_sub_pub_demo.c#L447-L569)erstellt ein Abonnement für ein MQTT-Thema und erstellt Veröffentlichungsvorgänge für dieses Thema. Um mehrere Veröffentlichungstypen zu demonstrieren, verwenden gerade nummerierte Aufgaben QoS 0 (die abgeschlossen sind, sobald das Veröffentlichungspaket gesendet wurde) und ungerade Aufgaben verwenden QoS 1 (die nach Erhalt eines PUBACK-Pakets abgeschlossen sind).