Negieren Protokolle, die auf dem Publish-Subscribe-Muster basieren, die Vorteile von Mesh-Netzwerken?

Protokolle, die dem Publish-Subscribe-Muster wie MQTT und AMQP nachempfunden sind, erfordern einen zentralen Nachrichtenbroker, um das Senden und Empfangen von Nachrichten zu koordinieren. Dies ist kein großes Problem, wenn Ihr IoT-Netzwerk auf einer Sterntopologie basiert, bei der alle Nachrichten ohnehin über einen zentralen Hub gesendet werden müssen. Ich habe jedoch über die Vorteile von Mesh-Netzwerken nachgedacht und darüber, wie diese beeinflusst werden können Protokollauswahl.

In der Präsentation zur Thread-Einführung werden insbesondere einige Vorteile des Mesh-Netzwerks von Thread beschrieben (diese sollten jedoch allgemein gelten):

✔ Keine einzelne Fehlerstelle

✔ Selbstheilung

✔ Robustheit der Interferenz

✔ Selbstverlängernd

✔ Zuverlässig genug für kritische Infrastrukturen

Obwohl ich mir nicht vorstellen kann, dass die letzten vier Punkte von der Protokollauswahl betroffen sind, bin ich gespannt, ob die Verwendung eines durch Nachrichten vermittelten Protokolls die Vorteile des "No Single Point of Failure" des Mesh-Netzwerks aufheben würde.

Führt die Verwendung eines auf Publish-Subscribe basierenden Protokolls im Allgemeinen zu einem unvermeidlichen Single Point of Failure, und schlägt die Präsentation zur Thread-Einführung aus diesem Grund stattdessen CoAP als potenzielles Protokoll vor?

^{Ich habe bereits gefragt, ob Mosquitto mehrere Broker unterstützt, um den einzelnen Fehlerpunkt zu beseitigen, aber ich möchte fragen, ob dies ein grundlegender Konflikt zwischen Mesh-Netzwerken und Publish-Subscribe-Protokollen ist.}

Ja und nein.

Beide Technologien betreffen unterschiedliche Ebenen der Bereitstellung von Konnektivität. In der Regel wird die Mesh-Vernetzung je nach Umfang der Implementierung von Level 3 oder 4 oder sogar von beiden des ISO OSI-Modells bereitgestellt . Die Netzwerk- und Transportschichten bieten die grundlegende Zuverlässigkeit des Maschennetzwerks. Diese Zuverlässigkeit wird normalerweise nicht beeinträchtigt, wenn ein Knoten abfällt.

MQTT und AMQP sind Protokolle der Anwendungsschicht auf Ebene 7. Daher sind diese Protokolle in Bezug auf das Basismodell von der Zuverlässigkeit der unteren Ebenen abhängig. Es ist jedoch immer das Vorrecht höherer OSI-Ebenen, Schutzmaßnahmen zu implementieren, um Ausfälle der niedrigeren Ebenen zu bewältigen. Beispielsweise kann die Anwendung zu einem völlig anderen Netzwerk wechseln, z. B. von Wi-Fi zu 4G, wenn ein Netzwerkfehler erkannt wird. Smartphones tun dies die ganze Zeit, wenn wir einen Ort mit einem konfigurierten WLAN betreten oder verlassen.

Es gibt auch Möglichkeiten für die unteren Ebenen, Fehler in den oberen Ebenen auszugleichen. Der Lastausgleich auf OSI-Ebene 4 kann beispielsweise fehlerhafte Knoten dahinter berücksichtigen. Dies erfordert natürlich, dass jeder Knoten, der für Lastausgleichs- und / oder Failover-Lösungen adressiert werden kann, denselben Service bereitstellen kann. Natürlich benötigen Sie die zentrale Komponente mindestens zweimal. Da MQTT im Grunde ein Routing auf Anwendungsebene ist, das auf Themen basiert, die durch einfaches Duplizieren möglich sein sollten. Dies ist ein Beispiel für eine MQTT- Clusterlösung mit der HiveMQ-Implementierung.

In diesem Sinne kann gefolgert werden , dass, keine , die Zuverlässigkeit im Netzwerk und Transportebenen kann nicht durch die Wahl eines höheren Protokolls negiert werden. Dies gilt jedoch nicht für die Benutzererfahrung. Für den Benutzer sind die Protokolle der unteren Ebene nur Fahrzeuge. Unter Verwendung eines Anwendungsschicht - Protokoll , das einen Single Point of Failure noch Mittel hat, dass , wenn dieser Knoten gebrochen ist, dann ja , wird die Funktionalität gebrochen , obwohl mein Netzwerk noch funktioniert.

Auf jeden Fall sind die Anwendungsschicht und höher dafür verantwortlich, dem Benutzer die Zuverlässigkeit zu bieten. Mesh-Netzwerke können nur die Grundlagen liefern.

Es gibt noch eine letzte Sache zu beachten. Sofern nicht für jede Komponente Redundanzen vorhanden sind, gibt es immer Anwendungsfälle mit einzelnen Fehlerquellen. Es ist höchstwahrscheinlich der Knoten, mit dem der Benutzer tatsächlich interagiert. In der Heimautomation zum Beispiel bedeutet jeder fehlerhafte Knoten sehr wahrscheinlich, dass man gerade einen Anwendungsfall verloren hat.