я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
и как же это соотносится с этим?
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
вы либо крестик снимите, либо … ну это… что бы факты уверено раздавать
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
Вы о чем вообще здесь говорите? Что значит “protobuf это не просто gRPC”? Что “помидор это не просто кетчуп”, “яйцо это не просто майнез”? В чём заключается ваша глубокая мысль?
В статье или в комментариях кто-то спрашивал о том, как хранить логи? В статье вообще есть акценты на хранении данных? Если уж разбираться, то у protobuf-сообщения самого по себе нет универсальной сигнатуры/framing для поиска сообщения в произвольном замусоренном потоке - каждый крутится с этим как может, что не отменяет ценности protobuf. Другое дело, что вы просто булщитите, постоянно пытаясь уйти от топика статьи. Мы с таким же успехом можем обсудить здесь интимные стрижки, они примерно так же соотносятся по смыслу со статьей, как упомянутый gRPC.
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи. Во-первых хранение не массивами, а фиксированными чанками, что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Откуда читалось? О каком хранилище вы говорите? О Storage из brec, нацеленном на seekable backend? О каких массивах речь? В brec-storage фиксированным является не размер данных, а размер slot: слот хранит длины пакетов и позволяет вычислять offset. Сами пакеты внутри слота переменного размера. Если вы даёте техническую оценку решения - то сопровождайте её кодом и бенчами, отражающими просадку по чтению/записи. Если бенчи делать лень, то надо очень вежливо спрашивать “а не рассматривали ли вы как вариант это и это?”. Именно вежливо, так как именно автор будет тратить своё время на дополнительные бенчи, чтобы вам ответить. Если и это лень, то хотя бы сформулируйте мысль.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
Сжатие, транспорт, шифрование всего хранилища, чанки, чанки. Вы статью читали вообще - это обзор конкретной фичи. brec crypt не является storage encryption pipeline и не пытается им быть. Вы вообще о чём? Если вы не поняли сути, то об этом можно спросить (вежливо) автора. В статье прямо говорится, в комментариях раскрывается, что есть сценарии, в которых на условные 100 сообщений приходится 1-2 зашифрованных. Точка. Если бы вы серьёзным ребятам, на серьёзных embedded-проектах, предложили бы шифровать всё ради 1-2% данных - вас не уволили, вас бы пристрелили, молча и хладнокровно. Вы либо очень ограниченно понимаете мир логов, трейсов, метрик и прочего, считая, что это вотчина исключительно Datadog и OpenTelemetry, либо какое-то медоборудование, где потоково шифруется зачастую вообще всё, либо… я хрен знает, если вы отрицаете право существования логов в файлах (отсылка к вашим вчерашним комментариям к моим статьям 5-летней давности). Мир разнообразнее, чем вам кажется.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше.
То есть да, DoS через length в одном из reader-path возможен (на недоверительном потоке), и это уже вынесено в issues (вас даже за это поблагодарили!). Но назвать это “кривым шифрованием” - это либо непонимание предмета, либо сознательная подмена тезиса. Шифрование здесь не ломается: payload не раскрывается, AEAD не обходится, валидная подмена encrypted body не появляется. Ломается входная валидация длины до аллокации. Это разные классы проблем. Если это ломает шифрование, то будьте добры доказательства на стол, за базар-то надо отвечать, если уж взялись.
Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы “помолившись забить” но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
Ровно то же самое - лишь бы саср#ть. CRC32 в brec не является криптографической защитой и за неё не выдавался. Это быстрая проверка для чтения, чтобы ловить повреждения и рассинхрон потока. Для encrypted payload криптографическую целостность тела даёт не CRC32, а AEAD-тег ChaCha20Poly1305: если подменить ciphertext/tag, расшифровка не пройдёт.
Да, открытые length/header поля до decrypt-этапа остаются возможностю для DoS, если читать недоверенный поток без лимитов. Именно это замечание я принял и по нему создал тикеты. Даже при том, что на руках у меня нет воспроизводимого сценария атаки. Но превращать CRC32 в “кривое шифрование” - это просто смешивать разные уровни проверки. Во-вторых, архитектура brec и концепция контекста позволяет реализовывать свой механизм вне фичи crypt, отвечающий повышенным мерам безопастности, что прямо в статье указано.
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это “стариковский WASM для десктопов”. Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как “универсальный” CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
Ох сударь, вам бы тут промолчать. Если вы не понимаете, чем отличается компиляция бинарника под разные платформы и архитектуры от биндинга и FFI, то хотя бы попридержите своё мнение. И просто для справки: в мире Cargo вспомогательный CLI/build-time tool - это нормальная практика.
Кстати, что такое "половые трудности"?
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу “небезопасных данных” - если сами разрабы, кто писали логи, такие “индусы” то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
На всё есть ответ и своё единственно-верное мнение. Кругом индусы, а он умничка наша! Ай да молодец, ай да солнышко! Как же хорошо, что мы вместе не работаем )
ЗЫ: Я правда вам признателен за агрессивный прогон решения через ИИ. Вы действительно вскрыли проблему с длинами на недоверенном потоке данных. Тикеты созданы, правки будут внесены. Те 3 проекта (на стадии MVP), что используют сегодня brec и могут в будущем стать реальными продуктами, будут лучше и безопастнее благодаря именно вам. Я особо это подчёркиваю - благодаря Вам. Спасибо! Но наш диалог мог быть совершенно иным, не смотрели бы вы на людей сверху вниз и не пытались бы за счёт других утверждаться. Хотите купить мою учётку на Хабре? Только вряд ли вам это поможет, потому как уважение не покупается.
Послушайте, я внимательно прочитал все ваши комментарии. К сожалению, с должным вниманием - только сейчас.
Что могу сказать: спасибо за прогонку репозитария через ИИ и найденное потенциально уязвимое место. Давайте только для читателей оговоримся, что речь именно о потенциальной уязвимости в сценарии недоверенного входного потока, а не о подтверждённом баге. По этому поводу я уже создал тикеты и буду разбираться.
В остальном, простите, это всё больше похоже на поток общих рассуждений вокруг темы. Если читать по диагонали - выглядит внушительно. Если читать внимательно - многие тезисы либо не относятся к статье, либо подменяют постановку задачи, либо спорят с тем, чего я не утверждал, либо вовсе отменяют реальность - это откровенный флуд. И честно это совсем не характеризует вас, как человека действительно в теме.
Поэтому предлагаю так: если у вас есть конкретные технические замечания по brec - на GitHub есть вкладка Issues и кнопка New Issue. Воспроизводимый сценарий, входные данные, ожидаемое/фактическое поведение - и я с радостью разберу.
А вашей продуктивности остаётся только завидовать: на Хабре меньше месяца, а уже больше полутора сотен объёмных комментариев :) Но увы ни одной статьи про ваши "миллион-миллионов бинарей". Я бы с радостью почитал... отправьте ping, как появится.
Хе ))) @gerbert_MX Вижу, вы уже не ограничились этой статьёй и пошли по архиву моих публикаций, включая материалы двухлетней давности.
Честно говоря, это уже выглядит не как профессиональная дискуссия, а как желание оставить “экспертное мнение” с явным негативным оттенком везде, где получится. Технические комментарии под старыми статьями я здесь обсуждать не буду: во-первых они весьма спорны и откровенно поверхностны, во-вторых это другая тема, другой контекст и местами вообще другой проект.
По brec я уже отдельно признал полезные замечания и завёл тикеты там, где есть реальная техническая фактура. Если появятся конкретные воспроизводимые проблемы - входные данные, падение, DoS-сценарий, ошибка чтения - с радостью разберу.
Если это что-то личное, напишите в личку - я всегда отвечаю.
Я благодарен вам за ответ и за то, что вы нашли время пройтись по коду. Это уже тянет не на комментарий, а на полноценное ревью, и за это правда спасибо. Оценку вроде “ученический проект” я оставлю за скобками: это, что называется, навешивание ярлыков, а не технический аргумент. Увы, в нашей среде такое встречается чаще, чем хотелось бы. Но выбранный вами тон комментария не отменяет того, что часть замечаний полезна и заслуживает отдельного разбора.
Давайте разбираться.
Вначале про контекст - это важно. Во многих местах документации, равно как и в статьях про brec упоминается наиболее подходящий сценарий его использования (по мнению автора) - логирование (логи, трейсы, метрики и вот весь этот зоопарк). Я много работал с DLT, работал с protobuf и flatbuffer, где данные собирались со множества устройств и это были гигобайты данных, которые потом приходилось анализировать и фильтровать. Собственно фильтрация была основной болью. Особенно это актуально для DLT-like протоколов, где можно (но не всегда просто) заглянуть “до” полного парсинга. Под каждый кейс приходилось пилить какой-то “особенный заглядыватель”, а если уж протокол обновился - всё, пиши пропало. Отсюда и основная идея проекта - блоки + полезная нагрузка, где блоки - это “открытый” индекс. То есть проект родился, простите, не как ученический, а как попытка обойти боль )) Причем brec не отменяет тот же DLT, protobuf, flatbuffer и прочих. Brec может быть “индексной” обёрткой - блоки как индекс, а payload может хранить хоть JSON, хоть байты DLT или protobuf.
Этим же контекстом диктовался и дизайн storage, хранящим данные по слотам для быстрого доступа к нужным участкам записей. Хочу записи от 100 000 до 100 042 - вот пожалуйста. Быстро и без магии.
Откуда фигня с шифрованием, если речь о логах? Тут просто. Компании, с которыми приходилось поработать, очень любят класть какую-нибудь гадость в логи. Говоришь им “фу! кака!”, а они всё равно кладут. И логика на самом деле ясна и проста. Во время разработки какой-нибудь приблуды, которая потом будет отвечать за работу приблуды в машине, данных нужно собрать будь здоров и как раз в режиме dev совершенно нормально часть секретиков пихать прямо в логи. У разрабов есть ключ - откроют. Конечно, на проде, когда вафля уже выпущена - такой дичи нет. Но вот во время разработки, когда за ночь легко набегает под терабайт диагностических данных - легко. И шифрование здесь используется как компромисс своего рода, когда разные подрядчики могут работать над массивом данных, но не всегда видеть всё.
Теперь предметно.
За замечание по поводу максимальных размеров - огромное спасибо. Это моё упущение, я об этом не подумал. Честно создал по мотивам два тикета: тыц, тыц. Правда, задача там шире, чем просто default-значение поправить, но буду разбираться. Вы смотрите с перспективы - “как сломать, если захотеть?”, я же честно смотрел с логики прикладного применения в “безопасной” зоне. Это ни в коем случае не отменяет ценности замечания. Тикеты созданы, возьму в работу.
По мотивам замечаний к самой фиче шифрования тоже сделал тикет, чтобы не забыть и подумать.
Про TLS. Это не сюда всё-таки. Это про транспорт. Сравнивать напрямую скорость TLS и brec crypt не корректно, потому что это разные слои и разные задачи: TLS защищает канал, а brec crypt защищает payload внутри самого формата, включая сценарии storage, где TLS уже закончился.
Это замечание “шифрование ничего не гарантирует и ни от чего не защищает” я честно не понял. Про то, что шифруется только payload, сказано в статье и документации. Это осознанное решение. Сама библиотека не кладёт в открытые блоки никаких чувствительных данных; блоки содержат только то, что пользователь протокола сам объявил как открытый индекс. Каким образом это убивает защиту самого payload - я не понимаю. Это не отличается от рабочей схемы, где в protobuf-сообщении шифруется отдельное поле, а остальные поля остаются открытыми. Или я, может быть, не понял, в чём вопрос?
Если посмотрите тикеты, я специально для ясности добавил туда пояснения по мотивации - почему было сделано так или иначе. Это тоже очень важно. И в части шифрования мне пришлось пойти на компромиссы ради производительности. Но вот то, что нужно сделать более гибко настраиваемым - тут я полностью согласен. Как и говорил, тикет создан, но пойдёт как улучшение - уязвимости я не вижу.
Почему не BLAKE3? В текущей схеме SHA-256 используется как часть RSA-OAEP-SHA256, то есть как стандартный и широко поддержанный параметр для обёртки сессионного ключа, а не как самостоятельная попытка выбрать “самый быстрый хеш”. О BLAKE3 думал, но это уже скорее отдельный crypto profile / algorithm option, который можно добавить позже по запросу. В идеале было бы здорово это дело настраивать, но так, чтобы не тянуть кучу зависимостей, а именно на этапе генерации определять “кого” и тянуть только его, чтобы не раздувать бинарник.
Насчёт скорости в боевых условиях. Я честно включал фичу шифрования в бенч. Скрывать ничего не пытаюсь. Конечно, шифрование не бесплатно, но и результаты выглядят вполне недурно. И вообще, если вы посмотрите именно на производительность - я там обманывать никого не пытаюсь, а совершенно честно говорю те сценарии, где brec выигрывает и где проигрывает. И если выигрывает, то честно говорю про цену.
Про unsafe. Тут я словил скример от вас ) Проверил… в crypto-core unsafe нет. В генераторе unsafe действительно встречается в zero-copy / referred path и низкоуровневом копировании байт, а в интеграциях - на FFI/JNI границах (об этом ниже). То есть это не часть криптографической схемы как таковой, но место для отдельного аудита, да.
Вы заглянули в интеграции. Спасибо конечно. Но эту часть я пока не готов анонсировать и этого не делал. Эта часть ещё требует доработок и осмысления, там много проблем и нерешённых архитектурных вопросов. Кэширование для Java - вообще черновик, а C# я даже не решил, оставлю ли в проекте в принципе. И да, вы правы… Если в Node и WASM у меня была возможность более внимательно посмотреть, то в части Java и C# - это чистые MVP. Весь фокус всё-таки был на ядре и генераторе. Про CLI в этой части я всё-таки считаю, что вариант вполне рабочий - не вижу проблемы. Мотивация за этим тоже стоит вполне ясная - интеграция разделена на несколько слоёв: слой кодека, когда мы в принципе можем прочитать сообщение, и слой генерации типов под платформу + биндинг (CLI только про этот слой, и он опциональный). Что касается потенциального кошмара в поддержке интеграции, то да - это риск. Но именно для этого все интеграции вынесены в свои крейты, отделены максимально от ядра и живут своей жизнью. Иными словами, апдейтить интеграцию с Node в 98-99 случаях из 100 можно не трогая ядро. Слой клея там есть, но очень тонкий. Но повторюсь - по интеграции есть много нерешённых архитектурных вопросов, о которых я бы пока предпочёл не говорить.
Про “смешанный поток” или “размазывание шума”. Может, я не совсем чётко артикулировал в статье и документации. Доки перепроверил - речи не идёт о том, что brec может собрать своё сообщение по частям. Речь о том, что может найти целое блюдце в мусорном баке. Но найти среди осколков и склеить битое - нет, не сможет. Этого нигде не заявлено и задачи такой не было.
Если что-то упустил - спрашивайте, я с радостью отвечу. Всегда приятно отвечать на умные вопросы от умных людей, но давайте попробуем без ярлыков ;)
Даже если "упёрся", не вижу в этом особой проблемы. Чтение так или иначе предполагает работу с диском, а не с оперативной памятью. Стремиться к "теоретически чистым" метрикам производительности... ну не знаю, мне кажется это немного избыточно. Тогда мы дойдём до обсуждения: давайте проверим на DDR5, потом на DDR4? Ну вы поняли :)
Меня больше интересует практическая сторона - как работает в реальном сценарии. Хотя вы навели меня на интересную мысль: тесты я действительно делал на SSD (и даже не обратил на это внимание), а не на HDD. Возможно, стоит провести аналогичный тест на HDD и посмотреть разницу. Спасибо за идею!
На счёт скорости вы совершенно правы. В обычном режиме (то есть без фильтрации) brec уступает в скорости JSON. Но на то есть объективные причины :)
Brec добавляет заголовки, чтобы распознать сообщение "в мусоре", и включает CRC, чтобы гарантировать, что данные не были повреждены или искажены. Эти проверки естественно увеличивают накладные расходы, поэтому скорость падает. Но даже при такой нагрузке показатели остаются вполне конкурентными:
Как видите, brec вполне держится рядом, можно сказать, сопит на ушко :) Но при активации фильтрации ситуация меняется, и brec значительно выигрывает за счёт возможности пропускать ненужные данные без полного парсинга.
Смотрите, дело в том, что даже если JSONL позволяет построчно обрабатывать данные, внутри каждой строки у вас всё равно находится целый объект. Например, если у вас есть объект { a: number; b: string; c: Something[] }, вы не можете "заглянуть" в поле a, не пропарсив весь объект целиком. То есть вы не узнаете значение поля a, пока не получите полностью готовый объект с помощью парсинга — только тогда можно сделать проверку obj.a = ?.
Теперь представьте ситуацию: у вас 1 млн таких объектов, а вам нужны только те, у которых a == 42. Среди всего массива данных таких объектов — всего 100 (то есть 100 на 1 000 000). Вам придётся пропарсить целиком все 1 000 000 записей, чтобы найти эти 100.
При частичном парсинге (что в том числе предлагает brec, а также ряд других решений) можно заранее на уровне протокола предусмотреть такой "ключ" и поместить его в самое начало сообщения. В таком случае парсер сможет сразу проверить a == 42 и полностью пропустить парсинг остальных полей, если они не удовлетворяют условию.
Разница наглядно показана в тестах brec. Я как раз сравнивал с JSON, который построчно (как и JSONL) читается из файла. Условие теста было — принимать только те записи, которые удовлетворяют условию. В итоге только за счёт того, что brec пропускал ненужные операции парсинга, он проверил ~1 Гб данных за ~300 мс, в то время как у JSON на это ушло ~600 мс. Это не потому что JSON медленный, а потому что он вынужден парсить запись целиком.
Таким образом мы вновь возвращаемся к целеполаганию. Если вы просто обмениваетесь сообщениями и вам не надо ни хранить их, ни "пропускать" (фильтровать), то самый простой JSON вполне достаточен (пока не столкнётесь например с невалидными строками, но это другая история ;))
А ведь очень точно подмечено! Но всё же brec не вносит новый стандарт — его назначение скорее для использования в закрытой системе, где данные не выходят за пределы этой системы, а сам brec - в первую очередь инструмент. То есть я изначально не ставил перед собой такую цель ))
Спасибо за ваши вопросы. Я отвечу сразу по JSONL и JSONB.
JSONL - это классическое текстовое представление, которое не позволяет эффективно фильтровать данные по критериям без полного парсинга, от чего будет страдать производительность поиска/фильтрации. Даже если библиотека включает "читалку", механизм предфильтрации редко доступен из коробки. Большинство известных мне крейтов поддерживают только чтение и запись, а более сложные операции остаются на откуп разработчику. Brec же предоставляет такие инструменты изначально. Мне кажется, что протокол без готовых инструментов недостаточен для полноценной работы.
JSONB действительно имеет некоторое сходство с brec, но если рассматривать его отдельно от PostgreSQL, остаются вопросы поиска и фильтрации. Обычно библиотеки, крейты jsonb предоставляют лишь бинарное представление JSON без развитых инструментов.
В целом, вопрос что лучше, что эффективнее - порочен по своей природе :) JSONL, JSONB и brec решают разные задачи. Если нужен простой обмен сообщениями, я бы выбрал JSONB или даже bincode (мне он видится более лёгким). Но когда речь идёт о хранении и быстром доступе к структурированным данным, приходится думать не только о протоколе, но и о инстументах для него. Собственно brec и пытается решить эту задачу, давая не только сам по себе протокол (то есть возможность его определить), но и инструменты к нему.
Но в конечном итоге, выбор между этими (или любыми другими) форматами зависит от конкретной задачи и требований к данным.
If you want to write multiple messages to a single file or stream, it is up to you to keep track of where one message ends and the next begins. The Protocol Buffer wire format is not self-delimiting, so protocol buffer parsers cannot determine where a message ends on their own.
All that said, the reason that this functionality is not included in the Protocol Buffer library is because we have never had a use for it inside Google.
This technique requires support for dynamic messages using descriptors. Check that your platforms support this feature before using self-describing messages.
Спасибо за уточнение, но как уже было отмечено этот вопрос отдан на откуп самим разработчикам, то есть не является частью protobuf
Protobuf - это действительно отличный инструмент, но его основной сценарий использования - это обмен сообщениями, а не их хранение. Protobuf не предусматривает стандартного механизма для идентификации и распознавания сообщений в произвольном потоке данных, и предполагает, что канал связи будет заполнен исключительно protobuf-сообщениями, соответствующими единой заранее определённой схеме. Более того, protobuf не задаёт стандартного формата заголовка сообщения, поэтому эту задачу разработчики вынуждены решать самостоятельно. Ещё один момент, на который стоит обратить внимание, — это кросс-языковая поддержка. Да, она является сильной стороной protobuf, но и здесь есть свои подводные камни. Например, документация прямо указывает, что имплементация сериализации и десериализации может немного отличаться в зависимости от платформы, особенно в отношении значений по умолчанию. Конкретный пример: числовые типы в Rust имеют чётко определённые значения по умолчанию (например,0), тогда как в JavaScript такой концепции просто нет. В результате поле вида field: 0, сериализованное на Rust, и то же самое поле, сериализованное на JavaScript, могут дать совершенно разные наборы байт. Причина в том, что Rust по умолчанию не передаёт значения, совпадающие со значениями по умолчанию, считая это излишним, а JavaScript будет передавать их явно. Такой, казалось бы, незначительный нюанс может стать источником серьёзных проблем при интеграции.
А мне как раз хотелось иметь что-то под рукой, что позволит не только эффективно обмениваться сообщениями, но и надёжно хранить их и без проблем распознавать в смешанных («замусоренных») потоках. И да, "префильтрация", когда я могу "заглянуть" в часть сообщения и понять - нужно ли мне его продолжать парсить.
Проверил на windows 11. Воспроизвести проблему не могу. Работает. Попросил коллегу проверить на windows 10, но это займёт какое-то время. Если у вас есть возможность, присоединяйтесь к обсуждению на github, что бы дать немного больше дополнительной информации.
Конечно рассматривали, я даже в статье упомянул об этом - "не electron'ом единым"... На данный момент стабильной и удовлетворяющей нашим требованиям альтернативы electron'у я не вижу... могу ошибаться, конечно. Дело же не только в том, чтобы браузер обернуть во что-то, дело же ещё в OS API... ну банально - системные диалоги, пуши и прочее. В 2021 мы, например, играли с https://tauri.app/... написан на rust, шустрый до безобразия, но базируется на webview, что не приемлемо с точки зрения производительности клиента (надо проверить, может что изменилось за 2 года). Так что пока мы остались на electron, но, как я уже отметил, ядро очень легко связать с любым клиентом и никакой прямо вот привязанности к electron команда не испытывает... просто сейчас он в наибольшей степени соответствует нашим требованиям.
Спасибо, очень надеюсь chipmunk будет полезным иструментом для вас. Кстати мы добавили поддержку attachments для DLT. Так что если trace включает в себя какие-то файлы, они будут отображены на табе Attachments. Текстовые файлы и графические можно просмотреть прямо в chipmunk.
Мне кажется мы просто говорим с вами о разных вещах. Если не ошибаюсь, вы подразумеваете что-то вроде авторизации (или верификации?), поправьте если я не прав.
Назначение SelfKey и AssignedKey немного в другом, в ассоциировании (наверное будет более точно). Например, SelfKey { uuid: string, lang: string, age: number } (поле uuid добавляется всегда автоматически, даже если этого не сделал разработчик, uuid присваивается сервером после успешного подключения). И, например, AssignedKey { age_confirmed: bool }.
Клиент может выставить и язык, и возраст, как его душе будет угодно, но лишь сервер (после какой-то проверки) может заключить, что возраст 18+ подтверждён.
Я думаю, что понятнее будет, если мы посмотрим на гипотетический запрос, после ответа на который, нам надо сделать broadcast всем русско-говорящим клиентам 18+. Например, пришло сообщение в чат и мы хотим сделать рассылку другим клиентам, но только тем у кого подтвержден возраст и указан целевой язык.
import { Response } from "../implementation/responses/message.request";
import {
Identification,
Protocol,
} from "../implementation/responses";
import { Scope } from "../implementation/scope";
// Обработчик входящего сообщения
export function response(
request: Protocol.Message.Request,
scope: Scope
): Promise<Response> {
// Добавляем сообщение в БД или куда-то еще
...
return Promise.resolve(
new Response(
// Готовим ответ клиенту (отправителю сообщения)
new Protocol.Message.Accepted({
uuid: scope.consumer.uuid(),
})
)
// Создаем список клиентов для broadcast
.broadcast(scope.filter.filter((ident: Identification) => {
// Broadcast message будет отправлять только клиентам, удовлетворящим следующему
// условию
return ident.getAssigned()?.age_confirmed && ident.getKey().lang === 'ru';
}))
// Создаем сообщение которое будет отправлено (broadcast message)
.EventsMessage(
new Protocol.Events.Message({
...,
})
)
);
}
Если вы сейчас подумали о том, что подобные данные хранятся обычно в БД и вытаскиваются по мере необходимости - вы совершенно правы. Идея в том, чтобы часть подобных данных иметь "под рукой" для составления списков broadcast.
Стоит также упомянуть, что и по умолчанию наличие AssignedKey не требуется, равно как можно избежать и использование SelfKey (он будет создан автоматически с единственным полем - uuid). Просто в ввиду слишком большого размера статьи, мне пришлось многое опускать. В документации (вы её уже отругали :)) есть разделы, посвященные настройке producer и стратегий в отношении ключей.
"ломай меня полностью... полностью ломай!"(с)
и как же это соотносится с этим?
вы либо крестик снимите, либо … ну это… что бы факты уверено раздавать
Вы о чем вообще здесь говорите? Что значит “protobuf это не просто gRPC”? Что “помидор это не просто кетчуп”, “яйцо это не просто майнез”? В чём заключается ваша глубокая мысль?
В статье или в комментариях кто-то спрашивал о том, как хранить логи? В статье вообще есть акценты на хранении данных? Если уж разбираться, то у protobuf-сообщения самого по себе нет универсальной сигнатуры/framing для поиска сообщения в произвольном замусоренном потоке - каждый крутится с этим как может, что не отменяет ценности protobuf. Другое дело, что вы просто булщитите, постоянно пытаясь уйти от топика статьи. Мы с таким же успехом можем обсудить здесь интимные стрижки, они примерно так же соотносятся по смыслу со статьей, как упомянутый gRPC.
Это просто какой-то набор слов вообще без содержания. “Сама придумала, сама обиделась” ©. В статье речь про фичу в протоколе. В документации прямо говорится, что это конструктор протокола в первую очередь. Storage, reader и прочие части - это инструменты вокруг packet format, а не обязательная часть
cryptи не транспортный протокол. В доках и статье прямо говорится: конструктор протокола + набор инструментов, которыми можно пользоваться по необходимости.Откуда читалось? О каком хранилище вы говорите? О Storage из brec, нацеленном на seekable backend? О каких массивах речь? В brec-storage фиксированным является не размер данных, а размер slot: слот хранит длины пакетов и позволяет вычислять offset. Сами пакеты внутри слота переменного размера. Если вы даёте техническую оценку решения - то сопровождайте её кодом и бенчами, отражающими просадку по чтению/записи. Если бенчи делать лень, то надо очень вежливо спрашивать “а не рассматривали ли вы как вариант это и это?”. Именно вежливо, так как именно автор будет тратить своё время на дополнительные бенчи, чтобы вам ответить. Если и это лень, то хотя бы сформулируйте мысль.
Сжатие, транспорт, шифрование всего хранилища, чанки, чанки. Вы статью читали вообще - это обзор конкретной фичи.
brec cryptне является storage encryption pipeline и не пытается им быть. Вы вообще о чём? Если вы не поняли сути, то об этом можно спросить (вежливо) автора. В статье прямо говорится, в комментариях раскрывается, что есть сценарии, в которых на условные 100 сообщений приходится 1-2 зашифрованных. Точка. Если бы вы серьёзным ребятам, на серьёзных embedded-проектах, предложили бы шифровать всё ради 1-2% данных - вас не уволили, вас бы пристрелили, молча и хладнокровно. Вы либо очень ограниченно понимаете мир логов, трейсов, метрик и прочего, считая, что это вотчина исключительно Datadog и OpenTelemetry, либо какое-то медоборудование, где потоково шифруется зачастую вообще всё, либо… я хрен знает, если вы отрицаете право существования логов в файлах (отсылка к вашим вчерашним комментариям к моим статьям 5-летней давности). Мир разнообразнее, чем вам кажется.То есть да, DoS через length в одном из reader-path возможен (на недоверительном потоке), и это уже вынесено в issues (вас даже за это поблагодарили!). Но назвать это “кривым шифрованием” - это либо непонимание предмета, либо сознательная подмена тезиса. Шифрование здесь не ломается: payload не раскрывается, AEAD не обходится, валидная подмена encrypted body не появляется. Ломается входная валидация длины до аллокации. Это разные классы проблем. Если это ломает шифрование, то будьте добры доказательства на стол, за базар-то надо отвечать, если уж взялись.
Ровно то же самое - лишь бы саср#ть. CRC32 в
brecне является криптографической защитой и за неё не выдавался. Это быстрая проверка для чтения, чтобы ловить повреждения и рассинхрон потока. Для encrypted payload криптографическую целостность тела даёт не CRC32, а AEAD-тегChaCha20Poly1305: если подменить ciphertext/tag, расшифровка не пройдёт.Да, открытые length/header поля до decrypt-этапа остаются возможностю для DoS, если читать недоверенный поток без лимитов. Именно это замечание я принял и по нему создал тикеты. Даже при том, что на руках у меня нет воспроизводимого сценария атаки. Но превращать CRC32 в “кривое шифрование” - это просто смешивать разные уровни проверки. Во-вторых, архитектура brec и концепция контекста позволяет реализовывать свой механизм вне фичи
crypt, отвечающий повышенным мерам безопастности, что прямо в статье указано.Ох сударь, вам бы тут промолчать. Если вы не понимаете, чем отличается компиляция бинарника под разные платформы и архитектуры от биндинга и FFI, то хотя бы попридержите своё мнение. И просто для справки: в мире Cargo вспомогательный CLI/build-time tool - это нормальная практика.
Кстати, что такое "половые трудности"?
На всё есть ответ и своё единственно-верное мнение. Кругом индусы, а он умничка наша! Ай да молодец, ай да солнышко! Как же хорошо, что мы вместе не работаем )
ЗЫ: Я правда вам признателен за агрессивный прогон решения через ИИ. Вы действительно вскрыли проблему с длинами на недоверенном потоке данных. Тикеты созданы, правки будут внесены. Те 3 проекта (на стадии MVP), что используют сегодня brec и могут в будущем стать реальными продуктами, будут лучше и безопастнее благодаря именно вам. Я особо это подчёркиваю - благодаря Вам. Спасибо! Но наш диалог мог быть совершенно иным, не смотрели бы вы на людей сверху вниз и не пытались бы за счёт других утверждаться. Хотите купить мою учётку на Хабре? Только вряд ли вам это поможет, потому как уважение не покупается.
Послушайте, я внимательно прочитал все ваши комментарии. К сожалению, с должным вниманием - только сейчас.
Что могу сказать: спасибо за прогонку репозитария через ИИ и найденное потенциально уязвимое место. Давайте только для читателей оговоримся, что речь именно о потенциальной уязвимости в сценарии недоверенного входного потока, а не о подтверждённом баге. По этому поводу я уже создал тикеты и буду разбираться.
В остальном, простите, это всё больше похоже на поток общих рассуждений вокруг темы. Если читать по диагонали - выглядит внушительно. Если читать внимательно - многие тезисы либо не относятся к статье, либо подменяют постановку задачи, либо спорят с тем, чего я не утверждал, либо вовсе отменяют реальность - это откровенный флуд. И честно это совсем не характеризует вас, как человека действительно в теме.
Поэтому предлагаю так: если у вас есть конкретные технические замечания по
brec- на GitHub есть вкладка Issues и кнопка New Issue. Воспроизводимый сценарий, входные данные, ожидаемое/фактическое поведение - и я с радостью разберу.А вашей продуктивности остаётся только завидовать: на Хабре меньше месяца, а уже больше полутора сотен объёмных комментариев :) Но увы ни одной статьи про ваши "миллион-миллионов бинарей". Я бы с радостью почитал... отправьте ping, как появится.
Удачи!
Хе ))) @gerbert_MX Вижу, вы уже не ограничились этой статьёй и пошли по архиву моих публикаций, включая материалы двухлетней давности.
Честно говоря, это уже выглядит не как профессиональная дискуссия, а как желание оставить “экспертное мнение” с явным негативным оттенком везде, где получится. Технические комментарии под старыми статьями я здесь обсуждать не буду: во-первых они весьма спорны и откровенно поверхностны, во-вторых это другая тема, другой контекст и местами вообще другой проект.
По
brecя уже отдельно признал полезные замечания и завёл тикеты там, где есть реальная техническая фактура. Если появятся конкретные воспроизводимые проблемы - входные данные, падение, DoS-сценарий, ошибка чтения - с радостью разберу.Если это что-то личное, напишите в личку - я всегда отвечаю.
Я благодарен вам за ответ и за то, что вы нашли время пройтись по коду. Это уже тянет не на комментарий, а на полноценное ревью, и за это правда спасибо. Оценку вроде “ученический проект” я оставлю за скобками: это, что называется, навешивание ярлыков, а не технический аргумент. Увы, в нашей среде такое встречается чаще, чем хотелось бы. Но выбранный вами тон комментария не отменяет того, что часть замечаний полезна и заслуживает отдельного разбора.
Давайте разбираться.
Вначале про контекст - это важно. Во многих местах документации, равно как и в статьях про brec упоминается наиболее подходящий сценарий его использования (по мнению автора) - логирование (логи, трейсы, метрики и вот весь этот зоопарк). Я много работал с DLT, работал с protobuf и flatbuffer, где данные собирались со множества устройств и это были гигобайты данных, которые потом приходилось анализировать и фильтровать. Собственно фильтрация была основной болью. Особенно это актуально для DLT-like протоколов, где можно (но не всегда просто) заглянуть “до” полного парсинга. Под каждый кейс приходилось пилить какой-то “особенный заглядыватель”, а если уж протокол обновился - всё, пиши пропало. Отсюда и основная идея проекта - блоки + полезная нагрузка, где блоки - это “открытый” индекс. То есть проект родился, простите, не как ученический, а как попытка обойти боль )) Причем brec не отменяет тот же DLT, protobuf, flatbuffer и прочих. Brec может быть “индексной” обёрткой - блоки как индекс, а payload может хранить хоть JSON, хоть байты DLT или protobuf.
Этим же контекстом диктовался и дизайн storage, хранящим данные по слотам для быстрого доступа к нужным участкам записей. Хочу записи от 100 000 до 100 042 - вот пожалуйста. Быстро и без магии.
Откуда фигня с шифрованием, если речь о логах? Тут просто. Компании, с которыми приходилось поработать, очень любят класть какую-нибудь гадость в логи. Говоришь им “фу! кака!”, а они всё равно кладут. И логика на самом деле ясна и проста. Во время разработки какой-нибудь приблуды, которая потом будет отвечать за работу приблуды в машине, данных нужно собрать будь здоров и как раз в режиме dev совершенно нормально часть секретиков пихать прямо в логи. У разрабов есть ключ - откроют. Конечно, на проде, когда вафля уже выпущена - такой дичи нет. Но вот во время разработки, когда за ночь легко набегает под терабайт диагностических данных - легко. И шифрование здесь используется как компромисс своего рода, когда разные подрядчики могут работать над массивом данных, но не всегда видеть всё.
Теперь предметно.
За замечание по поводу максимальных размеров - огромное спасибо. Это моё упущение, я об этом не подумал. Честно создал по мотивам два тикета: тыц, тыц. Правда, задача там шире, чем просто default-значение поправить, но буду разбираться. Вы смотрите с перспективы - “как сломать, если захотеть?”, я же честно смотрел с логики прикладного применения в “безопасной” зоне. Это ни в коем случае не отменяет ценности замечания. Тикеты созданы, возьму в работу.
По мотивам замечаний к самой фиче шифрования тоже сделал тикет, чтобы не забыть и подумать.
Про TLS. Это не сюда всё-таки. Это про транспорт. Сравнивать напрямую скорость TLS и
brec cryptне корректно, потому что это разные слои и разные задачи: TLS защищает канал, аbrec cryptзащищает payload внутри самого формата, включая сценарии storage, где TLS уже закончился.Это замечание “шифрование ничего не гарантирует и ни от чего не защищает” я честно не понял. Про то, что шифруется только payload, сказано в статье и документации. Это осознанное решение. Сама библиотека не кладёт в открытые блоки никаких чувствительных данных; блоки содержат только то, что пользователь протокола сам объявил как открытый индекс. Каким образом это убивает защиту самого payload - я не понимаю. Это не отличается от рабочей схемы, где в protobuf-сообщении шифруется отдельное поле, а остальные поля остаются открытыми. Или я, может быть, не понял, в чём вопрос?
Если посмотрите тикеты, я специально для ясности добавил туда пояснения по мотивации - почему было сделано так или иначе. Это тоже очень важно. И в части шифрования мне пришлось пойти на компромиссы ради производительности. Но вот то, что нужно сделать более гибко настраиваемым - тут я полностью согласен. Как и говорил, тикет создан, но пойдёт как улучшение - уязвимости я не вижу.
Почему не BLAKE3? В текущей схеме SHA-256 используется как часть RSA-OAEP-SHA256, то есть как стандартный и широко поддержанный параметр для обёртки сессионного ключа, а не как самостоятельная попытка выбрать “самый быстрый хеш”. О BLAKE3 думал, но это уже скорее отдельный crypto profile / algorithm option, который можно добавить позже по запросу. В идеале было бы здорово это дело настраивать, но так, чтобы не тянуть кучу зависимостей, а именно на этапе генерации определять “кого” и тянуть только его, чтобы не раздувать бинарник.
Насчёт скорости в боевых условиях. Я честно включал фичу шифрования в бенч. Скрывать ничего не пытаюсь. Конечно, шифрование не бесплатно, но и результаты выглядят вполне недурно. И вообще, если вы посмотрите именно на производительность - я там обманывать никого не пытаюсь, а совершенно честно говорю те сценарии, где brec выигрывает и где проигрывает. И если выигрывает, то честно говорю про цену.
Про unsafe. Тут я словил скример от вас ) Проверил… в crypto-core unsafe нет. В генераторе unsafe действительно встречается в zero-copy / referred path и низкоуровневом копировании байт, а в интеграциях - на FFI/JNI границах (об этом ниже). То есть это не часть криптографической схемы как таковой, но место для отдельного аудита, да.
Вы заглянули в интеграции. Спасибо конечно. Но эту часть я пока не готов анонсировать и этого не делал. Эта часть ещё требует доработок и осмысления, там много проблем и нерешённых архитектурных вопросов. Кэширование для Java - вообще черновик, а C# я даже не решил, оставлю ли в проекте в принципе. И да, вы правы… Если в Node и WASM у меня была возможность более внимательно посмотреть, то в части Java и C# - это чистые MVP. Весь фокус всё-таки был на ядре и генераторе. Про CLI в этой части я всё-таки считаю, что вариант вполне рабочий - не вижу проблемы. Мотивация за этим тоже стоит вполне ясная - интеграция разделена на несколько слоёв: слой кодека, когда мы в принципе можем прочитать сообщение, и слой генерации типов под платформу + биндинг (CLI только про этот слой, и он опциональный). Что касается потенциального кошмара в поддержке интеграции, то да - это риск. Но именно для этого все интеграции вынесены в свои крейты, отделены максимально от ядра и живут своей жизнью. Иными словами, апдейтить интеграцию с Node в 98-99 случаях из 100 можно не трогая ядро. Слой клея там есть, но очень тонкий. Но повторюсь - по интеграции есть много нерешённых архитектурных вопросов, о которых я бы пока предпочёл не говорить.
Про “смешанный поток” или “размазывание шума”. Может, я не совсем чётко артикулировал в статье и документации. Доки перепроверил - речи не идёт о том, что brec может собрать своё сообщение по частям. Речь о том, что может найти целое блюдце в мусорном баке. Но найти среди осколков и склеить битое - нет, не сможет. Этого нигде не заявлено и задачи такой не было.
Если что-то упустил - спрашивайте, я с радостью отвечу. Всегда приятно отвечать на умные вопросы от умных людей, но давайте попробуем без ярлыков ;)
Даже если "упёрся", не вижу в этом особой проблемы. Чтение так или иначе предполагает работу с диском, а не с оперативной памятью. Стремиться к "теоретически чистым" метрикам производительности... ну не знаю, мне кажется это немного избыточно. Тогда мы дойдём до обсуждения: давайте проверим на DDR5, потом на DDR4? Ну вы поняли :)
Меня больше интересует практическая сторона - как работает в реальном сценарии. Хотя вы навели меня на интересную мысль: тесты я действительно делал на SSD (и даже не обратил на это внимание), а не на HDD. Возможно, стоит провести аналогичный тест на HDD и посмотреть разницу. Спасибо за идею!
На счёт скорости вы совершенно правы. В обычном режиме (то есть без фильтрации) brec уступает в скорости JSON. Но на то есть объективные причины :)
Brec добавляет заголовки, чтобы распознать сообщение "в мусоре", и включает CRC, чтобы гарантировать, что данные не были повреждены или искажены. Эти проверки естественно увеличивают накладные расходы, поэтому скорость падает. Но даже при такой нагрузке показатели остаются вполне конкурентными:
Сплошное чтение (читаем каждый пакет):
brec, использование хранилища: 908 МБ, 1 000 000 записей — 987 мс
brec, чтение пакетов как потока: 831 МБ, 1 000 000 записей — 764 мс
JSON: 919 МБ, 1 000 000 записей — 597 мс
Чтение с фильтрацией (ищем пакеты по критерию):
brec, использование хранилища: 908 МБ, 140 000 записей — 612 мс
brec, чтение пакетов как потока: 831 МБ, 140 000 записей — 340 мс
JSON: 919 МБ, 140 000 записей — 608 мс
Как видите, brec вполне держится рядом, можно сказать, сопит на ушко :) Но при активации фильтрации ситуация меняется, и brec значительно выигрывает за счёт возможности пропускать ненужные данные без полного парсинга.
Смотрите, дело в том, что даже если JSONL позволяет построчно обрабатывать данные, внутри каждой строки у вас всё равно находится целый объект. Например, если у вас есть объект
{ a: number; b: string; c: Something[] }, вы не можете "заглянуть" в полеa, не пропарсив весь объект целиком. То есть вы не узнаете значение поляa, пока не получите полностью готовый объект с помощью парсинга — только тогда можно сделать проверкуobj.a = ?.Теперь представьте ситуацию: у вас 1 млн таких объектов, а вам нужны только те, у которых
a == 42. Среди всего массива данных таких объектов — всего 100 (то есть 100 на 1 000 000). Вам придётся пропарсить целиком все 1 000 000 записей, чтобы найти эти 100.При частичном парсинге (что в том числе предлагает brec, а также ряд других решений) можно заранее на уровне протокола предусмотреть такой "ключ" и поместить его в самое начало сообщения. В таком случае парсер сможет сразу проверить
a == 42и полностью пропустить парсинг остальных полей, если они не удовлетворяют условию.Разница наглядно показана в тестах brec. Я как раз сравнивал с JSON, который построчно (как и JSONL) читается из файла. Условие теста было — принимать только те записи, которые удовлетворяют условию. В итоге только за счёт того, что brec пропускал ненужные операции парсинга, он проверил ~1 Гб данных за ~300 мс, в то время как у JSON на это ушло ~600 мс. Это не потому что JSON медленный, а потому что он вынужден парсить запись целиком.
Таким образом мы вновь возвращаемся к целеполаганию. Если вы просто обмениваетесь сообщениями и вам не надо ни хранить их, ни "пропускать" (фильтровать), то самый простой JSON вполне достаточен (пока не столкнётесь например с невалидными строками, но это другая история ;))
А ведь очень точно подмечено! Но всё же brec не вносит новый стандарт — его назначение скорее для использования в закрытой системе, где данные не выходят за пределы этой системы, а сам brec - в первую очередь инструмент. То есть я изначально не ставил перед собой такую цель ))
Спасибо за ваши вопросы. Я отвечу сразу по JSONL и JSONB.
JSONL - это классическое текстовое представление, которое не позволяет эффективно фильтровать данные по критериям без полного парсинга, от чего будет страдать производительность поиска/фильтрации. Даже если библиотека включает "читалку", механизм предфильтрации редко доступен из коробки. Большинство известных мне крейтов поддерживают только чтение и запись, а более сложные операции остаются на откуп разработчику. Brec же предоставляет такие инструменты изначально. Мне кажется, что протокол без готовых инструментов недостаточен для полноценной работы.
JSONB действительно имеет некоторое сходство с brec, но если рассматривать его отдельно от PostgreSQL, остаются вопросы поиска и фильтрации. Обычно библиотеки, крейты jsonb предоставляют лишь бинарное представление JSON без развитых инструментов.
В целом, вопрос что лучше, что эффективнее - порочен по своей природе :) JSONL, JSONB и brec решают разные задачи. Если нужен простой обмен сообщениями, я бы выбрал JSONB или даже bincode (мне он видится более лёгким). Но когда речь идёт о хранении и быстром доступе к структурированным данным, приходится думать не только о протоколе, но и о инстументах для него. Собственно brec и пытается решить эту задачу, давая не только сам по себе протокол (то есть возможность его определить), но и инструменты к нему.
Но в конечном итоге, выбор между этими (или любыми другими) форматами зависит от конкретной задачи и требований к данным.
Спасибо за уточнение, но как уже было отмечено этот вопрос отдан на откуп самим разработчикам, то есть не является частью protobuf
Спасибо за вопрос!
Protobuf - это действительно отличный инструмент, но его основной сценарий использования - это обмен сообщениями, а не их хранение. Protobuf не предусматривает стандартного механизма для идентификации и распознавания сообщений в произвольном потоке данных, и предполагает, что канал связи будет заполнен исключительно protobuf-сообщениями, соответствующими единой заранее определённой схеме. Более того, protobuf не задаёт стандартного формата заголовка сообщения, поэтому эту задачу разработчики вынуждены решать самостоятельно.
Ещё один момент, на который стоит обратить внимание, — это кросс-языковая поддержка. Да, она является сильной стороной protobuf, но и здесь есть свои подводные камни. Например, документация прямо указывает, что имплементация сериализации и десериализации может немного отличаться в зависимости от платформы, особенно в отношении значений по умолчанию. Конкретный пример: числовые типы в Rust имеют чётко определённые значения по умолчанию (например,
0), тогда как в JavaScript такой концепции просто нет. В результате поле видаfield: 0, сериализованное на Rust, и то же самое поле, сериализованное на JavaScript, могут дать совершенно разные наборы байт. Причина в том, что Rust по умолчанию не передаёт значения, совпадающие со значениями по умолчанию, считая это излишним, а JavaScript будет передавать их явно. Такой, казалось бы, незначительный нюанс может стать источником серьёзных проблем при интеграции.А мне как раз хотелось иметь что-то под рукой, что позволит не только эффективно обмениваться сообщениями, но и надёжно хранить их и без проблем распознавать в смешанных («замусоренных») потоках. И да, "префильтрация", когда я могу "заглянуть" в часть сообщения и понять - нужно ли мне его продолжать парсить.
Thanks!
Проверил на windows 11. Воспроизвести проблему не могу. Работает. Попросил коллегу проверить на windows 10, но это займёт какое-то время.
Если у вас есть возможность, присоединяйтесь к обсуждению на github, что бы дать немного больше дополнительной информации.
Спасибо за рапорт. Создал issue с высоким приоритетом. Проверим обязательно в самое ближайшее время.
Конечно рассматривали, я даже в статье упомянул об этом - "не electron'ом единым"... На данный момент стабильной и удовлетворяющей нашим требованиям альтернативы electron'у я не вижу... могу ошибаться, конечно.
Дело же не только в том, чтобы браузер обернуть во что-то, дело же ещё в OS API... ну банально - системные диалоги, пуши и прочее. В 2021 мы, например, играли с https://tauri.app/... написан на rust, шустрый до безобразия, но базируется на webview, что не приемлемо с точки зрения производительности клиента (надо проверить, может что изменилось за 2 года). Так что пока мы остались на electron, но, как я уже отметил, ядро очень легко связать с любым клиентом и никакой прямо вот привязанности к electron команда не испытывает... просто сейчас он в наибольшей степени соответствует нашим требованиям.
спасибо!
Спасибо, очень надеюсь chipmunk будет полезным иструментом для вас. Кстати мы добавили поддержку attachments для DLT. Так что если trace включает в себя какие-то файлы, они будут отображены на табе Attachments. Текстовые файлы и графические можно просмотреть прямо в chipmunk.
Спасибо за хорошее замечание. В переименовании действительно есть смысл.
Нет клиент не может изменить
uuid(хоть это и поле ключа),uuidназначается только сервером.Мне кажется мы просто говорим с вами о разных вещах. Если не ошибаюсь, вы подразумеваете что-то вроде авторизации (или верификации?), поправьте если я не прав.
Назначение
SelfKeyиAssignedKeyнемного в другом, в ассоциировании (наверное будет более точно). Например,SelfKey { uuid: string, lang: string, age: number }(поле uuid добавляется всегда автоматически, даже если этого не сделал разработчик, uuid присваивается сервером после успешного подключения). И, например,AssignedKey { age_confirmed: bool }.Клиент может выставить и язык, и возраст, как его душе будет угодно, но лишь сервер (после какой-то проверки) может заключить, что возраст 18+ подтверждён.
Я думаю, что понятнее будет, если мы посмотрим на гипотетический запрос, после ответа на который, нам надо сделать broadcast всем русско-говорящим клиентам 18+. Например, пришло сообщение в чат и мы хотим сделать рассылку другим клиентам, но только тем у кого подтвержден возраст и указан целевой язык.
Если вы сейчас подумали о том, что подобные данные хранятся обычно в БД и вытаскиваются по мере необходимости - вы совершенно правы. Идея в том, чтобы часть подобных данных иметь "под рукой" для составления списков broadcast.
Стоит также упомянуть, что и по умолчанию наличие
AssignedKeyне требуется, равно как можно избежать и использованиеSelfKey(он будет создан автоматически с единственным полем -uuid). Просто в ввиду слишком большого размера статьи, мне пришлось многое опускать. В документации (вы её уже отругали :)) есть разделы, посвященные настройке producer и стратегий в отношении ключей.