Listener-Port: Portnummer, auf der gelauscht werden soll, ist erforderlich. Wenn diese Variable verwendet wird und kein Port angegeben wird, wird der Standard-Listener nicht gestartet.
Die Standardeinstellung für
FactoryTalk Optix
ist eine allgemeine Konfiguration mit einem Port, an dem gelauscht wird.
Maximale Verbindungen: Maximale Anzahl an zulässigen Clientverbindungen, ausgedrückt als Ganzzahl, bis zu 25.
Maximale Anzahl an In-Flight-Meldungen: Die maximal pro Client übertragene Anzahl an QoS 1- und QoS 2-Meldungen (Quality of Service). Dazu gehören auch Meldungen, die sich im Handshake befinden und wiederholt werden. Wenn dieser Wert auf 0 gesetzt wird, gibt es keine Obergrenze für diese Meldungen. Wenn dieser Wert auf 1 gesetzt wird, wird die Zustellung von QoS 1- und QoS 2-Meldungen in der richtigen Reihenfolge gewährleistet.
Maximale QoS: Legt die maximal unterstützte QoS fest. Die mit einer höheren als die hier angegebene QoS veröffentlichenden Clients werden getrennt.
Maximale Anzahl an Meldungen in der Warteschlange: Die maximale Anzahl an QoS-1- und QoS-2-Meldungen pro Client in der Warteschlange, ausgenommen der sich derzeit in Übertragung befindlichen Meldungen (d. h. die Meldungen, die gerade vom Broker verarbeitet werden). Es wird empfohlen, eine maximale Anzahl (größer als 0) von Meldungen in der Warteschlange festzulegen.
Grenzwert für Meldungsgröße: Die maximal zulässige Größe der Meldungen für den Broker. Wenn empfangene Meldungen diese Größe überschreiten, werden sie vom Broker abgewiesen. Wenn Sie diesen Wert auf 0 setzen, werden alle gültigen MQTT-Meldungen ohne Größenbeschränkung akzeptiert. MQTT begrenzt jedoch die tatsächlich maximal zulässige Größe auf 268.435.455 Byte.
Verfügbare beibehalten: Um die Unterstützung für beibehaltene Meldungen zu deaktivieren, legen Sie für diesen Wert
Falsch
fest. Wenn ein Client eine Meldung mit gesetztem Beibehaltungs-Bit veröffentlicht, wird seine Verbindung getrennt, wenn die Unterstützung hierfür deaktiviert wurde.
Anonyme Authentifizierung: Wenn auf
Falsch
gesetzt, ist eine Authentifizierung mit dem Benutzerpasswort erforderlich. Wenn auf
Wahr
gesetzt, ist keine Authentifizierung mit dem Benutzerpasswort erforderlich.
Clientzertifikat anfordern: Standardmäßig funktioniert ein TLS-fähiger Listener wie ein HTTPS-fähiger Webserver: Der Server verwendet ein Zertifikat, das von einer Zertifizierungsstelle (ZS) signiert wurde, und der Client überprüft, ob es sich um ein vertrauenswürdiges Zertifikat handelt. Das übergeordnete Ziel ist die Verschlüsselung des Netzwerkverkehrs. Wenn Sie
require_certificate
auf "Wahr" setzen, muss der Client ein gültiges Zertifikat bereitstellen, um eine Verbindung mit dem Netzwerk herzustellen. Dadurch kann der Zugriff auf den Broker außerhalb der von MQTT bereitgestellten Mechanismen gesteuert werden.
ZS-Zertifikatdatei: Definiert den Pfad zu der Datei, die ZS-Zertifikate enthält. Diese Zertifikate werden bei der Überprüfung der eingehender Client-Zertifikate als vertrauenswürdig eingestuft. Bei einer ZS-Kette wird bei
cpath
davon ausgegangen, dass dieser als
\ProjectFiles\PKI\Own\Certs
hartkodiert ist.
Broker-Zertifikatdatei: Pfad zum PEM-codierten Serverzertifikat.
Private Schlüsseldatei des Brokers: Pfad zur PEM-codierten Schlüsseldatei.

In der

Projektansicht

wird jetzt im Ordner

MQTT

das konfigurierte MQTT-Broker-Objekt angezeigt.

MQTT-Broker

MQTT-Benutzer hinzufügen

Rückmeldung geben

Haben Sie Fragen oder Feedback zu dieser Dokumentation? Bitte geben Sie hier Ihr Feedback ab.