Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Demo zur gemeinsamen Nutzung von CoreMatt-Agent-Verbindungen - Kostenlos RTOS

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.

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.

Demo zur gemeinsamen Nutzung von CoreMatt-Agent-Verbindungen

Wichtig

Diese Demo wird im Amazon-FreeRTOS-Repository gehostet, das veraltet ist. Wir empfehlen, dass Sie hier beginnen, wenn Sie ein neues Projekt erstellen. Wenn Sie bereits über ein bestehendes FreeRTOS-Projekt verfügen, das auf dem inzwischen veralteten Amazon-FreeRTOS-Repository basiert, lesen Sie dieLeitfaden zur Migration des kostenlosen RTOS Github-Repositorys von Amazon.

Einführung

Das Demoprojekt CoreMQTT Connection Sharing zeigt Ihnen, wie Sie mithilfe einer Multithread-Anwendung eine Verbindung zumAWS MQTT-Broker mithilfe von TLS mit gegenseitiger Authentifizierung zwischen dem Client und dem Server herstellen. Diese Demo verwendet eine MbedTLS-basierte Transportschnittstellenimplementierung, um eine Server- und Client-authentifizierte TLS-Verbindung herzustellen, und demonstriert den Subscribe-Publishing-Workflow von MQTT auf der QoS-1-Ebene. Die Demo abonniert einen Themenfilter, veröffentlicht Themen, die dem Filter entsprechen, und wartet dann darauf, dass diese Nachrichten vom Server auf der QoS 1-Ebene zurückgesendet werden. Dieser Zyklus des Publizierens beim Broker und des Empfangens derselben Nachricht vom Broker wird für jede erstellte Aufgabe mehrmals wiederholt. Die Nachrichten in dieser Demo werden mit QoS 1 gesendet, was mindestens eine Zustellung gemäß der MQTT-Spezifikation garantiert.

Anmerkung

Um die FreeRTOS-Demos einzurichten und auszuführen, folgen Sie den Schritten unterJetzt kostenlos durchstarten RTOS.

Diese Demo verwendet eine Thread-sichere Warteschlange, um Befehle zur Interaktion mit der MQTT-API zu speichern. In dieser Demo sind zwei Aufgaben zu beachten.

  • Eine (Haupt-) Aufgabe des MQTT-Agenten verarbeitet die Befehle aus der Befehlswarteschlange, während andere Aufgaben sie in die Warteschlange stellen. Diese Aufgabe tritt in eine Schleife ein, in der sie Befehle aus der Befehlswarteschlange verarbeitet. Wenn ein Terminierungsbefehl empfangen wird, bricht diese Aufgabe aus der Schleife.

  • Eine Demo-Subpub-Aufgabe erstellt ein Abonnement für ein MQTT-Thema, erstellt dann Veröffentlichungsoperationen und schiebt sie in die Befehlswarteschlange. Diese Veröffentlichungsoperationen werden dann von der MQTT-Agent-Task ausgeführt. Die Demo-Subpub-Aufgabe wartet auf den Abschluss der Veröffentlichung, was durch die Ausführung des Callbacks zur Befehlsabfertigung angezeigt wird, und tritt dann in eine kurze Verzögerung ein, bevor sie mit der nächsten Veröffentlichung beginnt. Diese Aufgabe zeigt Beispiele dafür, wie Anwendungsaufgaben die CoreMQTT Agent-API verwenden würden.

Für eingehende Veröffentlichungsnachrichten ruft der CoreMQTT-Agent eine einzelne Callback-Funktion auf. Diese Demo enthält auch einen Abonnementmanager, mit dem Aufgaben einen Callback angeben können, der für eingehende Veröffentlichungsnachrichten zu Themen, die sie abonniert haben, aufgerufen wird. Der eingehende Veröffentlichungs-Callback des Agenten in dieser Demo ruft den Abonnementmanager auf, Veröffentlichungen für jede Aufgabe zu fächern, für die ein Abonnement registriert wurde.

Diese Demo verwendet eine TLS-Verbindung mit gegenseitiger Authentifizierung, um eine Verbindung herzustellenAWS. Wenn das Netzwerk während der Demo unerwartet unterbrochen wird, versucht der Client, die Verbindung mithilfe der exponentiellen Backoff-Logik wiederherzustellen. Wenn der Client die Verbindung erfolgreich wiederherstellt, der Broker die vorherige Sitzung jedoch nicht fortsetzen kann, abonniert der Client erneut dieselben Themen wie die vorherige Sitzung.

Single-Threading gegen Multithreading

Es gibt zwei CoreMQTT-Nutzungsmodelle: Single Threading 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. In Multithread-Anwendungsfällen kann das MQTT-Protokoll stattdessen im Hintergrund innerhalb einer Agent- (oder Daemon-) Aufgabe ausgeführt werden, wie in der hier dokumentierten Demo gezeigt. Wenn Sie das MQTT-Protokoll in einer Agentenaufgabe ausführen, müssen Sie keinen MQTT-Status explizit verwalten oder dieMQTT_ProcessLoop API-Funktion aufrufen. Wenn Sie eine Agentenaufgabe verwenden, können sich mehrere Anwendungsaufgaben außerdem eine einzige MQTT-Verbindung teilen, ohne dass Synchronisationsprimitive wie Mutexe erforderlich sind.

Quellcode

Die Demo-Quelldateien sind benanntmqtt_agent_task.csimple_sub_pub_demo.c und befinden sich imfreertos/demos/coreMQTT_Agent/ Verzeichnis und GitHubauf der Website.

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 danach. Die primäre Aufgabe erstellt eine einzelne MQTT-Verbindung zum Broker, die von den Unteraufgaben gemeinsam genutzt wird. Die Unteraufgaben erstellen ein MQTT-Abonnement mit dem Broker und veröffentlichen dann Nachrichten an diesen. Jede Unteraufgabe verwendet ein eindeutiges Thema für ihre Veröffentlichungen.

Hauptaufgabe

Die Hauptanwendungsaufgabe, RunCoreMQTTAgentDemo, richtet eine MQTT-Sitzung ein, erstellt die Unteraufgaben und führt die Verarbeitungsschleife MQTTAgent_ aus,CommandLoop bis ein Terminierungsbefehl empfangen wird. Wenn das Netzwerk unerwartet unterbrochen wird, stellt die Demo im Hintergrund erneut eine Verbindung zum Broker her und stellt die Abonnements beim Broker erneut her. Nach Beendigung der Verarbeitungsschleife wird die Verbindung zum Broker getrennt.

Befehle

Wenn Sie eine CoreMQTT-Agent-API aufrufen, erstellt sie einen Befehl, der an die Warteschlange der Agentenaufgabe gesendet wird, in der sie verarbeitet wirdMQTTAgent_CommandLoop(). Zum Zeitpunkt der Erstellung des Befehls können optionale Abschluss-Callback- und Kontextparameter übergeben werden. Sobald der entsprechende Befehl abgeschlossen ist, wird der Abschluss-Callback mit dem übergebenen Kontext und allen Rückgabewerten aufgerufen, die als Ergebnis des Befehls erstellt wurden. 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 MQTTAgentCommandContext.

Befehle gelten als abgeschlossen, wenn:

  • Abonniert, meldet sich ab und veröffentlicht mit QoS > 0: Sobald das entsprechende Bestätigungs-Paket 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 solange gültig bleiben, bis der Befehl abgeschlossen ist. Eine aufrufende Aufgabe darf vor dem Aufruf des Abschluss-Callbacks keine der Strukturen eines Befehls wiederverwenden. Beachten Sie, dass der Abschluss-Callback, da er vom MQTT-Agenten aufgerufen wird, mit dem Thread-Kontext der Agentenaufgabe ausgeführt wird, nicht mit der Aufgabe, die den Befehl erstellt hat. Kommunikationsmechanismen zwischen Prozessen, wie z. B. Aufgabenbenachrichtigungen oder Warteschlangen, können verwendet werden, um der aufrufenden Aufgabe den Abschluss eines Befehls zu signalisieren.

Befehlsschleife ausführen

Befehle werden kontinuierlich in verarbeitetMQTTAgent_CommandLoop(). Wenn keine Befehle verarbeitet werden müssen, wartet die Schleife, bis maximal einerMQTT_AGENT_MAX_EVENT_QUEUE_WAIT_TIME zur Warteschlange hinzugefügt wird, und wenn kein Befehl hinzugefügt wird, führt sie eine einzelne Iteration von ausMQTT_ProcessLoop(). Dadurch wird sichergestellt, dass MQTT Keep-Alive verwaltet wird und dass alle eingehenden Veröffentlichungen empfangen werden, auch 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ückMQTTSuccess. 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 erneut hergestellt, und es wird ein erneuter Verbindungsversuch unternommen. Wenn ein Fehler auftritt, kann eine Wiederverbindung im Hintergrund erfolgen, ohne dass andere Aufgaben mit MQTT eingreifen müssen.

  • Ein Trenn-Befehl (vonMQTTAgent_Disconnect) wird verarbeitet. Die Befehlsschleife wird beendet, sodass die TCP-Verbindung getrennt werden kann.

  • Ein Termine-Befehl (vonMQTTAgent_Terminate) wird verarbeitet. Dieser Befehl markiert auch jeden Befehl, der sich noch in der Warteschlange befindet oder auf ein Bestätigungspaket wartet, als Fehler mit dem Rückgabecode vonMQTTRecvFailed.

Abonnementverwaltung

Da die Demo mehrere Themen verwendet, ist ein Abonnementmanager eine bequeme Möglichkeit, abonnierte Themen mit eindeutigen Rückrufen oder Aufgaben zu verknüpfen. Der Abonnementmanager in dieser Demo ist Singlethread-fähig und sollte daher nicht für mehrere Aufgaben gleichzeitig verwendet werden. In dieser Demo werden Abonnement-Manager-Funktionen nur von Callback-Funktionen aufgerufen, die an den MQTT-Agenten übergeben werden, und sie werden nur mit dem Thread-Kontext der Agentenaufgabe ausgeführt.

Einfache Aufgabe zum Abonnieren und Veröffentlichen

Jede Instanz von prvSimpleSubscribePublishTaskerstellt ein Abonnement für ein MQTT-Thema und erstellt Veröffentlichungsoperationen 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).

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.