Ich habe über XMPP als potenzielles Kommunikationsprotokoll für IoT-Geräte gelesen, aber nachdem ich eine Quelle gelesen habe, bin ich mir nicht sicher, ob es wirklich ein geeignetes Protokoll ist, wenn Sie sich Gedanken über den Overhead für jede Nachricht machen.
Diese Quelle besagt:
XMPP weist jedoch eine Reihe von Problemen auf, die es für EINGEBETTETE IOT-PROTOKOLLE etwas unerwünscht machen. Als XML-basiertes Protokoll ist XMPP sehr ausführlich, noch mehr als HTTP, und hat einen hohen Datenaufwand. Ein einzelner Anforderungs- / Antwortaustausch zum Senden eines Datenbytes von einem IOT CONNECTED DEVICE an den Server beträgt mehr als 0,5 kB.
Es gibt einen Entwurf einer Spezifikation, die XMPP mithilfe einer XML-Codierung komprimieren würde, die als effizienter XML-Austausch (EXI) bezeichnet wird. Aber selbst mit EXI erhält dasselbe Datenbyte allein von XMPP Hunderte von Bytes Protokoll-Overhead. EXI ist auch ein viel schwieriger zu verarbeitendes Format als andere derzeit verfügbare Optionen. Aufgrund dieser inhärenten Probleme wird generell empfohlen, die Verwendung von XMPP in eingebetteten IoT-Anwendungen zu vermeiden.
XMPP bewirbt sich jedoch als geeignet für IoT-Anwendungen (obwohl es nicht ausdrücklich besagt, dass es einen geringen Overhead hat), so dass es seltsam erscheint, dass ein so großes, scheinbar ausführliches Protokoll für IoT-Geräte empfohlen / beworben wird.
Ist der Overhead von XMPP wirklich so groß, wie die Quelle für kleine Datenmengen vorschlägt? Wie viel Overhead würde beispielsweise beim Senden einer 8-Byte-Nachricht anfallen?
Ist der Overhead auch so groß, wenn die EXI- Komprimierung verwendet wird (wie in der Quelle erwähnt)? Würde dies auch mit einigen Fallstricken einhergehen?
quelle
Antworten:
Es ist zwar fair zu sagen, dass XML ausführlich ist, dies sollte jedoch mit dem Bewusstsein gemildert werden, dass diese Ausführlichkeit in Bezug auf den Inhalt nicht nur "Overhead" ist, da sie die Semantik einschließt. Der Overhead ist symptomatisch für jedes Protokoll, das eine dynamische im Gegensatz zu einer statischen Struktur betont. Zum Beispiel ist HTML wirklich eine entspannte Form von XML, die Inhalte mit einer dynamischen Struktur vermittelt, die als ein Aspekt des Inhalts betrachtet werden kann. Sie können den Inhalt einer Tabelle von der Tabelle selbst unterscheiden, aber die Tatsache, dass es sich bei dem Inhalt um Tabellendaten mit bestimmten Beziehungen handelt, ist ein wesentlicher Bestandteil des Inhalts. Wenn ich nur jede Zelle genommen und alles als eine lange Zeichenfolge übertragen habe, sind diese Struktur und diese Beziehungen verschwunden, und ich habe Informationen verloren, und ist das nicht Inhalt?
Betrachten wir eine 8-Byte-Nachricht, die einige Tabluar-Daten darstellen könnte. Wenn ich ein sehr statisches Protokoll verwende, könnte ich dies ohne zusätzlichen Aufwand minimal übertragen, indem ich einfach ein Protokoll wie das folgende definiere:
Wenn alle meine Nachrichten genau so sind, kann die Verwendung von XML, HTML oder XMPP als albern angesehen werden. Ich verschwende Bandbreite für Strukturkomponenten, die ohnehin immer gleich und vorbestimmt sind, und verschwende an beiden Enden die entsprechende Rechenzeit, um sie zu erstellen und zu analysieren. Eine minimale, ordnungsgemäße HTML-Seite, die nur eine 2 x 2-Tabelle mit einigen Zeichen in jeder Zelle enthält, wird wahrscheinlich mindestens 100 Byte groß sein, um den Formatierungs- und Protokollaufwand zu berücksichtigen.
Wenn jedoch nicht alle meine Nachrichten genau das sind, ist die Angabe, um welche Art von Nachricht es sich handelt, möglicherweise kein wörtlicher Teil der "Nutzlast", aber inhaltlich eine notwendige Komponente. Ich könnte das mit nur zwei zusätzlichen Bytes tun und viel mehr Dynamik einführen:
Jetzt erfordern meine 8 Bytes Tabelleninhalt 2 Bytes Overhead, aber es gibt eine viel größere Auswahl an Möglichkeiten, welche Arten von Nachrichten mit diesem benutzerdefinierten Protokoll gesendet werden können.
Es ist immer noch weit entfernt von den Möglichkeiten einer HTML-Seite oder einer XML-Namespace- Spezifikation (oder einer Menge davon, was XMPP im Wesentlichen ist ).
Auf dieser Grundlage ist XMPP wahrscheinlich übertrieben, wenn Sie hauptsächlich einfache 8-Byte-Nachrichten senden. Allerdings nicht unbedingt so viel. Die Behauptung, dass "ein einzelner Anforderungs- / Antwortaustausch zum Senden eines Datenbytes von einem IOT CONNECTED DEVICE an den Server mehr als 0,5 kB beträgt", scheint mir bei einem Blick auf den relevanten RFC eine mögliche Übertreibung zu sein (aber nb, alles Ich habe einen Blick darauf geworfen, ich habe XMPP noch nie implementiert oder verwendet. Ich bezweifle nicht, dass Sie ein Beispiel dafür konstruieren könnten, aber das ist wahrscheinlich kein minimales Beispiel.
Da das Protokoll TCP-orientiert ist, muss das Einrichten eines "XML-Streams, der durch den Namespace 'jabber: client' qualifiziert ist" nur dann als Teil der Nachricht betrachtet werden, wenn wir einmalige Dinge tun - das Gerät kontaktiert einen Server, um 8 Bytes an zu senden, sendet Die Daten werden getrennt. Wenn die Beziehung beständiger ist, wie dies häufig in einem IoT-Kontext der Fall ist, können wir davon ausgehen, dass das Gerät bereits eine Verbindung zum Ziel hergestellt hat. In diesem Fall ist der Protokoll-Overhead möglicherweise minimal, wenn das endgültige Ziel der Nachricht der Server ist (im Gegensatz zu einem anderen Client, an den der Server die Nachricht weiterleiten wird).
Eine dürftige 33 Bytes "Overhead". Hier ist darauf hinzuweisen, dass XML Text ist. Wenn Ihre Nachrichten daher häufig binär sind, wird dies viel weniger geeignet sein, da diese Daten codiert werden müssen (z. B. in base64 ), was zusätzlichen Overhead und Rechenaufwand bedeutet Anforderungen.
Also letztendlich:
Wenn es eine dauerhafte Verbindung gibt und die Nachrichten weitgehend unstrukturiert sind, denke ich nicht. Wenn Sie jedoch nicht das benötigen, was es bietet (die Dynamik in Bezug auf die Struktur), gibt es wahrscheinlich geeignetere Methoden.
Wenn wir einen Kontext haben, in dem ein einzelner zentraler Server Nachrichten zwischen verschiedenen Geräten verarbeitet und / oder verlässt, obwohl das, was eines dieser Geräte tut, immer einfach und unkompliziert sein kann, kann ein Protokoll a Eine Vielzahl von Nachrichten wäre immer noch nützlich. Wenn ein Client-Gerät nur über begrenzte Ressourcen verfügt, können wir einen Großteil des Protokolls fest codieren, und das Umschließen jeder Nachricht von diesem Ende wird zu einer sehr einfachen Aufgabe. Ich glaube, dass viele IoT-Geräte, die HTTP-Server bereitstellen, dies tun (was das Gegenteil von "einfachen Clients, komplexen Servern" ist). Diese Server können keine Art von HTTP-Anfrage verarbeiten (außer durch vorformatierte Ablehnung) und haben eine sehr gut definierte, fokussierte Reihe von Aufgaben und Antworten, die sie senden, aber da sie dennoch korrekt als HTTP-Server funktionieren,
quelle
Zunächst sollte ich sagen, dass XML verwendet wurde, um Echtzeitnachrichten mit einigem Erfolg und in großem Umfang zu kapseln, insbesondere für die Kommunikation von IM und Präsenz in XMPP. Es scheint auch einige Unternehmen zu geben, die ihr XML-Wissen nutzen wollen, um einen weiteren Anwendungsbereich für dieses Datenrepräsentationssystem zu finden.
Allerdings ist nicht jeder davon überzeugt, dass XML die Antwort auf alles in Messagingsystemen ist. Zum Beispiel gab es in den letzten Jahren eine spürbare Verlagerung zu Online-Systemen, die JSON verwenden, um Daten anstelle von XML zu serialisieren, und wenn ich meinen Entwicklerhut für einen Moment aufsetze, würde ich sagen, dass die Tools zum Codieren / Decodieren von nativ sind Die Darstellung (z. B. in Python, PHP, Javascript) scheint viel einfacher zu verwenden als für JSON als ihre Entsprechungen für XML, selbst wenn XML mehr Zeit hatte, um diese Antworten richtig zu machen.
XML ist eine schwierige Darstellung für Computer, da es einen relativ komplexen Textparser und dann eine hierarchische Darstellung benötigt, damit die Daten in einem Programm extrahiert werden können. Da so viel Text enthalten ist, benötigen Sie ziemlich viel Speicher zum Codieren / Decodieren.
Oft scheint es unklar zu sein, dass XML der Darstellung der Daten viel Wert hinzufügt: Wenn die Kernnachricht nicht tief hierarchisch ist, erscheint es unnötig, viel Textspreu hinzuzufügen, aber paradoxerweise, wenn es viel Hierarchie gibt, wird die Nachricht dann dekodiert Die Darstellung in Textform wird harte Arbeit sein und viele Ressourcen erfordern. Der Vorteil der Darstellung in Text ist mir auch nicht klar: Wenn wir Kommunikationssysteme zum ersten Mal schreiben und debuggen, verwenden wir häufig Überwachungs- / Dekodierungswerkzeuge (z. B. Wireshark), um herauszufinden, was falsch läuft. Langfristig funktioniert alles einwandfrei, und kein Mensch muss die hin und her gehenden Nachrichten (nur Computer) im Detail betrachten. Computer bevorzugen binäre Darstellung. Die Textdarstellung kommt niemandem zugute, der in irgendeiner Phase der Bereitstellung involviert ist.
XML ist für Menschen schwer zu lesen (und manuell zu erstellen), während es gleichzeitig für Computer harte Arbeit ist. Es ist daher ein System, das weder für Computer noch für Menschen geeignet ist.
Wichtig ist, dass das Internet der Dinge einige spezielle Einschränkungen aufweist, die es wünschenswert machen, effizient zu sein. IoT-Geräte haben normalerweise eine begrenzte Verarbeitungsleistung und Speicher (normalerweise kein großer Sekundärspeicher, nur etwas RAM und EEPROM). Ein IoT-Gerät verfügt möglicherweise über die einfachsten Kommunikationsverbindungen, möglicherweise nicht einmal über einen TCP / IP-Stack. Es wird eine Vielzahl von Mikrocontroller-Designs geben, nicht einmal auf dem Niveau der Raffinesse, auf dem ein Standardbetriebssystem (z. B. Linux, Android) verwendet werden würde. Dies begrenzt die Anzahl der Standardwerkzeuge, die herumliegen und einfache XML-Schnittstellen bieten.
Zusammenfassend vermute ich, dass mit IoT die Datendarstellung von Fall zu Fall besser belassen wird, abhängig von Hardwareeinschränkungen, Kommunikationsstil (z. B. Broadcast, Datagramm, zuverlässig usw.), Kommunikationsfrequenz usw. XML sollte sicherlich nicht als unabdingbare Voraussetzung für das Internet der Dinge angesehen werden.
quelle
Vor vielen Jahren habe ich Unterschiede für die Verwendung analysiert
XML im Zahlungsnetzwerk zur Darstellung von Zahlungstransaktionen (Kartennummer, Datum, Uhrzeit, Terminal-ID und Liste zusätzlicher Elemente) im Vergleich zu herkömmlichen
Bitmap ISO8583
XML hat einen enormen Overhead. Wenn Sie die Auswirkungen in Netzwerken mit mehr als 10000 Knoten berücksichtigen, von denen jeder mehr als 10 Nachrichten pro Stunde / Tag an den zentralen Host sendet, geht XML aus und Sie benötigen wirklich etwas Effizienteres.
quelle