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:
- Jede Nachricht hat genau 8 Bytes, daher müssen wir weder die Länge angeben noch eine Abschlusssequenz angeben.
- Die acht Bytes beziehen sich immer auf ein 2 x 2-Gitter, in dem jede Zelle einen 16-Bit-Wert enthält.
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:
- Nachrichten haben jetzt eine variable Länge von 0 bis 255 Byte, und das erste Byte gibt die Länge an.
- Es gibt (bis zu) 256 Codes für verschiedene vordefinierte Nachrichtentypen, von denen einer "2 x 2 Tabelle" ist, das ist das zweite Byte.
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).
<message><body>8 bytes.</body></message>
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:
Hat XMPP einen großen Overhead für IoT-Geräte, die kurze, häufige Nachrichten senden?
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,