msgpack C/C++ 6.0.0

Интересно, где этот формат используется и зачем? В его слогане зачем-то указано, что он «быстрее и меньше, чем JSON», но тесты показывают, что он проигрывает и BSON (т.е. бинарному JSON), и Protobuf… 🤔

Это типа бинарного Джейсона, если кто не в курсе.

Вот спек – https://github.com/msgpack/msgpack/blob/master/spec.md#overview

Чем от BSON отличается не знаю.

Референс на тесты? Возможно BSON проигрывает по размеру. А может и нет.

$ apt-cache rdepends libmsgpackc2

libmsgpack-dev
tmate-ssh-server
tmate
neovim-qt
neovim
libdata-messagepack-stream-perl
libgroonga0
groonga-plugin-suggest

https://github.com/fffaraz/awesome-cpp#serialization - и почти каждая библиотека быстрая, очень быстрая или даже быстрейшая.

А где ASN.1 потеряли?

И CBOR тоже нет. Нубы список составляли.

Добавьте.

Но я один раз попробовал и джва года ждал, больше не хочу.

Поэтому header-only библиотеки предпочитаю добавлять сюда: https://github.com/p-ranav/awesome-hpp

Не прошло и 10 минут, и uni-algo добавлена.

Хорошая штука, но как всегда негде применить, а если надо наверное у каждого есть свой велосипед =)))

Поиграть можно тут https://kawanet.github.io/msgpack-lite/

но тесты показывают, что он проигрывает и BSON

где эти тесты?

В питоне по каким-то причинам быстрее оных

ASN.1 даже в первом рассмотрении делится на BER и DER, не говоря уже про экзотику типа кодирования в XML. И реализаций у него множество, большинство которых реализуют свое подмножество стандарта.

Так что если и заводить, то отдельную страничку под все это дело.

и почти каждая библиотека быстрая, очень быстрая или даже быстрейшая.

…но если нужно что-то сложное, ядрёное и энтерпрайзное, то обычно смотрят в сторону Protobuf.

обязательное требование использования С++, если не используются тесты

Ох лол

Использовал msgpack, он реально неплох.

На protobuf вообще не похож, у protobuf кодогенерация. (Хотя мне в итоге пришлось для msgpack тоже делать кодогенерацию).

От BSON немного отличается, но реально BSON менее компактный.

For example, a simple map {«a»:1, «b»:2} is serialized in 7 bytes with MessagePack, while BSON uses 19 bytes.

Я когда-то for fun пытался придумать свой идеальный формат для бинарной сериализации, и в итоге у меня получился msgpack почти бит-в-бит, отличие было только в bin и ext части. Это говорит о том, что в msgpack ещё и продумана расширяемость.

но реально BSON менее компактный.

Как бы вам это объяснить… Обязательное замороченное битовое «сжатие» служебных полей в пакетах данных конечно… эм… прикольно что ли, но не является существенным фактором влияющим на трафик, однако повышает накладные расходы на обработку пакетов по всей цепочке передачи. Именно поэтому так популярна кодогенерация, как в Protobuf, для имплементации маршалинга, ещё с древних времён rpc/dcom/corba и т.д. А если нужно уменьшить данные, то данные придётся честно сжать…

А что, спецификация выглядит довольно приличественно…

Проекту сто лет в обед, но не видел его ни в одном продакшен приложении.

Что с ним не так?

CBOR aka msgpack? :)

Это разные форматы

однако повышает накладные расходы на обработку пакетов по всей цепочке передачи.

Што? Схрена ли формат кодирования как-то влияет на пересылку пакетов? Роутеру насрать что именно роутить.

Што? Схрена ли… насрать…

Именно роутеру? Ну, хорошо, допустим вашу узкую конкретику: А если бы IP-пакеты были бы так же упакованы? Ну вот, захотелось вам свой гипотетический IPv1337 на основе MessagePack сделать. 🤔

А если бы IP-пакеты были бы так же упакованы? Ну вот, захотелось вам свой гипотетический IPv1337 на основе MessagePack сделать. 🤔

Это уже к санитарам.

Он немного неточен. Речь, конечно, о физическом уровне OSI, не о доставке пакетов.

што

Это уже к санитарам.

Вот поэтому и нет такой упаковки данных в IP, и задница вашего роутера в относительной безопасности. 😎

Вот поэтому и нет такой упаковки данных в IP, и задница вашего роутера в относительной безопасности. 😎

В смысле нет? Заголовки в IP упакованы по самое небалуй. А всё, что после заголовка, роутер не парит. Ну, почти.

Заголовки в IP упакованы по самое небалуй

Они НЕ упакованы. А ваш скептицизм мне стал понятен. 🤦‍♂️

Они НЕ упакованы.

Начни с определения термина «упакованы». В IP заголовках нет избыточности, потому что формат уже предполагает упаковку по максимуму.

Юзали в 2016 для мобильных клиентов, по 3г жирный жсон долго выходит. Сейчас хз зачем надо

Хотя ща подумал, если её с gql скрестить то может и выйдет чего

Начни с определения термина «упакованы»

Смею напомнить, что здесь мы с вами говорим о MessagePack, и, соответственно, о его способах упаковки.

msgpack применяется там, где количество данных заранее неизвестно. Для вещей типа сетевых пакетов, где длина статична, такие форматы не имеют смысла.

типа сетевых пакетов, где длина статична

Длина сетевых пакетов НЕ статична. 🤔

Длина заголовков статична. Содержимое пакета после заголовка – проблема приложения, и там может быть что угодно.

Длина заголовков статична.

В том-то и дело, что если бы IP-пакет использовал MessagePack кодирование, то он не был бы со статичным заголовком. Напоминаю, что IP-пакет мы взяли потому, что вы зачем-то решили перевести обсуждение на гипотетические MessagePack-роутеры, хотя это явно не упрощает ситуацию для вашего понимания.

гмгм… я вообще не понимаю, нахрена ты сюда притащил про сетевые пакеты, но ты всё равно неправ. Даже про msgpack.

нахрена

Эм… 🤔 Про сетевые пакеты это вы упомянули, я писал про пакеты данных в общем, без относительно физического уровня передачи, хоть из памяти на диск. Конкретно, вы сказали про «роутер», и я привёл пример с роутером, надеясь, что вам так будет понятнее.

Длина заголовков статична.

Лолшто?

В IP заголовках нет избыточности

Серьезно? т.е., они несжимаемы? А если сожму?

Серьезно? т.е., они несжимаемы? А если сожму?

Сожми. Мне интересно будет посмотреть на это.