Критика KEKS от участника IETF CBOR WG
Что: 69435b268f0fc2bb27b10d19c4faaa7616622a5d
Когда: 2025-11-23 18:43:04+03:00
Темы: keks nncp
Критика KEKS от участника IETF CBOR WG https://habr.com/ru/articles/923810/comments/ Несколько часов назад тут у меня была простыня текста поясняющего чем и почему автор комментариев с критикой KEKS не прав. Но позже он опубликовал ещё и критику NNCP. После них у меня остался только один нерешённый вопрос: человек или невменяем/неадекватен, либо просто обыкновенный тролль. Но его же сообщения подтвердили факт того, что в CBOR комитете люди заняты чем угодно, но только не решением реальных задач, а переливанием из пустого в порожнее. Такие люди не в состоянии сделать адекватные решения, что пугает, ведь окружают же нас подобные.
комментарий 0:
From: Sergey Matveev
Date: 2025-11-26 08:35:07Z
------------------------ >8 ------------------------
Тут в одном месте один из разработчиков CBOR вышел на мой KEKS (YAC) с
критикой. Опубликовал он много ссылок и на примеры обсуждений разных
проблем в рассылке CBOR.
Теперь я с полной уверенностью могу говорить о том, что CBOR является
чистейшим 100% поделием "комитета" -- в том самом плохом значении этого
слова. Они максимально далеки от проблем реального мира, как и другие
комитеты пытаясь покрыть все возможные use-case, что, по опыту
человечества, никогда не работает: в лучшем случае будет реализовано
только небольшое подмножество стандарта/формата/протокола.
* Ярчайший пример безумия что там творится: они, как подтвердил
разработчик из IETF WG CBOR, *годами* обсуждали проблему
детерминированного кодирования данных. Проблема в CBOR в том, что они,
академически красиво, решили что ключом в MAP может быть абсолютно
любой тип данных. В том числе другой MAP. Я с ходу даже ни одного
языка программирования или библиотеки не вспомню, которые бы
предоставляли таку странность. И вот из-за неё они не могут годами
договориться и решить как же это всё можно бы было кодировать
детерминированно. Ни одного настоящего принятого предложения по
deterministic или canonical encoding не было принято. На данный момент
их позиция: streaming и deterministic encoding взаимоисключающи друг
другу.
Что, на мой взгляд, надо было сделать? Да просто ограничить тип данных
MAP ключа до чего-то вменяемого. В KEKS это только и только строка.
Все проблемы с детерминированным кодированием волшебным образом уходят.
Да, строго говоря, формально говоря, математически говоря,
действительно детерминированное кодирование и потоковость не
совместимы. В общем случае мы должны сначала узнать (забуферизировать)
все ключи MAP-а, потом отсортировать, и только потом уже можем
производить кодирование. Но, в реальном мире:
* либо список возможных ключей заранее известен. Поэтому этот список
можно просто в коде hard-code-ом отсортировать, как мы сделали в XXX:
const struct {
const char *name;
const size_t nameLen;
const size_t value;
} items[] = {
{KeyDPD, (sizeof KeyDPD) - 1, stats->dpd},
{KeySeen, (sizeof KeySeen) - 1, stats->seen},
{KeyBadPC, (sizeof KeyBadPC) - 1, stats->badPC},
{KeyGotPC, (sizeof KeyGotPC) - 1, stats->gotPC},
{KeyDelGot, (sizeof KeyDelGot) - 1, stats->delGot},
{KeyDPDAck, (sizeof KeyDPDAck) - 1, stats->dpdAck},
[...]
{NULL, 0, 0},
};
* либо в задаче совершенно не обязательно передавать именно MAP, а
можно обойтись списком из пар значений
В CBOR есть крмое bool, nil ещё и undef значение. Из-за него ещё
месяцы обсуждений что со всем этим делать. dCBOR предлагает короткие
FLOAT-ы преобразовать в FP16, что вообще ни одним популярным ЯП не
поддерживается как тип данных. Ответ разработчика CBOR: это проблемы
конкретных языков и инструментов, что включает и их неспособность
иметь MAP в качестве ключа другого MAP.
- Доктор, когда я делаю вот так, мне больно.
- Так не делайте так!
* У них полнейший уклон на компактность кодирования (при этом KEKS
те же 32-байт строки всё равно компактнее кодирует), полностью забивая
на вопросы производительности. И в рассылке и в критике KEKS много раз
было сказано, что на самом деле производительность мало кому нужна.
Фиксированные длины полей заголовков IPv6 есть зло (за десятилетия я
впервые услышал, что его фиксированные заголовки являются не
достоинством).
Опять же, люди максимально далеки от реальности. У них всё является
Kbps каналом связи для IoT лампочки, где даже IPv6 заголовок будет
занимать много места. Вот только у нас всё больше и больше оптоволокна
появляется на 800+Gbps, где нужно триллионы пакетов обрабатывать.
Почему в Google/Facebook используют "странные" Cap'n'proto,
Flatbuffers форматы? Потому что упираются в скорость кодирования и
декодирования. Производительность и компактность представления данных:
на практике полностью взаимоисключающие свойства.
От CBOR было утверждение, что хороший кодек должен покрывать вообще
все use-case, начиная от лампочки, заканчивая терабитным трафиком ДЦ.
Это невыполнимо. Оно одинаково плохо будет для всех use-case. Это
совершенно разные задачи, совершенно разные условия, требования и
ограничения. Хотеть покрыть все задачи такого рода может только тот,
кто далёк от них, далёк от практики и реального мира.
И что мне вообще не понятно. Они делают черновики RFC на ещё более
компактное кодирование, где экономятся биты. Если нужно экономить даже
биты, то адекватным решением может быть только кодек со схемой
(protobuf тот же). А использовать schemaless кодек, но экономить
биты... вообще не понятно.
К сожалению, стандартами становятся те, у кого больше есть время и силы
на бюрократический аппарат. MessagePack, творения DJB, многие другие
кодеки не заморачиваются RFC и прочими не имеющими к технике делами. Они
решают задачи реального мира. CBOR же занимается придумыванием академических
задач, многолетним обсуждением способов их решения, штампованием RFC. Вне
IoT я не встречал чтобы кто-то по доброй воле выбирал CBOR.
Нужна производительность безумная: нужны кодеки заточенные под
machine-friendly, где всякий zero-copy, выравнивание в памяти, и т.д..
Нужна максимальная компактность: schema-full кодеки, без вариантов.
ASN.1 PER поэтому в сотовых сетях и используется.
Нужно удобство работы, schemaless и простота реализации -- это уже
другой класс кодеков
Но, признаю, уж лучше CBOR чем ASN.1. Если взять небольшой subset CBOR,
ввести ограничения на возможные типы ключей в MAP, запретить undef -- то
он ничем не хуже MessagePack будет, вполне useable. Вот только и не понятно
чем он лучше MessagePack, не говоря, конечно же, про KEKS.
------------------------ >8 ------------------------