Kurz gesagt, ich brauchte eine Miniaturbibliothek für Mikrocontroller mit einem binären Datenserialisierer und die anschließende Übertragung dieser Nachrichten über langsame Kommunikationsleitungen, während die üblichen Formate xml, json, bson, yaml, protobuf, Thrift, ASN.1 usw. passte aus verschiedenen Gründen nicht.
Wie erwartet war die Lösung mehr als ein Fahrrad, und dennoch hat mir die Veröffentlichung des Artikels über Habré sehr geholfen. Tatsache ist, dass ich bei der ersten Analyse möglicher Bibliotheken aus irgendeinem Grund die Serializer MessagePack, CBOR und UBJSON übersehen habe.
Links zu ihnen wurden mir in den Kommentaren nach Veröffentlichung des Artikels geschrieben. Und ich sofort erkannt , dass höchstwahrscheinlich CBOR , UBJSON leicht das Problem vor mir lösen kann. Und sie machen es viel besser als meine eigene Entwicklung.
Danach habe ich meine Schnittstelle mit der CBOR- Bibliothek verschraubt (um die Quellen nicht zu schaufeln) und ... beschlossen, dieses Format zugunsten von MessagePack aufzugeben :-)
CBOR vs. MessagePack
Tatsächlich verwenden die Formate CBOR und MessagePack dasselbe Prinzip der Datenserialisierung. Sie basieren auf einer praktischen Methode zum Schreiben von TLVs , mit der einzigen Ausnahme, dass ein TLV in der klassischen Form immer ein Tag-Feld und ein Datenlängenfeld enthält. Das Feld mit den Daten selbst kann jedoch fehlen (wenn die Datengröße Null ist).
Bei diesen Serialisierern gingen die Entwickler noch einen Schritt weiter und erstellten fast ausgeklügelte Formate, in denen das Vorhandensein eines Felds mit einer Datengröße vom Datentyp abhängt und für Felder mit fester Größe nicht erforderlich ist. Das erste Byte speichert sowohl den Feldtyp mit der Datengröße als auch dessen unmittelbare Größe Wert (natürlich, wenn die Bittiefe dies zulässt).
Im ursprünglichen Artikel schrieb ich über die Tatsache , dass ich die maximalen Packungs von Binärdaten und beiden Formate bewältigen diese Aufgabe mit einem Knall benötigen. Sie sind einander sehr ähnlich und unterscheiden sich nur in der Anzahl der Bits, in denen die Feldtypwerte gespeichert sind.
Im CBOR-Format beträgt der minimale Speicheraufwand für jedes Feld drei Bits, d.h. Im ersten Byte jedes Feldes sind die ersten drei Bits für den Inhaltstyp verantwortlich, und abhängig davon werden das Vorhandensein und die Größe anderer Felder interpretiert, und die verbleibenden 5 Bits können bereits den Feldwert selbst enthalten.
Aber in MessagePack gingen sie noch weiter! In diesem Format beträgt der minimale Speicheraufwand für einen Wert nur 1 (EINS!)ein bisschen Information. Dementsprechend können 7 Bits verwendet werden, um zusätzliche Informationen zu speichern, und Werte mit dem höchstwertigen gesetzten Bit werden verwendet, um zusätzliche Informationen über den Feldtyp anzuzeigen.
Es ist klar, dass der Darstellungsbereich negativer Werte mit dieser Codierungsmethode aufgrund positiver Zahlen verringert wird (nur 32 negative Zahlen können in einem Byte gespeichert werden, und die anderen Werte erfordern das zweite Byte). Aber das ist das richtige Ungleichgewicht und es wird in die richtige Richtung verschoben, weil In der Praxis werden positive Zahlen viel häufiger verwendet als negative.
Mit anderen Worten, in einem Byte im CBOR-Format passen ganzzahlige Werte von 0 bis 23 und im MessagePack-Format von 0 bis 127!
Es war dieser Moment sowie eine normale Bibliothek mit der Implementierung des Formats in einem Dutzend verschiedener Sprachen, die meine endgültige Entscheidung zugunsten des MessagePack-Formats bestimmte. Ich denke, dass ich nicht der einzige bin, der an diesen Details der Implementierung dieser Formate interessiert sein könnte, daher halte ich es für richtig, diese Informationen weiterzugeben.
Infolgedessen wurde das ursprüngliche Format des Serializers noch kompakter, auch aufgrund einiger Konventionen (zum Beispiel sollte die Struktur der codierten Daten nur auf eine flache Liste und die Weigerung beschränkt sein, nicht beanspruchte Typen zu verwenden), und mein Schlaf wurde ruhiger, weil Keine Kopfschmerzen mehr hinsichtlich der Kompatibilität auf der Ebene der Formate von weitergeleiteten Nachrichten zwischen Geräten.
Vielen Dank an Habra-Benutzer Spym und edo1hDas hat auf einen früheren Beitrag geantwortet und so dazu beigetragen, mit so wenig Aufwand eine Lösung für ein wirklich ernstes Problem zu finden!
Primäre Quellen:
CBOR- Spezifikation . Es gibt einen guten Artikel mit einer Beschreibung zu Habré .
Die MessagePack-Spezifikation ist in der Dokumentation sehr einfach zu lesen und erfordert keine Übersetzung oder zusätzliche Erläuterungen.