Search
Write a publication
Pull to refresh

Comments 3

Я участвовал в проекте с работой с 3GPP протоколами, нормальном проприетарном "галерном" проекте. Именно PER был основным страшилищем. Формально там всё хорошо, конечно, но на практике получалась масса проблем с отсутствием средств диагностики сериализации и десериализации сообщений. Возможно, где-то есть высококачественные проприетарные, нам они не достались. В реально же доступном наборе были или такие, которые умели нужные спецификации включая параметризованные ASN.1 схеме, но по принципу "всё или ничего" - или пакет разбирается, или нет, или такие, которые умели показывать все детали разбора согласно приложенной схеме, но при этом содержали невычищенные ошибки. Разбор даже небольшого 100-байтного пакета какого-нибудь XNAP превращался в дёргание между такими средствами и ручной разбор по битам. Это было не последней причиной, почему я оттуда сбежал.

Ситуация усугублялась тем, что формально у 3GPP обратная совместимость, но реально в спецификациях периодически возникало "ой, мы тут диапазон расширили и заодно бит расширения на будущее добавили".

Ваши схемки красивы и чудесны тут, но они не показывают даже малую часть той внутренней боли.

Я понимаю причину введения PER после многословности BER, но цена за неё великовата. Кстати, тут соотношение не всегда строго в пользу PER. Представим себе integer, который обычно не выходит за 100, но иногда может достичь триллионов. Я видел такие случаи. В BER кодирование будет предельно компактным - 2 лишних байта, а дальше само значение в минимуме. В PER тут вот фиксировано 6 байт, 6 и передавай, если такой размах в принципе возможен. (Да, кто-то сделает в таком случае схему с передачей большого значения через расширение. Но это уже костыль.)

В этом смысле меня больше радует CBOR. Упаковка в первый байт базового типа, значения (если влезло) или длины - даёт, конечно, толще выхлоп, чем идеализированный "в сферическом вакууме" PER, но сильно меньше, чем BER, и ещё и сам по себе не требует схемы для получения общей структуры. Жаль, что его так поздно изобрели и мало применяют.

Здесь я вас понимаю. По правде говоря, практически 3gpp рекомендации это боль (до сих пор с содроганием вспоминаю TS 23.040, а это всего лишь техническая реализация SMS). Плюс производители очень любят модернизировать команды в протоколе (добавить своего, это правило, а не исключение). Ну и постоянная доработка стандартов, это общий бич (это ж не "буханка", которая сразу получилось идеальной (это сарказм, если что)).

Я не вижу ничего страшного в бите расширения, это вполне себе инструмент. Хотя по правде говоря, очень не нравится когда его пихают везде, где ни попадя (авось пригодится).

С CBOR никогда не сталкивался. Интересно. Почитаю на досуге.

очень переусложненное и оверинженерное наследство модели OSI (я называю ее "модель SOSI"). но метод есть - прятать поглубже в библиотеки и фреймворки.

Sign up to leave a comment.

Articles