Здравствуйте, Хреннос, Вы писали:
Х>Спасибо за статью (просвещение — дело нужное). Но нужно что-то делать со стилем изложения.
Вполне допускаю, что именно для Вас мой стиль кажется странным и запутанным. А для кого-то он будет привлекательным и полезным.
Для кого-то описание дополнительного кода есть "азы", а кто-то об этом слышит в первый раз.
Так что Ваш "поток сознания" я также почитал, но замечаний как сделать статью лучше там не нашел. Но Ваше мнение я услышал, спасибо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, y-niko, Вы писали:
YN>>SS7 — это стэк протоколов, в поддержке отдельной реализации которого также участвовал и я, кстати говоря. YN>>И лично знал многих из тех, кто очень успешно занимался разработкой всех уровней этого стэка. C>Ну дык. Я тоже знаю фанатов BDSM.
YN>>Кстати в упомянутой статье говорится только про протокол MAP, протокол уровня приложения. До "реального процессора SS7" там как до Луны пешком. C>Это часть OpenBTS/OpenBSC, которая таки полный стек реализует.
Во-первых в OpenBTS нет реализации полного стека протоколов SS7, смотрите внимательнее документацию.
Во-вторых в моём комментарии я отвечал на замечание другого товарища о том, что якобы "вот в этой статье по ссылке был сделан реальный процессор SS7". Я ответил, что реализация только протокола МАР есть реализация только одного протокола из всего стека. И тут ваш комментарий что МАР реализован также и в OpenBTS, а вот там реализован полный стек протоколов. Этот протокол на самом деле много где реализован, и иногда даже там, где действительно есть реализация полного SS7. Как я понял вы хотели просто поделиться информацией (кстати ошибочной), а никак не отвечали на мой комментарий.
Здравствуйте, y-niko, Вы писали:
YN>Здравствуйте, Хреннос, Вы писали:
Х>>Спасибо за статью (просвещение — дело нужное). Но нужно что-то делать со стилем изложения. YN>Вполне допускаю, что именно для Вас мой стиль кажется странным и запутанным. А для кого-то он будет привлекательным и полезным.
Вопрос в количестве этих "кого-то".
Пока в теме отзывы преимущественно отрицательные.
YN>Для кого-то описание дополнительного кода есть "азы", а кто-то об этом слышит в первый раз.
Для тех, кто слышит о двоичном представлении чисел в первый раз, можно дать ссылку на википедию. Это действительно азы, безо всяких кавычек.
YN>Так что Ваш "поток сознания" я также почитал, но замечаний как сделать статью лучше там не нашел.
Жаль, жаль. Но ничего, я процитирую сам себя, и выделю ключевые моменты, чтобы они стали заметнее:
Честно говоря, от статьи с таким названием я ожидал гораздо менее формальной и более живой подачи материала. Не таблицы битов, а живые примеры с последующим разбором. Не нудное и невнятное описание вычитаний и оснований 256, а живые примеры кодирований чисел: вот тут у нас — бинарное число в дополнительном формате (обратите внимание — в формате big-endian), вот тут — число в виде строки (потому что флаги в заголовке такие-то), а вот тут у нас — напряглись, поднатужились — мантисса числа великой точности. Я вовсе не ожидаю, что после прочтения статьи я смогу во сне перечислить все возможные значения полей в служебных октетах. Как раз наоборот: ожидается, что в голове возникнет какая-то общая картина, что появится представление, как устроен протокол "с высоты птичьего полета".
YN>Но Ваше мнение я услышал, спасибо.
Судя по обиженному тону, мнение вы заслушали, но не услышали.
Раз уж пошёл разговор в глубину, постараюсь свести свои впечатления воедино. Для начала последовательно по тексту в порядке его чтения:
> ASN.1 создавался как некий общий стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте.
Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо.
> Здесь мы рассмотрим только самое сложное – двоичное кодирование (формат ASN.1 BER – Basic Encoding Rules).
BER не самое сложное. PER значительно сложнее.
> Данные, закодированные в формате ASN.1, представляют собой последовательность байт (или "октетов"), которые идут один за другим, без каких либо разрывов.
Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных.
> Часть идентификатора блока (до нескольких октетов).
Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более".
> Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: > 1000 0001 (81) > 1100 1001 (C9)
Тут в принципе верно, но стиль крайне неровный. Читателю потребуется самому совершить конверсии. Лучше было бы так:
"Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: длина длины (значение 129, или 0x81, то есть 128+1, где 1 — количество последующих октетов длины, и 201 (0xC9)."
Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000).
> Положительные целые числа в ASN.1 представляют собой последовательность "индексов" при соответствующих степенях разложения по основанию 256.
Тут уже потоптались без меня, не хочу повторять. Замечу лишь, что это очень хороший пример, почему исходная идея статьи — начинать с простых типов — была не вполне корректной. Если бы
а) вначале объяснили вообще представление беззнаковых и знаковых целых в BE октетной цепочке (для тех, кто этого не знает)
б) сказали бы, что оно применяется 1) в кодировании целых, 2) кодировании мантиссы в вещественных, 3) кодировании длины данного, если оно (грубо говоря) длиннее 127 октетов
— не нужно было бы косноязычить и заплетыком языкаться на таких простых вещах, и уж тем более не упоминать решение уравнений по основанию 256.
> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё.
Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной.
> Значение мантиссы числа представляет собой всегда беззнаковое целое.
Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос.
> Для примера возьмём число 0.15625. Для начала закодируем его в двоичном представлении по основанию 2. Коэффициенты разложения этого числа по основанию 2 будут находиться как: 0.1562510 = 1*2-3 + 1*2-5. То есть мантисса для нашего тестового числа будет иметь значение М = 1012, а значение экспоненты будет равно -5.
Я долго пытался понять, что такое 1012. Единственное верное прочтение — 101 в двоичной системе. Но в выбранном стиле эта двойка смещена так слабо, что практически не отличается в позиции от остальных. Надо было как-то иначе оформить.
> Теперь поставим дополнительное условие: значение мантиссы должно быть "нормализовано",
Без причины такое условие никому нафиг не надо. Надо было бы уточнить, например, "дополнительное требование для CER и DER для обеспечения единственности представления." Но для них всё равно требуется основание 2, а не 8 или 16.
> Кодирование отрицательных целых значений осуществляется по отдельным правилам. Фактически в закодированном отрицательном целом хранится не одно, а два целых числа: основное число и число, которое нужно вычесть из основного числа, чтобы при декодировании получить изначально закодированное отрицательное число.
Безумная форма описания дополнительного кода. Уже обсуждалось.
> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой).
Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому.
> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число).
Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов.
> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00).
Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации.
Во-первых, отличать их друг от друга жёстко нужно только в том случае, если это set, или они оба объявлены optional. Если sequence, и они оба обязательны, то никакой проблемы нет, на чтении будет обнаружено наличие двух REAL подряд, как и положено. Если первое обязательное, а после второго ничего нет, то достаточно самого факта присутствия или отсутствия второго значения. Если после второго другие типы (не REAL), то, аналогично, не требуется обёртка. Критерий здесь — наличие однозначного пути парсинга.
> Для внешней "обертки" используем класс тега PRIVATE (11) и номер тега выберем равный 2.
Как уже сказал — плохой, негодный метод. Для конкретной структуры (sequence), набора (set) положено вводить context-specific теги, пространство значений которых локально для данного группирующего контекста.
> В случае, когда между получателем закодированной информации и отправителем существует заранее согласованная и известная схема ASN.1-сообщений, то при использовании "оберточного кодирования" можно не указывать значение информационного октета для внутреннего, "обёрнутого", значения. В этом случае в качестве значения для "обёртки" будет уже использоваться примитивный тип,
Следовало бы сказать, что это зовётся implicit tagging, в отличие от ранее описанного explicit tagging. Тому, кто не знает описанных сущностей, будет крайне сложно понять, что имелось в виду. Далее, утверждение
> в качестве значения для "обёртки" будет уже использоваться примитивный тип,
я просто не смог распарсить. Implicit tagging означает, что тип вложенного значения известен на основании контекста и значения тега, и не нужно его описывать ещё раз. Что такое "примитивный тип"?
Primitive encoding? Если да, то зачем на это нажимать при описании? Это совершенно несущественно для описания различия между методами тегирования.
> В заключение скажу несколько слов о нотации, которой обозначаются "префиксные типы".
А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно.
Резюмирую.
1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна.
2. Ни одна из этих задач не решена. Для чтения дампов, например, главным вопросом является "мне тут поступило context-specific 0, и где искать, что это должно быть?", а также комплект стандартных граблей типа "если от SNMP устройства пришло C0 D1 E3 F3 в типе counter32, то это всё равно беззнаковое". Для создания — "а как надо сериализовать и нужно ли мне подымать полную машину включая ASN.1 compiler?"
Для просто интересующихся — эта статья способна только отбить интерес к теме. IMHO, лучше всего было бы начинать с того, что объяснить: "Посмотрите, как умные люди решают задачу платформенно-независимого представления любых данных, причём неограниченно расширяемо!" и уже от этого начинать плясать, через объяснения, зачем нужны те же классы, теги и длины (сразу на примерах); почему придумано constructed encoding; зачем нужны странности типа indefinite length; почему кодирование длинных тегов и OID'ов отличается от кодирования целых; показать представления с их вариантами; упомянуть пользу от CER и DER. Переходить ко всё более сложным; те же real'ы дать в самом конце.
3. Ну и язык надо исправлять везде и всюду. И попытки объяснять простое сложнейшими путями (типа решения уравнений по модулю 256) показывают, jIMHO, что у автора нет даже минимального опыта преподавания (такого, как рассказать что-то юным коллегам на работе).
Изначальная задумка интересна (на русском языке мало простых и внятных объяснений ASN.1). Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью.
Здравствуйте, y-niko, Вы писали:
YN>Как я понял вы хотели просто поделиться информацией (кстати ошибочной), а никак не отвечали на мой комментарий.
Смысл моего поста такой: ASN.1 — это полный BDSM. Использовать его по своему выбору может только полный извращенец.
Там где использовать его приходится (телефония, в основном) лучше взять готовые инструменты.
Здравствуйте, Kernan, Вы писали:
C>>Там где использовать его приходится (телефония, в основном) лучше взять готовые инструменты. K>Например? http://www.asnlab.com/asncpp/overview.html — для примера.
Х>Жаль, жаль. Но ничего, я процитирую сам себя, и выделю ключевые моменты, чтобы они стали заметнее:
Х>
Х>Честно говоря, от статьи с таким названием я ожидал гораздо менее формальной и более живой подачи материала. Не таблицы битов, а живые примеры с последующим разбором. Не нудное и невнятное описание вычитаний и оснований 256, а живые примеры кодирований чисел: вот тут у нас — бинарное число в дополнительном формате (обратите внимание — в формате big-endian), вот тут — число в виде строки (потому что флаги в заголовке такие-то), а вот тут у нас — напряглись, поднатужились — мантисса числа великой точности. Я вовсе не ожидаю, что после прочтения статьи я смогу во сне перечислить все возможные значения полей в служебных октетах. Как раз наоборот: ожидается, что в голове возникнет какая-то общая картина, что появится представление, как устроен протокол "с высоты птичьего полета".
YN>>Но Ваше мнение я услышал, спасибо.
Х>Судя по обиженному тону, мнение вы заслушали, но не услышали.
Ну уж и интонацию сообщений научились придумывать
А говорил я прежде всего о том, что если человек хочет улучшить статью то он приводит свои варианты того, что не нравится.
Пока из вашего комментария следует, что должен был примерно так написать про кодирование целых чисел:
"Для кодирования целых чисел используется дополнительный код. Каждый более-менее вменяемый программист должен его знать. Но если что-то непонятно то вот ссылка на Википедию. Ах да — иногда кодировать целые числа можно большим числом октетов чем это необходимо".
Напишите внятно, не косноязычно и понятно про дополнительный код, а потом и вместе обсудим что получиться.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Строжевский Юрий, Вы писали:
N>Раз уж пошёл разговор в глубину, постараюсь свести свои впечатления воедино. Для начала последовательно по тексту в порядке его чтения:
>> ASN.1 создавался как некий общий стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте.
N>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо.
Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
>> Здесь мы рассмотрим только самое сложное – двоичное кодирование (формат ASN.1 BER – Basic Encoding Rules).
N>BER не самое сложное. PER значительно сложнее.
Субъективное мнение. Для меня лично PER является "недо-ASN.1".
>> Данные, закодированные в формате ASN.1, представляют собой последовательность байт (или "октетов"), которые идут один за другим, без каких либо разрывов.
N>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных.
Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
>> Часть идентификатора блока (до нескольких октетов).
N>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более".
Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
>> Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: >> 1000 0001 (81) >> 1100 1001 (C9)
N>Тут в принципе верно, но стиль крайне неровный. Читателю потребуется самому совершить конверсии. Лучше было бы так:
N>"Например, если общая длина блока равна L = 201, то она будет кодироваться с помощью двух октетов: длина длины (значение 129, или 0x81, то есть 128+1, где 1 — количество последующих октетов длины, и 201 (0xC9)."
N>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000).
В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
>> Положительные целые числа в ASN.1 представляют собой последовательность "индексов" при соответствующих степенях разложения по основанию 256.
N>Тут уже потоптались без меня, не хочу повторять. Замечу лишь, что это очень хороший пример, почему исходная идея статьи — начинать с простых типов — была не вполне корректной. Если бы N>а) вначале объяснили вообще представление беззнаковых и знаковых целых в BE октетной цепочке (для тех, кто этого не знает) N>б) сказали бы, что оно применяется 1) в кодировании целых, 2) кодировании мантиссы в вещественных, 3) кодировании длины данного, если оно (грубо говоря) длиннее 127 октетов N>- не нужно было бы косноязычить и заплетыком языкаться на таких простых вещах, и уж тем более не упоминать решение уравнений по основанию 256.
Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"?
И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё.
N>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной.
Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
>> Значение мантиссы числа представляет собой всегда беззнаковое целое.
N>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос.
Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
>> Для примера возьмём число 0.15625. Для начала закодируем его в двоичном представлении по основанию 2. Коэффициенты разложения этого числа по основанию 2 будут находиться как: 0.1562510 = 1*2-3 + 1*2-5. То есть мантисса для нашего тестового числа будет иметь значение М = 1012, а значение экспоненты будет равно -5.
N>Я долго пытался понять, что такое 1012. Единственное верное прочтение — 101 в двоичной системе. Но в выбранном стиле эта двойка смещена так слабо, что практически не отличается в позиции от остальных. Надо было как-то иначе оформить.
Это издержки оформления на этом сайте. На своём сайте я постарался всё сделать красиво.
>> Теперь поставим дополнительное условие: значение мантиссы должно быть "нормализовано",
N>Без причины такое условие никому нафиг не надо. Надо было бы уточнить, например, "дополнительное требование для CER и DER для обеспечения единственности представления." Но для них всё равно требуется основание 2, а не 8 или 16.
Моя фраза относится к примеру кодирования числа REAL. То, что данное требование входит в число правил DER значения в рамках моей статьи не имеет.
>> Кодирование отрицательных целых значений осуществляется по отдельным правилам. Фактически в закодированном отрицательном целом хранится не одно, а два целых числа: основное число и число, которое нужно вычесть из основного числа, чтобы при декодировании получить изначально закодированное отрицательное число.
N>Безумная форма описания дополнительного кода. Уже обсуждалось.
Я уже сказал — напишите свой вариант.
>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой).
N>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому.
И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число).
N>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов.
Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00).
N>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации.
Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
N>Во-первых, отличать их друг от друга жёстко нужно только в том случае, если это set, или они оба объявлены optional. Если sequence, и они оба обязательны, то никакой проблемы нет, на чтении будет обнаружено наличие двух REAL подряд, как и положено. Если первое обязательное, а после второго ничего нет, то достаточно самого факта присутствия или отсутствия второго значения. Если после второго другие типы (не REAL), то, аналогично, не требуется обёртка. Критерий здесь — наличие однозначного пути парсинга.
Ну так я и написал "например при кодировании типа SET" и ранее написал "Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим".
>> Для внешней "обертки" используем класс тега PRIVATE (11) и номер тега выберем равный 2.
N>Как уже сказал — плохой, негодный метод. Для конкретной структуры (sequence), набора (set) положено вводить context-specific теги, пространство значений которых локально для данного группирующего контекста.
Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
>> В случае, когда между получателем закодированной информации и отправителем существует заранее согласованная и известная схема ASN.1-сообщений, то при использовании "оберточного кодирования" можно не указывать значение информационного октета для внутреннего, "обёрнутого", значения. В этом случае в качестве значения для "обёртки" будет уже использоваться примитивный тип,
N>Следовало бы сказать, что это зовётся implicit tagging, в отличие от ранее описанного explicit tagging. Тому, кто не знает описанных сущностей, будет крайне сложно понять, что имелось в виду. Далее, утверждение
>> в качестве значения для "обёртки" будет уже использоваться примитивный тип,
N>я просто не смог распарсить. Implicit tagging означает, что тип вложенного значения известен на основании контекста и значения тега, и не нужно его описывать ещё раз. Что такое "примитивный тип"? N>Primitive encoding? Если да, то зачем на это нажимать при описании? Это совершенно несущественно для описания различия между методами тегирования.
>> В заключение скажу несколько слов о нотации, которой обозначаются "префиксные типы".
N>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно.
Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
N>Резюмирую.
N>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна.
Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
N>2. Ни одна из этих задач не решена. Для чтения дампов, например, главным вопросом является "мне тут поступило context-specific 0, и где искать, что это должно быть?", а также комплект стандартных граблей типа "если от SNMP устройства пришло C0 D1 E3 F3 в типе counter32, то это всё равно беззнаковое". Для создания — "а как надо сериализовать и нужно ли мне подымать полную машину включая ASN.1 compiler?"
N>Для просто интересующихся — эта статья способна только отбить интерес к теме. IMHO, лучше всего было бы начинать с того, что объяснить: "Посмотрите, как умные люди решают задачу платформенно-независимого представления любых данных, причём неограниченно расширяемо!" и уже от этого начинать плясать, через объяснения, зачем нужны те же классы, теги и длины (сразу на примерах); почему придумано constructed encoding; зачем нужны странности типа indefinite length; почему кодирование длинных тегов и OID'ов отличается от кодирования целых; показать представления с их вариантами; упомянуть пользу от CER и DER. Переходить ко всё более сложным; те же real'ы дать в самом конце.
N>3. Ну и язык надо исправлять везде и всюду. И попытки объяснять простое сложнейшими путями (типа решения уравнений по модулю 256) показывают, jIMHO, что у автора нет даже минимального опыта преподавания (такого, как рассказать что-то юным коллегам на работе).
N>Изначальная задумка интересна (на русском языке мало простых и внятных объяснений ASN.1). Но до адекватного состояния тут, увы, надо переделать чуть менее чем полностью.
Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
Здравствуйте, y-niko, Вы писали:
YN>А говорил я прежде всего о том, что если человек хочет улучшить статью то он приводит свои варианты того, что не нравится.
Понимаете, Юрий, некоторые вещи лучше переработать с нуля, нежели улучшать постепенно.
В случае данной статьи бессмысленно улучшать отдельные фрагменты. Это будет медленно, нервно, бестолково, а результат все равно будет недалек от оригинала.
Полностью переработать нужно несколько вещей. Постараюсь максимально подробно описать, как я это вижу:
Необходимо определить целевую аудиторию и писать статью именно для нее. Очевидно, что это не школьники (им ASN.1 нафиг не впился). Очевидно, что это люди, посещающие КЫВТ (статья выложена именно на нем). Очевидно, что это НЕ люди, профессионально и досконально разбирающиеся в протоколе ASN.1 (да, они могут прочитать статью из любопытства или ради прикола, но не ради получения полезных сведений — статья у нас называется "простыми словами"). Следовательно, аудитория статьи — люди, которым по долгу службы пришлось работать с ASN.1 и которые хотят понять, что это за зверь такой, и просто интересующиеся (типа меня) — слышали краем уха что-то и хотят получить общее представление о предмете. Следовательно, надо определить:
1 Уровень подачи материала. Мы пишем статью для начинающих, а не мануал для специалистов, поэтому не стоит вставлять в статью длинные списки, таблицы битовых полей и прочую конкретику. Конкретика — только там, где без этого не обойтись (при разборе конкретных примеров).
2 Стиль изложения. Бич русскоязычных технических статей — это суконность языка, наплевательское отношение к читателю ("кому надо — разберется"), громоздкие конструкции, полное отсутствие юмора. Гораздо приятнее читать статьи англоязычных авторов: они не вещают истину в последней инстанции, как это принято у нас. Они вместе с читателем открывают для себя тонкости описываемого протокола или явления. С оговорками ("вот этот аспект мы пока пропустим — он слишком сложен"), со ссылками на спецификации илистатьи, где предмет рассмотрен более углубленно.
3 Широта охвата темы. Очевидно, что начинающим гораздо полезнее дать общие принципы построения протокола, нежели чем ткнуть их носом в какую-то одну конкретную его область и начать знакомить с ее тонкостями. Тонкости (особенно если их много) лучше оставить на потом — как тему для других статей. Так мы и себе задел на будущее обеспечиваем, и читателя не отпугиваем обилием мелочей, которые непонятно, как применять.
YN>Пока из вашего комментария следует, что должен был примерно так написать про кодирование целых чисел: YN>"Для кодирования целых чисел используется дополнительный код.
Уже неплохо (заметим, это гораздо лучше ваших "двух чисел, которые надо вычесть одно из другого"). Только чуть больше конкретики:
Для кодирования целых чисел в BER используется знакомый каждому программисту дополнительный код(ссылка). Следует учесть, что порядок байт в протоколе ASN.1 — Big-endian(ссылка).
А еще я бы учел, что часть аудитории может быть незнакома с терминологией, используемой в телекоме, поэтому по ходу пьесы я бы объяснил, что такое "октет" и зачем он так назван.
YN>Каждый более-менее вменяемый программист должен его знать.
Суть верна, но. Фраза звучит по-гадски. Не стоит косвенно оскорблять читателя, называя его "невменяемым". Следует признать право читателя не знать многих, даже элементарных, вещей. Но и рассусоливать каждую мелочь тоже не нужно. Наиболее правильный подход — давать в статье краткое описание таких вещей, плюс ссылку на более полную статью или стандарт, если читателю захочется освежить память. Это своеобразный жест вежливости: вы не засираете текст тягомотными описаниями, но и не оставляете за бортом тех, кто кой-чего подзабыл.
Найти правильный баланс между краткостью и полнотой изложения — это и есть талант писателя (в т.ч. технических статей).
YN>Но если что-то непонятно то вот ссылка на Википедию.
Ссылку на википедию нужно давать без комментариев в стиле "гуру снисходит к дебилам". Это элементарная вежливость по отношению к читателю.
YN>Ах да — иногда кодировать целые числа можно большим числом октетов чем это необходимо".
Вот насчет количества байт в числе я бы остановился поподробнее (если это нужно). А если это не нужно для понимания протокола, значит, фраза просто создает лишний шум в голове у читателя, и я бы убрал ее вообще.
YN>Напишите внятно, не косноязычно и понятно про дополнительный код, а потом и вместе обсудим что получиться.
"Спердобейся", да?
Внятно, не косноязычно и понятно пишу про дополнительный код: "Для кодирования целых чисел в BER используется знакомый каждому программисту дополнительный код".
Но обсуждать тут абсолютно нечего: перед тем, как нырять в дебри словоблудия, нужно определить широту охвата темы (см. п. 3 выше). Вопрос стоит так: а стоит ли вообще обсуждать двоичное кодирование в статье такого уровня? Может быть, для этой статьи будет лучше просто рассказать читателю о том, какие типы кодирования имеются в ASN.1, нахрена их столько, и когда какой из них применяются? А более подробный разбор разных типов кодирования, может быть, лучше оставить на потом — для других ваших статей на ту же тему?
Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль".
Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред.
Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может.
Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
На самом деле на сайте RSDN статья была выложена последней. До этого (за полгода до публикации на RSDN) она была опубликована на Хабре и на моём сайте.
Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания.
Больше замечаний мне дала жена, которая является профессиональным бухгалтером. Честно — я ожидал от местной аудитории бОльшего.
Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования). Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана. Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены. Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Здравствуйте, y-niko, Вы писали:
N>>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо. YN>Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
А ничего, что они явно упомянуты в ряде документов?
N>>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных. YN>Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
Да, изобразить крик Вы смогли — "Запомните раз и навсегда". Только вот от того, называть BER правилами кодирования или форматом, неточностей на порядки меньше, чем называть их "ASN.1". Если у меня это максимум упрощение терминологии, не влияющее на понимание (и даже облегчающее для произвольного постороннего читателя), то у Вас — огрубление до полного бардака, потому что первая же встреча прочитавшего это с PER или XER введёт в когнитивный диссонанс. Как "вода, которая течёт вниз, хотя она течёт вверх" у египтян в Месопотамии.
>>> Часть идентификатора блока (до нескольких октетов). N>>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более". YN>Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
Попробуйте взглянуть на текст, представив себе, что Вы ничего не знаете про предмет статьи.
N>>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000). YN>В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
Ну вот оно неровно. Или надо разжёвывать всё, и тогда сказать, что 201 == 0xC9. Или сократить, тогда в первую очередь не нужно битовое представление. Хотя я вижу, что Вы этот кусок практически передрали из X.690, пункт 8.1.3.5. Тогда неудивительно.
YN>Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"? YN>И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
Это вызов? Ну давайте попробую. Я даже никуда в сеть не заглядываю:
"Несколько слов про дополнительный код ((ссылка)) для тех, кто с ним не знаком. В дополнительном коде в представлении в N бит значения от 0 до 2**(N-1)-1 включительно (то есть те, у которых старший бит равен 0) означают равные им неотрицательные числа. Значения от 2**(N-1)-1 до 2**N-1 (то есть те, у которых старший бит равен 1) означают отрицательные числа от -2**(N-1) до -1 соответственно. Например, в 1 байте (8 бит) это от 0 до 127 и от -128 до -1; в 2 байтах (16 бит) — от 0 до 32767 и от -32768 до -1; и так далее.
Во внутреннем использовании компьютера обычно используются фиксированные количества бит в числовых действиях, в современных это в основном 4 или 8 октетов (32 и 64 бита соответственно), реже 1 или 2 байта (8 и 16 бит соответственно). Например, число 123 представляется как 7B, 00 7B, 00 00 00 7B или 00 00 00 00 00 00 00 7B. Аналогично, -120 представляется как 85, FF 85, FF FF FF 85, или FF FF FF FF FF FF FF 85. Для представлений в BER допускается произвольное количество октетов в представлении, но минимально необходимое для представления конкретного числа. Для примеров выше допускаются только однооктетные представления. Аналогично, например, число 987654 может быть представлено в трёх октетах как 0F 12 06, но равное ему представление 00 0F 12 06 уже запрещено. Число 127 ещё представляется как 7F, но 128 — уже как 00 80, потому что представление 80 значит -128, а не 128.
В примерах выше все числа были записаны так, что старшие цифры шли раньше в записи. Если их укладывать в память или в поток в том же порядке, получится так называемое big-endian представление ((ссылка)), в котором в октетах с меньшими адресами находятся старшие части числа. Это единственно допустимое представление для BER и потомков. Представление с обратным порядком, так называемое little-endian ((ссылка)), применяется во многих процессорах, как x86, но оно требует перестановки октетов для экспорта или импорта в BER.
Описанные правила применяются 1) для представления содержимого целого типа, 2) для представления мантиссы в содержимом вещественного типа (REAL), 3) для представления длины элемента, если она задана в длинной форме. В случае мантиссы в REAL она считается беззнаковой, правила дополнительного кода для отрицательных чисел не используются."
Я считаю, что это в разы понятнее, чем "... и число, которое надо вычесть из основного" или "решим уравнение" (которое тут нафиг не сдалось, зато способно отпугнуть 90% читающих). Если же кого-то надо учить таким основам, как двоичное представление чисел, 16-ричная система и т.д., то это надо делать отдельным документом (можно поставить на него ссылку).
>>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё. N>>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной. YN>Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
Да, я уже прокомментировал, что это получилось методологически крайне неудобно. Это как учить первоклашек объяснению, что такое числа, в стиле Бурбаки. Не зря обычно учат от простого к сложному. Обратный подход постоянно порождает несуразности в изложении.
>>> Значение мантиссы числа представляет собой всегда беззнаковое целое. N>>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос. YN>Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
В подавляющем большинстве представлений мантисса — нецелое значение, лежащее в диапазоне или 1<=M<b, или 1/b<=M<1, где b — основание системы счисления. Для нормализованных двоичных в IEEE754, например, это первый вариант, при b=2. Представление в BER отличается от них именно что принципиально, и это надо было подчеркнуть.
>>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой). N>>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому. YN>И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
Я про слово "фактически". Им принято вводить выводы, согласующиеся с фактами, но сделанные из ранее изложенного материала, а не другого источника. Если это правило изложено явно, то лучше написать где-то так: "Можно сказать иначе (и это явно сказано в X.690 пункт 8.3.2), что первые 9 бит представления целого числа не могут все совпадать друг с другом; такое совпадение означает, что можно устранить старший октет представления без ущерба для значения представленного числа."
>>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число). N>>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов. YN>Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
Это Вы разберитесь. Уже BER требует представления целого минимальным количеством октетов, независимо от знака. Процитировать, или сами найдёте? Зато оно почему-то не требует представления *длины* минимальной формой (то есть позволяет, например, 02, 81 02, 82 00 02, и так далее).
>>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00). N>>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации. YN>Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE).
В случае, если действовать по Вашему примеру (есть SET, внутри два REAL, надо различить, и на побочные эффекты плевать), а почему это UNIVERSAL не годится? Ну написали Вы вместо REAL — INTEGER, всё равно ведь сами разбираете? Различие достигнуто, а каким методом — неважно.
Итого: как в анекдоте, или трусы наденьте, или крестик снимите. Или мы используем таки BER для ASN.1, и тогда есть определённые правила, которые нельзя нарушать. Или мы его используем в сферическом вакууме, и тогда нам вообще всё пофиг, где какие типы и почему.
YN>Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила.
N>>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно. YN>Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
Это Вы так решили, что она "будет нужна только в специфичных случаях"? А почему? Обычный метод работы с ASN.1 таки начинается с составления схемы данных.
N>>Резюмирую.
N>>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна. YN>Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
Я дальше всё описал.
[...]
YN>Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. Всё-таки его использование чем дальше, тем меньшую долю составляет от всего, что есть в мире, и в моей практике он как-то не встречался ни разу, кроме суррогатов в виде SNMP.
Практически, все случаи, где бы оно могло применяться, у нас покрыты JSON'ом.
Здравствуйте, y-niko, Вы писали:
YN>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Извините за ещё один потенциально низкий комментарий, но рекомендую посмотреть в зеркало.
YN>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
Если четвёртый — это я, то с деталями плохо таки у Вас. Извините за назойливость.
А в общем, Хреннос прав, классическое "сперва добейся".
YN>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
Я там рядом приводил ссылку, где я писал больше чем просто статью. Ещё я вёл курсы для сисадминов. Ещё у меня есть преподавательский опыт кроме этого. Но если считать критерием статьи именно для RSDN... Я не пишу ничего именно для RSDN, почти принципиально.
YN>На самом деле на сайте RSDN статья была выложена последней. До этого (за полгода до публикации на RSDN) она была опубликована на Хабре и на моём сайте.
Свой сайт — считайте, никто не увидел. Хабр очень неровен, выдержит всё, включая и такие статьи. И там очень специфический контингент — статья с чудовищными ляпами, но с кавайной картинкой, больше понравится, чем полностью правильная, но без картинок. Я бы не гордился этим, извините.
YN>Потом на моём сайте я опубликовал версию статьи с исправленными ошибками и неточностями. Но здесь никто (кроме редактора сайта, большое ему спасибо) не дал мне ни одного полезного замечания.
Потому что Вы все полезные замечания успешно проигнорировали.
YN>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования). Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана. Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены. Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Отлично. В таком случае прошу принять конструктивные замечания от меня и коллег Хреннос и Cyberax. (Впрочем, если Вы их заранее записали в помои, то итог будет неудивителен.)
Здравствуйте, netch80, Вы писали:
N>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины.
Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное . В русскоговорящих странах эта информация практически не нужна, т.к. нет отрасли её использующей, поэтому если и писать статьи, то на английском .
Здравствуйте, Kernan, Вы писали:
N>>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. K>Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное .
"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
K> В русскоговорящих странах эта информация практически не нужна, т.к. нет отрасли её использующей, поэтому если и писать статьи, то на английском .
Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно.
Здравствуйте, netch80, Вы писали:
N>"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
О да. N>Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно.
Например? Что за конторы есть у нас которые производят оборудование или чипсеты для телекома? Я только интеграторов наблюдаю.
Здравствуйте, Kernan, Вы писали:
N>>Отрасль есть. Но её действительно настолько мало, что возиться с русским обычно невыгодно. K>Например? Что за конторы есть у нас которые производят оборудование или чипсеты для телекома? Я только интеграторов наблюдаю.
Зачем сразу чипсеты?
Вот тут я работаю (с перерывами) с ноября 2004-го.
Все решения построены как "стандартные серверы с собственным софтом". Не знаю, можно ли это считать интегратором.
Всего около 60 программистов (Киев, Чернигов, Сумы, несколько человек за пределами Украины).
Вся внутренняя кухня на SIP, но есть сопряжение с H.323.
Вот эта контора была вообще первой, кто запустил в Украине наложенные сервисы из серии "отправьте SMS на короткий номер", и сейчас обеспечивает их существенную часть. Её директор — мой старый знакомый и бывший коллега по ISP. В решениях тоже много всякого GSM и SS7 (в первую очередь в сопряжениях).
И да, я как-то ему (директору) помогал разбирать фигню в BER — когда он ещё сам это делал
Здравствуйте, y-niko, Вы писали:
YN>Мне очень жаль, что уровень комментариев на этом сайте столь низок.
Не соглашусь.
"Низкий уровень" — это когда комментарии идут уровня "гыгыгы", "кг/ам" или "пешы исчо".
Среди комментариев на вашу статью не было ни одного пустопорожнего. Были критические, были малоконструктивные (каюсь), были обсуждения каких-то малозначащих особенностей терминологии и протокола (заметим — в дискуссии активно участвовали вы сами).
YN>Сначала один говорит, что ему интереснее PER чем BER. Отвечаю — напиши сам про PER. Мне отвечают, что я некий "троль". YN>Другой начинает говорить сначала ерунду про RFC и STD, потом сваливается в какой-то бред. YN>Третий говорит, что у меня косноязычно написано про дополнительный код, но сам его суть объяснить не может. YN>Четвёртый даёт относительно подробные комментарии, но постоянно ошибается в деталях.
YN>Причём ни один (!) из критикующих не написан ни одной статьи на RSDN. Однако про стиль изложения все считают за "честь" сказать.
Другими словами, "вы все дураки и не лечитесь".
Понимаете, Юрий, мы ведь не со зла тут вас критикуем. Попытайтесь быть объективным: если бы не ваши попытки доказать оппонентам, что они дураки, дискуссия была бы гораздо продуктивнее и не свелась бы к "сперва добейся".
Что касается выделенного, поясню мою точку зрения: в статье подобной направленности ("протокол, вид сверху") и целевой аудитории (программисты и специалисты) не следует объяснять суть таких вещей, как представление чисел в двоичном виде. Достаточно упомянуть о существовании и привести ссылку на полное описание. Впрочем, если объяснение простое, а термин достаточно часто используемый и не всем читателям знаком, то можно и объяснить (как я это сделал бы для термина "октет").
YN>Я считаю свою статью полезной и описанной на доступном языке (первым моим читателем была бухгалтер, достаточно далёкая от программирования).
Жена — лицо заинтересованное, поэтому я бы не сильно доверял ее заверениям, что все читается легко и гладко.
YN>Я считаю себя специалистом достаточной квалификации чтобы писать статьи такого плана.
В вашей квалификации как технического специалиста у меня лично нет никаких сомнений. Но для написания научно-популярных статей нужно быть больше, чем хорошим техническим специалистом.
Ваша статья (судя по заголовку) относится именно к таким — "просто о сложном". А вот написана она в стиле "сложно о простом", что, как бы, неожиданно для статей подобного плана.
YN>Я готов обсуждать критические замечания к моей статье, но различные "помои" и личные мнения будут пропущены.
Баз личных мнений, к сожалению, не обойтись. Впечатление от статьи, понятность формулировок — штука субъективная. Вы как автор вольны игнорировать мнения, которые лично вам кажутся неадекватными.
Очевидно, что если принимать во внимание все высказанные мнения, то ничего хорошего из этого не выйдет: на вкус и цвет товарищей нет.
Но также очевидно, что если игнорировать все мнения, не совпадающие с вашим собственным, то вы добровольно отсекаете от себя обратную связь, а значит, и возможность улучшить свой стиль.
Что касается "помоев" — вы сами их провоцируете, пытаясь поймать оппонентов на незнании или неумении что-то объяснить. Собственно, уже то, что вы используете в отношении высказавшихся здесь слово "оппонент", показательно: вы изначально ставите себя в позицию, когда любое критическое замечание в адрес вашей статьи надо обязательно опровергнуть. Гораздо конструктивнее было бы относиться к высказывающимся как к друзьям, а не врагам-оппонентам: не опровергать, а попросить объяснить; не ловить на незнании тонкостей, а выяснить, насколько вообще эти тонкости важны в рамках статьи.
YN>Я за то, чтобы расширять информированность аудитории, в различных сферах. Если есть претензии к моей информации — напишите свои варианты, напишите отдельные статьи и книги. Пусть они будут дополнением к моей статье, или полностью её заместят. Я за достойную конкуренцию.
Юрий, ваше требование абсурдно.
Как я уже говорил, целевая аудитория вашей статьи — мало- и средне-знакомые с протоколом люди, которые по долгу службы или из любопытства хотели бы получить о нем представление. Вы же призываете их писать о том, о чем они пришли узнать от вас.
Здравствуйте, netch80, Вы писали:
K>>Везде, где есть телефония все эти ваши SS7, GSM, UMTS, LTE, LTE-A — будут использовать ASN.1 до скончания времён наверное . N>"Узок их круг, страшно далеки они от народа." Я общался с H.323 и SNMP. Но вероятность встречи с кем-то ещё, имеющим такой опыт, чем дальше, тем уверенней стремится к 0.
H.323 с его PER мало кто пинал напрямую, да. А вот бороться с (часто глючащим) SNMP приходилось многим.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, y-niko, Вы писали:
N>>>Это крайне однобокое описание целей ASN.1, или вообще не для ASN.1 как такового, а его конкретных представлений. Цели ASN.1 заметно другие: описать всё что угодно, но абстрактно и расширяемо. YN>>Думаю, что каждый может додумывать для чего именно создавался стандарт ASN.1. Сомневаюсь что вы являетесь здесь истиной в последней инстанции.
N>А ничего, что они явно упомянуты в ряде документов?
То есть моё "стандарт, позволяющий описывать произвольную информацию, которая бы понималась любым компьютером, имеющим представление об этом стандарте" — это в корне ошибочное заявление, и официальная позиция только ваша?
N>>>Смещённая терминология. Следовало бы писать хотя б "данные в формате BER", и так везде по тексту. Опять-таки путаница между ASN.1 в целом и конкретными представлениями конкретных данных. YN>>Запомните раз и навсегда: нет такого "формата BER". BER расшифровывается как "Basic Encoding Rules". То есть это базовый набор правил кодирования. Все остальные "форматы" вроде DER и CER налагают только дополнительные ограничения на BER.
N>Да, изобразить крик Вы смогли — "Запомните раз и навсегда". Только вот от того, называть BER правилами кодирования или форматом, неточностей на порядки меньше, чем называть их "ASN.1". Если у меня это максимум упрощение терминологии, не влияющее на понимание (и даже облегчающее для произвольного постороннего читателя), то у Вас — огрубление до полного бардака, потому что первая же встреча прочитавшего это с PER или XER введёт в когнитивный диссонанс. Как "вода, которая течёт вниз, хотя она течёт вверх" у египтян в Месопотамии.
Во введении к статье я написал, что статья примеры в статье кодируются с применением правил BER. Где я там замещал BER на ASN.1 — мне непонятно.
>>>> Часть идентификатора блока (до нескольких октетов). N>>>Слово "часть" диверсионно, потому что наводит на мысль о том, что остальная часть этого представления где-то спрятана. Лучше заменить на какой-то менее проблемный аналог ("сегмент", "поле"...) "До нескольких октетов" тоже некрасиво. "Не менее 1 октета", "1 октет или более". YN>>Мне слабо понятно почему это слово "часть" наводит на мысль, что остальная часть где-то спрятана.
N>Попробуйте взглянуть на текст, представив себе, что Вы ничего не знаете про предмет статьи.
У меня нет такой аллергии на простое слово "часть".
N>>>Разложение в двоичный вид тут совершенно не нужно, и даже сбивает с толку (на втором октете). Но ещё лучше было бы сразу привести пример, когда длина не укладывается в 1 октет даже так (например, равна 2000). YN>>В статье в предыдущем параграфе разговор шел на уровне битового разбора, так что и пример также приведен с использованием двоичного разложения.
N>Ну вот оно неровно. Или надо разжёвывать всё, и тогда сказать, что 201 == 0xC9. Или сократить, тогда в первую очередь не нужно битовое представление. Хотя я вижу, что Вы этот кусок практически передрали из X.690, пункт 8.1.3.5. Тогда неудивительно.
Я ещё раз повторю: ранее в статье я вел разговор на уровне битов. А то что двоичное представление в скобках дано в шестнадцатеричном формате, и это вам не нравится — пусть будет так.
YN>>Что такое "представление беззнаковых и знаковых целых в BE октетной цепочке"? YN>>И я тут уже выше одному оппоненту написал: считаете моё описание косноязычным — напишите своё и мы его пообсуждаем.
N>Это вызов? Ну давайте попробую. Я даже никуда в сеть не заглядываю:
N>"Несколько слов про дополнительный код ((ссылка)) для тех, кто с ним не знаком. В дополнительном коде в представлении в N бит значения от 0 до 2**(N-1)-1 включительно (то есть те, у которых старший бит равен 0) означают равные им неотрицательные числа. Значения от 2**(N-1)-1 до 2**N-1 (то есть те, у которых старший бит равен 1) означают отрицательные числа от -2**(N-1) до -1 соответственно. Например, в 1 байте (8 бит) это от 0 до 127 и от -128 до -1; в 2 байтах (16 бит) — от 0 до 32767 и от -32768 до -1; и так далее.
N>Во внутреннем использовании компьютера обычно используются фиксированные количества бит в числовых действиях, в современных это в основном 4 или 8 октетов (32 и 64 бита соответственно), реже 1 или 2 байта (8 и 16 бит соответственно). Например, число 123 представляется как 7B, 00 7B, 00 00 00 7B или 00 00 00 00 00 00 00 7B. Аналогично, -120 представляется как 85, FF 85, FF FF FF 85, или FF FF FF FF FF FF FF 85. Для представлений в BER допускается произвольное количество октетов в представлении, но минимально необходимое для представления конкретного числа. Для примеров выше допускаются только однооктетные представления. Аналогично, например, число 987654 может быть представлено в трёх октетах как 0F 12 06, но равное ему представление 00 0F 12 06 уже запрещено. Число 127 ещё представляется как 7F, но 128 — уже как 00 80, потому что представление 80 значит -128, а не 128.
N>В примерах выше все числа были записаны так, что старшие цифры шли раньше в записи. Если их укладывать в память или в поток в том же порядке, получится так называемое big-endian представление ((ссылка)), в котором в октетах с меньшими адресами находятся старшие части числа. Это единственно допустимое представление для BER и потомков. Представление с обратным порядком, так называемое little-endian ((ссылка)), применяется во многих процессорах, как x86, но оно требует перестановки октетов для экспорта или импорта в BER.
N>Описанные правила применяются 1) для представления содержимого целого типа, 2) для представления мантиссы в содержимом вещественного типа (REAL), 3) для представления длины элемента, если она задана в длинной форме. В случае мантиссы в REAL она считается беззнаковой, правила дополнительного кода для отрицательных чисел не используются."
N>Я считаю, что это в разы понятнее, чем "... и число, которое надо вычесть из основного" или "решим уравнение" (которое тут нафиг не сдалось, зато способно отпугнуть 90% читающих). Если же кого-то надо учить таким основам, как двоичное представление чисел, 16-ричная система и т.д., то это надо делать отдельным документом (можно поставить на него ссылку).
Насчет "дополнительного кода": для сведения на английском языке этот называется "two's complement binary number" из чего явно происходит его природа — представление в виде двух чисел. Попробуйте новичку сказать ваш первый абзац, а потом сказать мой вариант — два числа, вычитаемые одно из другого. Я считаю, что мой вариант гораздо ближе и к сути кодирования, и к человеку с его мышлением.
>>>> То есть для кодирования целых чисел в ASN.1 не нужно выполнять вообще никаких действий – просто нужно сохранить их байт за байтом и всё. N>>>Во-первых, что эта фраза делает в секции для real? (см. выще про порядок изложения) Во-вторых, "забыты" проблемы представления нужной длиной. YN>>Тип REAL содержит кодирование целых чисел. Моя статья умышленно построена на объяснении от сложных типов к простым.
N>Да, я уже прокомментировал, что это получилось методологически крайне неудобно. Это как учить первоклашек объяснению, что такое числа, в стиле Бурбаки. Не зря обычно учат от простого к сложному. Обратный подход постоянно порождает несуразности в изложении.
Это уже частное мнение.
>>>> Значение мантиссы числа представляет собой всегда беззнаковое целое. N>>>Не сказано "в представлении в BER", ну ладно, тут стилевой вопрос. YN>>Хм, а в каком ещё "представлении" мантиса может иметь значение отличное от беззнакового целого?
N>В подавляющем большинстве представлений мантисса — нецелое значение, лежащее в диапазоне или 1<=M<b, или 1/b<=M<1, где b — основание системы счисления. Для нормализованных двоичных в IEEE754, например, это первый вариант, при b=2. Представление в BER отличается от них именно что принципиально, и это надо было подчеркнуть.
Вот тут уже вы явно заменяете понятия BER и ASN.1: представление мантиссы в виде целого числа характерно для ASN.1
>>>> Фактически к кодируемому целому числу предъявляется требование: старшие 9 бит закодированного числа не должны все быть равны 1, и не должны все быть равны 0 (старшие 9 бит закодированного числа не должны быть равны между собой). N>>>Звучит как какое-то подводное открытие. На самом деле это требование прописано в X.690 английским по фоновому. YN>>И что, мне отсылать читателя к стандарту? Типа "в вот ещё интересную информацию вы найдёте в X.690 в строке такой-то"?
N>Я про слово "фактически". Им принято вводить выводы, согласующиеся с фактами, но сделанные из ранее изложенного материала, а не другого источника. Если это правило изложено явно, то лучше написать где-то так: "Можно сказать иначе (и это явно сказано в X.690 пункт 8.3.2), что первые 9 бит представления целого числа не могут все совпадать друг с другом; такое совпадение означает, что можно устранить старший октет представления без ущерба для значения представленного числа."
Я написал по другому и смысл от этого остался прежним.
>>>> Если же старшие 9 бит закодированного числа равны 1, то закодированное число отрицательное и может быть перекодировано с применением меньшего числа октетов (при кодировании были добавлены лишние нулевые октеты в вычитаемое число). N>>>Не "может", а обязано быть. Хотя в реальности куча SNMP устройств игнорируют это требования, передавая значения в фиксированном количестве октетов. YN>>Именно "может", ибо я рассказываю про BER. Разберитесь для себя где есть разница между BER и DER.
N>Это Вы разберитесь. Уже BER требует представления целого минимальным количеством октетов, независимо от знака. Процитировать, или сами найдёте? Зато оно почему-то не требует представления *длины* минимальной формой (то есть позволяет, например, 02, 81 02, 82 00 02, и так далее).
Да, здесь уже я подзабыл. Но для целей кодирования фактически применяется глагол "может", так как число закодированное в "длинной" форме по-сути имеет такое же значение как и число в "короткой".
>>>> Зачастую необходимо различать закодированные в одном элементы одного и того же типа, следующие один за другим (например при кодировании типа SET, где порядок вложенных элементов может быть произвольным). Для этого применяют дополнительное кодирование элементов в блоках с новыми, специфичными тегами. Например, типа REAL имеет класс тега UNIVERSAL (00) и номер тега 9. Чтобы логически отличить два подряд идущих значения REAL применяют дополнительное, "обёрточное" кодирование значения. Для этого используют классы тегов кроме класса UNIVERSAL (00). N>>>Во-первых, не все, "кроме UNIVERSAL (00)". Application здесь не годится. Здесь годится context-specific — это однозначно, и для set [of], и для sequence [of]. Private неадекватен для этой цели, потому что фактически означает, что это нечто за пределами спецификации. YN>>Почитайте стандарт: годится всё, кроме UNIVERSAL. Адекватность или неадекватность применения — это вопрос разрабатываемой схемы ASN.1 и выходит за рамки моей статьи.
N>Нет, это вопрос именно в рамках статьи, потому что не надо учить людей с самого начала плохому. Говоря "годится всё, кроме UNIVERSAL", Вы грубо вводите людей в заблуждение. Да, два объекта, один REAL, другой APPLICATION 0, будут различаться. Но два APPLICATION 0 будут путаться, даже если они "в душе" оба REAL! Точно так же как два PRIVATE 0 будут путаться. Но два CONTEXT 0 или невозможны согласно общим правилам ASN.1 (ещё до спускания на уровень BER), или являются грубой ошибкой кодирования. Принципиально тут именно различение тегов, между всеми значениями (в случае SET) или для однозначности разбора (в случае SEQUENCE).
Два CONTEXT 0 очень даже возможны. Просто при разборе значения будет невозможно определить что есть что (как впрочем и с двумя APPLICATION 0 и PRIVATE 0).
N>В случае, если действовать по Вашему примеру (есть SET, внутри два REAL, надо различить, и на побочные эффекты плевать), а почему это UNIVERSAL не годится? Ну написали Вы вместо REAL — INTEGER, всё равно ведь сами разбираете? Различие достигнуто, а каким методом — неважно.
N>Итого: как в анекдоте, или трусы наденьте, или крестик снимите. Или мы используем таки BER для ASN.1, и тогда есть определённые правила, которые нельзя нарушать. Или мы его используем в сферическом вакууме, и тогда нам вообще всё пофиг, где какие типы и почему.
YN>>Как я и написал вопросы составления схем ASN.1 выходят за рамки моей статьи.
N>Но всё равно для статьи надо брать адекватные примеры, даже если не объясняете, почему они взяты. Надеюсь, не нужно объяснять истока этого правила.
Все примеры, описанные в моей статье адекватны и проверены. Ваши претензии были высказаны только к каким-то частям моих высказываний.
Если найдёте некорректный пример — пишите.
N>>>А вот тут волшебным образом появилась какая-то нотация, хотя до того всё время BER назывался ASN.1, но про собственно ASN.1 нотацию не было ни слова. Кстати, тегирование из той же области — не введя описание составного типа, сложно объяснить, зачем оно вообще было нужно. YN>>Здесь я действитель отступил от общего стиля статьи, но только ради того, чтобы дать читателю информацию по совершенно неочевидной теме, в которой делают большинство ошибок даже "продвинутые" программисты. Эта информация будет нужна только в специфичных случаях.
N>Это Вы так решили, что она "будет нужна только в специфичных случаях"? А почему? Обычный метод работы с ASN.1 таки начинается с составления схемы данных.
Статья рассматривает исключительно только вопросы кодирования. Отступление было необходимо так как более наглядно показывало сущность "tagged values".
N>>>Резюмирую.
N>>>1. Автор пытался совместить в одной статье "сидение на двух стульях". Причём один из этих стульев — движущегося велосипеда, а второй — стоматологическое кресло. Попытка совмещения практического руководства "как читать непонятную хрень, от которой известен только её hexdump" или "повторим работу BER dumper вручную" с общим описанием принципов в одном тексте изначально проблемна. YN>>Вы выразитесь менее иносказаетльно — какие задачи я тут решал то по вашему мнению?
N>Я дальше всё описал.
N>[...]
YN>>Очень ценю ваши подробные комментарии! Правда, спасибо! И если считаете себя специалистом в области ASN.1 то напишите свою чудесную статью, увеличьте количество информации по ASN.1!
N>У меня есть, например, заметки (в формате трактата) о протоколах и форматах вообще. ASN.1 там частность, на которой я не хотел заостряться, и вообще там предполагался другой стиль — не описание с азов, а максимальная концентрация пищи для инженерного ума, для помощи выбора решения на всех уровнях. Насчёт только ASN.1 я подумаю, но считаю вероятность реализации — сильно меньше половины. Всё-таки его использование чем дальше, тем меньшую долю составляет от всего, что есть в мире, и в моей практике он как-то не встречался ни разу, кроме суррогатов в виде SNMP. N>Практически, все случаи, где бы оно могло применяться, у нас покрыты JSON'ом.
У меня вопрос: эту вашу статью кто-нибудь читает? Уверен, что там написаны какие-то нужные факты, но я открыл первую часть и... Стили трафика? Изохронный? Наливной стиль трафика? Подложки, которые сгруппированы в классы? Вы стандартные книги по описанию протоколов читали или сами придумываете?
Что-то мне подсказывает, что если бы эти лекции и были кому-нибудь прочитаны пользы от них было бы мало. "Концентрация пищи для инженерного ума" тут чрезмерная Знаете, где-то услышал, что наиболее знающий человек это тот, который умеет просто объяснять самые сложные вещи. Вы наверное знающий, но с объяснениями на мой взгляд у вас туго.
Ну давайте попробую. Я даже никуда в сеть не заглядываю: