Zert 10 июл 2009 в 17:36

ASN.1 и Erlang

2 мин

6.1K

Erlang/OTP *

+28

Комментарии 66

blind 10 июл 2009 в 19:43

наконец-то кто-то написал об asn.1

подозреваю флейм по поводу сабж vs xml ;)

ni4 10 июл 2009 в 20:34

Для ASN.1 есть же XER (не то что подумалось, а xml encoding rules), так что имхо нечего и спорить — из ASN.1 можно получить XML, а вот обратно увы :(

stab 12 июл 2009 в 08:40

Корректней было бы сравнивать языки описания схемы XML (DTD, XSD/WXS, RELAX NG), по ним вполне можно построить эквивалентное ASN.1 представление.

НЛО прилетело и опубликовало эту надпись здесь

stab 13 июл 2009 в 05:07

Вы меня не поняли. XML в данном случае контейнер, ASN.1 язык описания содержимого этого контейнера, DTD, XSD, RELAX NG — тоже. Если языки описывают одно и тоже, можно сделать вывод, что они эквиваленты. Этого уже достаточно, чтобы считать сравнение DTD, XSD, RELAX NG vs ASN.1 корректным, а XML vs ASN.1 — нет.

Бонус: из всего этого следует, что схемы XML теоретически возможно перевести на ASN.1, тогда эти ваши Структуры Данных можно генерировать также, как и прочий эйэсенный хлам.

НЛО прилетело и опубликовало эту надпись здесь

stab 13 июл 2009 в 08:16

С тем, что результат фиговый не поспоришь.

Можно ли где-нибудь в сети посмотреть на спецификации каких-либо нетривиальных форматов описанных на ASN.1, например описание формата Flash-файлов?

НЛО прилетело и опубликовало эту надпись здесь

stab 13 июл 2009 в 13:05

> H.323? :)

На сколько я понял, специфицируются только форматы сообщений, а сами потоковые бинарные данные нет. Есть что-нибудь такое чтобы прям по полочкам от самого абстрактного уровня и до битов? Или ASN.1 для этого не применяется?

НЛО прилетело и опубликовало эту надпись здесь

stab 14 июл 2009 в 04:30

> Не совсем понимаю чего вы конкретно хотите

Я пытаюсь выяснить у носителя языка возможно ли на нём описывать\кодировать данные изначально чуждые языку или этот язык вещь в себе. Например, возможно ли описать существующий бинарный формат, и после бинарного кодирования получить файл совместимый с приложениями предназначенными для работы с такими файлами.

Это всё не из праздного любопытства, у нас есть проект-долгожитель, который производит бинарные данные, начинался он на Дельфи ещё при царе Горохе, потом С++, потом понадобилось на сервере с помощью PHP некоторую часть данных обрабатывать, сейчас стало понятно, что было бы не плохо иметь доступ к этим данным из .NET. В итоге, имеется куча маленьких велосипедов для доступа к этим данным и один большой на C++. Если бы можно было на чём-то описать прародителя всех велосипедов и генерировать из него для каждого языка\платформы свою проекцию, сохранив при этом бинарную совместимость — это была бы сказка.

Zert 14 июл 2009 в 04:39

ASN.1 не может генерировать произвольный бинарный формат. Бинарник, полученный из описания в ASN.1 имеет чёткую структуру, и описать уже существующий бинарный протокол, используя ASN.1 не получится.

vlm 9 мар 2010 в 22:14

На самом деле, может. Технология называется ECN.

Zert 10 мар 2010 в 04:26

Что-то никак не могу найти. Можешь ссылкой поделиться?

vlm 10 мар 2010 в 06:54

en.wikipedia.org/wiki/Encoding_Control_Notation

Zert 10 мар 2010 в 08:16

Спасибо, не натыкался раньше

vlm 10 мар 2010 в 09:55

Это потому, что ты смотрел на отсутствующий стандарт X.208. Если бы ты посмотрел X.680+, там бы сразу ECN нашёл.

Zert 13 июл 2009 в 13:46

В Wireshark есть поддержка MPEG Audio, и лежит файл с описанием формата в ASN.1. Но сам поток там не описывается, да и не применяется asn.1 для кодирования потоковых данных.

vlm 9 мар 2010 в 22:15

Применяется. Вернее, рассчитывалось, что может применяться. См. стандарт CER. Компилятор lionet.info/asn1c поддерживает потоковое декодирование.

Zert 10 мар 2010 в 04:26

Не знал, спасибо

Zert 11 июл 2009 в 09:44

Флеймить по этой теме не имеет смысла, так как ниши у XML и ASN.1 разные, хотя и пересекаются в некоторой области, отличной от нуля. Но всё равно, в большинстве случаев надо использовать здравый смысл и выбрать тот инструмент, который лучше других подходит для решения проблемы. Фанатично пытаться повсюду использовать какой-то один формат в ущерб задаче — по меньшей мере глупо.

akzhan 12 июл 2009 в 06:39

JSON is my favourite ;)

Silverity 12 июл 2009 в 05:18

Google Protocol Buffers тоже вполне хороши.

Zert 12 июл 2009 в 05:48

ASN.1 ещё долго не уйдёт со сцены, так что работать с ним надо уметь. PB только что появился и пройдут ещё годы, прежде чем он получит такой же вес, как и ASN.1.

ni4 12 июл 2009 в 09:27

Он походу вобще не уйдет со сцены :) На нем вся криптография в этих всяких интернетах базируется. Как минимум.

Zert 12 июл 2009 в 13:25

Ну всё меняется в этом мире. Мало ли, что ещё придумают.

aryeh 9 ноя 2011 в 11:49

пока что asn.1 никуда не делся. а прошло более 2-х лет :-)

Zert 9 ноя 2011 в 12:49

ASN.1 ещё минимум лет 15 будет жить, а максимум — неизвестно сколько.

egorinsk 12 июл 2009 в 05:53

Гм, в Perl/PHP все проще, это встроенная функция pack/unpack (ну или serialize для эстетов) :)

Zert 12 июл 2009 в 05:56

Это совсем разные вещи.
Аналог pack/unpack в ерланге — term_to_binary/binary_to_term.

uglock 12 июл 2009 в 06:27

Эх… Для SEQUENCE'а из трех полей ASN понятен. Но в разборе какого-нибудь CMS увязнуть проще некуда. Хотя скорость и экономия памяти приличная.

Zert 12 июл 2009 в 06:33

А зачем для CMS тогда использовать ASN.1?

uglock 12 июл 2009 в 06:37

en.wikipedia.org/wiki/Content_management_system
!=
en.wikipedia.org/wiki/Cryptographic_Message_Syntax

А последний именно что ASN encoded.

Zert 12 июл 2009 в 06:43

Я про en.wikipedia.org/wiki/CMS_protocol подумал.
А в разборе Cryptographic Message Syntax что сложного? Можно ещё посмотреть на такие протоколы, как H.248 и H.323, там тоже ASN.1 используется и всё вполне нормально разбирается.

uglock 12 июл 2009 в 06:52

Как много в IT любви к аббревиатурам :)
Разбор не особо сложный — сложно для понимания. Хотя краем глаза глянул на H.323 — тож без поллитры не разберешься :)

Zert 12 июл 2009 в 07:11

Это так сначала кажется, что сложно. Когда начинаешь использовать — становится просто и понятно.

pwlnw 12 июл 2009 в 12:32

Ага, то-то в линуксе и большинстве сетевых устройств NAT h.323 представляет из себя эвристику, которая в общем случае не работает, а работает только с определенными опциями.
То-то решения для sip-телефония плодятся как грибы.
То-то фирма dlink закрыла поддержку h.323 в шлюзах.

Ну просто очень простой и дружественный протокол.

Zert 12 июл 2009 в 13:22

Казалось бы, причём тут ASN.1?
С таким же успехом можно высказываться против передачи данных с помощью байтов, аргументируя это тем, что от H.323 отказываются, а он передаётся байтами.

pwlnw 12 июл 2009 в 13:51

Можно и дальше расширить: практические примеры показывают, что бинарные протоколы, даже использующие ASN.1, все равно не становятся достаточно удобными и простыми в сопровождении.

А отказываться не надо. Надо внимательно взвешивать технологии при их выборе.

Zert 12 июл 2009 в 14:15

Можете привести эти практические примеры, кроме H.323?

pwlnw 12 июл 2009 в 14:54

Легко: практически все развитые (читай настолько удобные, что не загнулись) протоколы интернета базирующиеся на TCP — НЕ БИНАРНЫЕ.

Zert 12 июл 2009 в 15:03

Когда у человека единственный инструмент — молоток, то всё вокруг кажется гвоздями. Когда единственный инструмент — PHP, всё становится текстовым протоколом.

pwlnw 12 июл 2009 в 15:18

Вместо того, чтобы делать выводы обо мне по моим сегодняшним постам, лучше почитайте RFC — узнаете, что вот уже 40 лет текстовые протоколы двигают Интернет.

Zert 12 июл 2009 в 15:22

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

pwlnw 12 июл 2009 в 16:14

И занятия эти сводятся к унаследованным сетям связи и каналам с крайне низкой пропускной способностью.
А там где нету этих проблем, современные протоколы получаются текстовыми. Взять хотя бы относительно свежий MGCP: казалось бы, те же самые бравые мужи-телефонисты из nortel проектировали, но протокол почему-то вышел текстовым.
С SIP та же история — разрабочик Bell Labs.

Zert 12 июл 2009 в 16:40

А взять хотя бы ещё более свежий H.248/Megaco, так почему-то есть и текстовый, и бинарный формат, как раз в ASN.1.

pwlnw 12 июл 2009 в 16:50

Ну а что там на практике у железок? Оба варианта поддерживаются одинаково хорошо?

Zert 12 июл 2009 в 16:53

Да.
Я вообще не пойму, с какой целью ведётся этот спор. Хотите сказать, что работать с ASN.1 не надо, так как формат плохой? Или то, что бинарные форматы не нужны? Или просто поговорить приспичило?

pwlnw 12 июл 2009 в 17:09

С целью опровергнуть первоначальное утверждение о простоте бинарных форматов.
Ну и бравых мужей помянуть словом бранным.

Zert 12 июл 2009 в 17:16

Я пока не видел опровержений. Если, конечно, не считать подход «мне не нравится — не нужно» достаточной аргументацией.

Кстати, протокол AMQP бинарный :)

pwlnw 12 июл 2009 в 17:24

«слишком многим не нравится — в большинстве случаев не нужен».

Zert 12 июл 2009 в 17:45

Т.е. везде должны использоваться Java, XML, PHP и Windows? Что решения, отличные от мейнстрима, не должны иметь права на жизнь?

pwlnw 12 июл 2009 в 18:00

Плохой пример. Но, да. В такой области как коммуникации — желательно придерживаться общепринятой практики.

Zert 12 июл 2009 в 18:02

Так вот, в телекоммуникациях ASN.1 — общепринятая практика.

pwlnw 12 июл 2009 в 18:30

Ну и пусть. Это дурное воспитание.
А если считать телекоммуникациями еще и Интернет, то объем разработок в этой области гораздо больше разработок перекладывающих байтики связистов. И получается ASN.1 не особо общепринят.