En definitiva, necesitaba una librería en miniatura para microcontroladores con serializador de datos binarios y la posterior transmisión de estos mensajes por líneas de comunicación de baja velocidad, mientras que los formatos habituales xml, json, bson, yaml, protobuf, Thrift, ASN.1, etc. no encajaba por varias razones.
Como era de esperar, la solución resultó ser más que una bicicleta y, sin embargo, la misma publicación del artículo sobre Habré me ayudó mucho. El hecho es que durante el análisis inicial de posibles bibliotecas, por alguna razón pasé por alto los serializadores MessagePack, CBOR y UBJSON.
Se me escribieron enlaces a ellos en los comentarios después de la publicación del artículo. E inmediatamente me di cuenta de que lo más probable es que CBOR , UBJSON pueda resolver fácilmente el problema que tengo ante mí. Y lo hacen mucho mejor que mi propio desarrollo.
Después de eso, atornillé mi interfaz a la biblioteca CBOR (para no perder las fuentes) y ... decidí abandonar este formato a favor de MessagePack :-)
CBOR vs. MessagePack
En realidad, los formatos CBOR y MessagePack utilizan el mismo principio de serialización de datos. Se basan en un método práctico para escribir TLV , con la única excepción de que en la forma clásica, un TLV siempre contiene un campo de etiqueta y un campo de longitud de datos. Pero el campo con los datos en sí puede estar ausente (si el tamaño de los datos es cero).
Y en estos serializadores, los desarrolladores fueron aún más lejos e hicieron formatos casi ingeniosos en los que la presencia de un campo con un tamaño de datos depende del tipo de datos y no es necesario para campos de tamaño fijo, y el primer byte almacena tanto el tipo de campo con el tamaño de los datos como su tamaño inmediato. valor (por supuesto, si la profundidad de bits lo permite).
En el artículo original escribí sobre el hecho de que necesito el máximo empaquetado de datos binarios y ambos formatos hacen frente a esta tarea a la perfección. Son muy similares entre sí y solo difieren en el número de bits en los que se almacenan los valores del tipo de campo.
En formato CBOR, la sobrecarga de almacenamiento mínima para cada campo es de tres bits, es decir, en el primer byte de cada campo, los tres primeros bits son responsables del tipo de contenido y, dependiendo de él, se interpreta la presencia y tamaño de otros campos, y los 5 bits restantes pueden contener ya el valor del campo en sí.
¡Pero en MessagePack fueron aún más lejos! En este formato, la sobrecarga de almacenamiento mínima para un valor es solo 1 (¡UNO!)poco de información. En consecuencia, se pueden usar 7 bits para almacenar información adicional, y los valores con el conjunto de bits más significativo se usan para indicar información adicional sobre el tipo de campo.
Está claro que el rango de representación de valores negativos con este método de codificación se reduce debido a los números positivos (solo se pueden almacenar 32 números negativos en un byte, y los otros valores requerirán el segundo byte). Pero este es el desequilibrio correcto y se desplaza en la dirección correcta, porque en la práctica, los números positivos se utilizan con mucha más frecuencia que los negativos.
En otras palabras, un byte en formato CBOR puede acomodar valores enteros de 0 a 23, y en formato MessagePack de 0 a 127.
Fue este momento, así como una biblioteca normal con la implementación del formato en una docena de idiomas diferentes, lo que determinó mi elección final a favor del formato MessagePack. Creo que no soy el único que puede estar interesado en estos detalles de la implementación de estos formatos, por lo que creo que es correcto compartir esta información.
Como resultado, el formato original del serializador se hizo aún más compacto, incluso debido a algunas convenciones (por ejemplo, la estructura de los datos codificados debe limitarse solo a una lista plana y la negativa a usar tipos no reclamados), y mi sueño se volvió más tranquilo, porque Ya no es un dolor de cabeza la compatibilidad a nivel de formatos de mensajes reenviados entre dispositivos.
Muchas gracias a los usuarios de Habra Spym y edo1hque respondió a una publicación anterior y, por lo tanto, ayudó a encontrar una solución a un problema realmente grave con tan poco esfuerzo.
Fuentes primarias:
Especificación CBOR . Hay un buen artículo con una descripción sobre Habré .
La especificación de MessagePack es muy fácil de leer en la documentación y no requiere traducción ni explicaciones adicionales.