Здравствуйте, vdimas, Вы писали:
V>ASN.1 компилятор в кодировку BER можно накатать за неделю, только я так и не понял этого странного довода. Затраты на собственную разработку инструментария (даже наколенного) окупаются только при большом масштабированнии, например внутри большой фирмы. Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500)
Насколько я помню, отображение ASN.1 в различные языки программирования не стандартизированны. Поэтому каждый производитель ASN.1 компиляторов предоставляет собственный набор классов, которые будут использоваться в полученном из ASN.1 описания коде. Т.о. покупая чей-то ASN.1 компилятор разработчик подсаживается на иглу этого производителя. Временами это может напрягать
Если я правильно помню, то не проблема найти свободный и бесплатный ASN.1 компилятор, который поддерживает BER. А вот с PER уже ситуация была сложнее.
А с остальными доводами об актуальности ASN.1 в наше время я согласен.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pzz, Вы писали:
C>>Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов. Pzz>Насколько я понял, они там вполне универсальны, и позволяют разбирать более-менее любые структуры данных, описанные ASN'ом.
Разные кодировки оно точно не поддерживает.
Pzz>>>Если ASN.1 пойдет в топку, он прихватит с собой SSL/TLS, SNMP, LDAP, ... C>>ASN.1 уже в топке, де-факто. В этих протоколах он остался просто как исторический артефакт. Pzz>Ну не скажите. Joost, например, использует внутри себя ASN.1 для описания своих протоколов.
Ну так и CORBA местами тоже осталась. Но в целом индустрия на них забила.
Здравствуйте, netch80, Вы писали:
N>Засовывать же в железяку с мегабайтом оперативки поддержку OSI или скомпилированный ASN.1 парсер — мне, честно говоря, жалко эту железяку: для неё есть значительно больше полезных применений.
Про OSI согласен, про ASN.1 — нет. Во-первых, для конкретных протоколов (т.е. оперирующими весьма ограниченными наборами типов) готовый ASN.1 парсер получается весьма и весьма небольшим. Во-вторых, существуют как минимум 2 способа построения ASN.1-парсера:
1. жестко зашитый код сериализации/десериализации
2. работа по метаданным (т.к. любая описанная в ASN.1 конструкция — суть композиция весьма конечного кол-ва базовых типов + ограничений)
Для небольших протоколов неплохо подходит способ №1, если же мы имеем требования поддержки кучи протоколов на миниатюрном футпринте, то можно использовать способ №2. (Это будет всё равно гораздо экономнее, чем такое же сборище разномастных протоколов, или даже родственных по технологии протоколов, например на основе XML)
Здравствуйте, vdimas, Вы писали:
V>ASN.1 компилятор в кодировку BER можно накатать за неделю, только я так и не понял этого странного довода. Затраты на собственную разработку инструментария (даже наколенного) окупаются только при большом масштабированнии, например внутри большой фирмы.
Куда чего масштабировать? Я не очень понимаю.
V>Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500)
А для XML — бесплатно. И с открытыми исходниками.
C>>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. V>Мдее... я уверен, что стандарт BER-кодировки лично ты осилишь за 10 мин, и меньше чем за час накатаешь парсер какого-нить простейшего протокола (текстовый чат в T120-семействе, например) в этой кодировке безо-всяких "чёрных ящиков", то бишь без компиляторов.
А PER? Или DER.
V>В общем, стоило взглянуть на проблему хоть одним глазком, прежде чем делать столь громкие утверждения. ASN.1 гораздо более распространён, чем ты думаешь: V>http://asn1.elibel.tm.fr/en/uses/index.htm — наиболее популярные применения V>http://asn1.elibel.tm.fr/en/uses/rfc.htm — список одних лишь только стандартов семейства RFC, описанных на базе ASN.1 (а сколько еще не-RFC?)
Это ерунда, нишевые применения. Ты же понимаешь, что список только применения того же XML растянется на мегабайты. Про HTTP я вообще молчу.
C>>CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное. V>Она пошла в топку совсем по другой причине — по причине медленного становления как "mature" стандарта, почему так получилось — отчасти я упомянул в предыдущем посте, разрабатывать свой бинарный протокол с 0-ля — это было очень большой ошибкой, т.к. в бинарных протоколоах (вот новость) очень много тонких моментов.
GIOP, AFAIR, не менялся особо. Да и не сложный он в CORBA, не в нём дело.
CORBA умерла из-за своей переусложнённости и отсутствии фокуса. Например, в первых стандартах CORBA предполагалось, что IORы — это непрозрачные ссылки. Чтобы сравнить два IORа — требуется сетевой вызов. Решение не очень хорошее, но это было обосновано идеологическими причинами — созданием полностью прозрачной распределённой среды. Но в последующих стандартах про это просто забыли и забили.
А ещё в CORBA совсем никак с работой в реальных условиях — в гетерогенных сетях с высокой латентностью и кучей файрволов. Дальше локалки CORBA живёт с большим трудом.
C>>Не нужны в IT такие "общие теории всего". V>Извини, но это отдаёт поверхностностью. Дотнет и Ява — гораздо более "общая теория всего", однако они полезны именно как сборник хорошо взаимодействующих частностей.
Нет, Java/.NET — это просто языки с хорошими библиотеками. И самое главное — их не надо самому реализовывать.
C>>Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак) и язык HTML. V>И GSM, и 802.xx и еще тонна популярных стандартов.
GSM — это уже к телекомщикам. 802.xx — к железячникам.
Здравствуйте, eao197, Вы писали:
E>Насколько я помню, отображение ASN.1 в различные языки программирования не стандартизированны. Поэтому каждый производитель ASN.1 компиляторов предоставляет собственный набор классов, которые будут использоваться в полученном из ASN.1 описания коде. Т.о. покупая чей-то ASN.1 компилятор разработчик подсаживается на иглу этого производителя. Временами это может напрягать
Мы тут все забываем еще об одном моменте. Например, написать простейший SUX XML-парсер может и легко, но помимо этого нужен будет код, который конвертирует текстовое представление в типизированное и распихивает по прикладным структурам данных, точно так же нужен код, который из своих структур порождает XML. В случае ASN.1 мы уже имеем код, который выполняет всю эту работу, причём куда как более безошибочно.
E>Если я правильно помню, то не проблема найти свободный и бесплатный ASN.1 компилятор, который поддерживает BER. А вот с PER уже ситуация была сложнее.
Здравствуйте, vdimas, Вы писали:
N>>Хотя некоторые силы в IETF'е пытаются упорно склонять в сторону TCP (меня особенно посмешили последние версии CoMedia drafts, в которых по TCP предполагалось пускать весь RTP).
V>Да ты знаешь... При обычном деджиттере на 100-200мс у нас по VPN неплохо всё работало с серваком на другом конце Земли. Потому как другого способа пробить их каскад NAT-ов не было, RTP никак не жил.
Да ты знаешь... почему-то с помощью портовского/iptel'овского rtpproxy я успешно пробиваю на практике любые каскады NAT'ов, и условий к этому совсем немного — 1) чтобы тот кто за NAT послал хотя бы один пакет с любого из портов (RTP, RTCP), 2) чтобы он использовал один и тот же адрес (хост:порт) для приёма и передачи. ~99% конечных юзерских UA'шек эти условия соблюдают, и сервера (софтсвичи) тоже, и проблемы с NAT нет.
STUN, заметь, мне тут не нужен — концептуально он полная дрянь. Если вдруг суметь исправить все NAT'ы чтобы они были и конусовыми, и держали трансляции подолгу — может, и будет работать. Местами.
А если у вас "работало" — это до первого затыка. Видимо, кроме NAT'ов остальные сетевые условия были слишком идеальные. Передавать голос поверх потока — диверсия, потому что voip — трафик не наливной, а изохронный.
V> В общем, проблема RTP в том, что он может не жить (и часто не живёт) там, где живёт TCP.
Чушь какая. Во-первых, RTP поверх TCP тоже может жить (есть RFC на это), так что не надо тут путать уровни. Во-вторых, UDP (который тут надо подставить вместо RTP) и TCP проходят NAT'ы и файрволлы совершенно одинаково по результатам. Ну а если Вы затуннелировали IP уровень поверх TCP потока — это тем более не "не живёт там, где живёт TCP".
V> (А ты думаешь, отчего я в той ветке про протоколы на весь IP взъелся? Разве осишным сеткам нужны были бы STUN да ICE? Разве там прохождение пакетов зависит от типа обслуживания? То-то...)
Если Вы имеете в виду то, что удлиняемый адрес является частичным избавлением от необходимости NAT — да, можно частично согласиться. Хотя IPv6 предлагает более простое решение (топорное, но работающее легче, чем подходы OSI). Но есть ещё как минимум необходимость сокрытия внутренней структуры — и тут NAT является самым прямым решением.
Что такое "тип обслуживания" — я не понял. Это что-то OSIшное?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, eao197, Вы писали:
E>>Насколько я помню, отображение ASN.1 в различные языки программирования не стандартизированны. Поэтому каждый производитель ASN.1 компиляторов предоставляет собственный набор классов, которые будут использоваться в полученном из ASN.1 описания коде. Т.о. покупая чей-то ASN.1 компилятор разработчик подсаживается на иглу этого производителя. Временами это может напрягать :)
V>Мы тут все забываем еще об одном моменте. Например, написать простейший SUX XML-парсер может и легко, но помимо этого нужен будет код, который конвертирует текстовое представление в типизированное и распихивает по прикладным структурам данных, точно так же нужен код, который из своих структур порождает XML. В случае ASN.1 мы уже имеем код, который выполняет всю эту работу, причём куда как более безошибочно.
Ага, ага. Только вот в чём фигня — это он разве что для Python/Perl/Ruby/etc. будет так хорошо выглядеть, потому что там один тип "строки", один штатный "целого числа произвольного размера", "списка данных произвольного содержания" (для sequence of, в котором могут быть числа, строки и так далее, и совершенно не обязательно её состав и размер заранее определён)... А в случае C или C++ его ещё надо связывать с той библиотекой, которая именно в данном проекте выбрана для таких представлений, и структурой классов (чтобы какой-нибудь TStreamedBigInteger происходил от общего TStreamedObject). И вот тут-то весь код парсера ASN.1 пойдёт нафиг, как только правила для данного проекта поменяются.
XML'ный парсер для SAX стиля, при том что соответствующий код надо писать руками — это сделает именно так, как нужно для данного проекта, с использованием именно тех средств, которые нужны именно в нём.
E>>Если я правильно помню, то не проблема найти свободный и бесплатный ASN.1 компилятор, который поддерживает BER. А вот с PER уже ситуация была сложнее.
V>Последние годы полегче: http://lionet.info/asn1c/ V>Под удобной BSD лицензией.
Здравствуйте, vdimas, Вы писали:
V>Мы тут все забываем еще об одном моменте. Например, написать простейший SUX XML-парсер может и легко, но помимо этого нужен будет код, который конвертирует текстовое представление в типизированное и распихивает по прикладным структурам данных, точно так же нужен код, который из своих структур порождает XML.
А зачем? Это далеко не всегда нужно. А когда нужно — выясняется, что байндить не так-то просто из-за того, что многие языки имеют свои понятия о типах.
V>В случае ASN.1 мы уже имеем код, который выполняет всю эту работу, причём куда как более безошибочно.
Угу. А для sed у тебя есть ASN.1-парсер? Мне вот как раз сегодня слегка напильничком надо было XML обработать. xpath+sed+perl+такая-то-матерь — и всё замечательно.
E>>Если я правильно помню, то не проблема найти свободный и бесплатный ASN.1 компилятор, который поддерживает BER. А вот с PER уже ситуация была сложнее. V>Последние годы полегче: http://lionet.info/asn1c/ V>Под удобной BSD лицензией.
Целый один проект. Прогресс.
Кстати, нашёл недавно вообще зверскую вещь: http://parabix.costar.sfu.ca/ — разбор XML с помощью SSE-инструкций (!!!). Работает примерно в 10 раз быстрее libxml...
V>>Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500) C>А для XML — бесплатно. И с открытыми исходниками.
Бесплатно что именно? Помимо самого парсера XML тебе нужен некий маппер на твои прикладные структуры + валидатор, вон для дотнета XML-сериализация бесплатна, но уж очень и очень ограничена, ввиду чего я постоянно вижу рукописный маппинг (да и сам неоднократно грешен). Тут рядом я давал ссылку на бесплатный опенсорсовый ASN.1 под BSD лицензией, напомню, что помимо собственно разбора/формирования потока, парсер/сериализатор полностью осуществляет маппинг и валидацию, т.е. использование в клиентском коде более чем простое.
C>>>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. V>>Мдее... я уверен, что стандарт BER-кодировки лично ты осилишь за 10 мин, и меньше чем за час накатаешь парсер какого-нить простейшего протокола (текстовый чат в T120-семействе, например) в этой кодировке безо-всяких "чёрных ящиков", то бишь без компиляторов. C>А PER? Или DER.
PER — это высший пилотаж, используется там, где никакими текстовыми стандартами (и даже многими самопальными бинарными) и близко пахнуть не должно. Ибо имеем оптимизированный поток бит, а не байт, и для оптимизации компилятору нужна практически вся информация о кодируемом протоколе. Конечно, на коленке за неделю фиг сделаешь, так что отсылаю туда же — в готовый опенсорс.
V>>В общем, стоило взглянуть на проблему хоть одним глазком, прежде чем делать столь громкие утверждения. ASN.1 гораздо более распространён, чем ты думаешь: V>>http://asn1.elibel.tm.fr/en/uses/index.htm — наиболее популярные применения V>>http://asn1.elibel.tm.fr/en/uses/rfc.htm — список одних лишь только стандартов семейства RFC, описанных на базе ASN.1 (а сколько еще не-RFC?) C>Это ерунда, нишевые применения. Ты же понимаешь, что список только применения того же XML растянется на мегабайты. Про HTTP я вообще молчу.
Ну да, управление полётами и управляемой посадкой, автомобилестроение, безопасность, сервисы сотовой связи и т.д. и т.п. — это весьма нишевые применения. Однако, всё гораздо проще уже сегодня, есть мапперы со схем XML в ASN.1, так что в любом проекте можешь использовать свой любимый XML, но будь потребность многократного сжатия траффика, ты легко сможешь прыгнуть на бинарный протокол. В какой-то мере на сегодняшний день это всё практически прозрачно и не тема для холи варз.
Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента.
C>>>CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное. V>>Она пошла в топку совсем по другой причине — по причине медленного становления как "mature" стандарта, почему так получилось — отчасти я упомянул в предыдущем посте, разрабатывать свой бинарный протокол с 0-ля — это было очень большой ошибкой, т.к. в бинарных протоколоах (вот новость) очень много тонких моментов. C>GIOP, AFAIR, не менялся особо. Да и не сложный он в CORBA, не в нём дело.
Менялся значительно, в плане кодировок.
C>CORBA умерла из-за своей переусложнённости и отсутствии фокуса.
Фокус в интероперабельности гетерогенных систем. Другого фокуса не было и нет. Большинство стандартных служб CORBA — это лишь стандартизация наиболее востребованных сценариев, ничего более. Никто не заставляет тебя их использовать.
C>Например, в первых стандартах CORBA предполагалось, что IORы — это непрозрачные ссылки. Чтобы сравнить два IORа — требуется сетевой вызов. Решение не очень хорошее, но это было обосновано идеологическими причинами — созданием полностью прозрачной распределённой среды. Но в последующих стандартах про это просто забыли и забили.
Немного не так, масштабируемость не подкосили. Сейчас IOR можно сравнить на клиенте, но все реализации при неудачном сравнении запрашивают сервак, т.е. они просто внесли некую оптимизацию в процесс сравнения. А вообще странный у тебя аргумент, зачём вообще сравнивать IOR-ы, не объяснишь? ИМХО, сценарий предположительного их использования не предусматривает сравнения в клиентском коде (может я чего-то упустид? ).
C>А ещё в CORBA совсем никак с работой в реальных условиях — в гетерогенных сетях с высокой латентностью и кучей файрволов. Дальше локалки CORBA живёт с большим трудом.
Это проблема относится не конкретно к CORBA, а вообще к распределённым приложениям. Обратные асинхронные вызовы — зло, это относится к любой современной распределённой среде. Если же ты используешь сервис-ориентированный подход, то CORBA живёт там, например, где живёт собственно TCP (mapping GIOP onto TCP), т.е. далеко за пределами локалки.
C>>>Не нужны в IT такие "общие теории всего". V>>Извини, но это отдаёт поверхностностью. Дотнет и Ява — гораздо более "общая теория всего", однако они полезны именно как сборник хорошо взаимодействующих частностей. C>Нет, Java/.NET — это просто языки с хорошими библиотеками. И самое главное — их не надо самому реализовывать.
CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более.
C>>>Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак) и язык HTML. V>>И GSM, и 802.xx и еще тонна популярных стандартов. C>GSM — это уже к телекомщикам. 802.xx — к железячникам.
И что? И там и там большинство штата — программисты, не хуже чем в "обычной" софтовой конторе.
V>>Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500) C>А для XML — бесплатно. И с открытыми исходниками.
Бесплатно что именно? Помимо самого парсера XML тебе нужен некий маппер на твои прикладные структуры + валидатор, вон для дотнета XML-сериализация бесплатна, но уж очень и очень ограничена, ввиду чего я постоянно вижу рукописный маппинг (да и сам неоднократно грешен). Тут рядом я давал ссылку на бесплатный опенсорсовый ASN.1 под BSD лицензией, напомню, что помимо собственно разбора/формирования потока, парсер/сериализатор полностью осуществляет маппинг и валидацию, т.е. использование в клиентском коде более чем простое.
C>>>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. V>>Мдее... я уверен, что стандарт BER-кодировки лично ты осилишь за 10 мин, и меньше чем за час накатаешь парсер какого-нить простейшего протокола (текстовый чат в T120-семействе, например) в этой кодировке безо-всяких "чёрных ящиков", то бишь без компиляторов. C>А PER? Или DER.
PER — это высший пилотаж, используется там, где никакими текстовыми стандартами (и даже многими самопальными бинарными) и близко пахнуть не должно. Ибо имеем оптимизированный поток бит, а не байт, и для оптимизации компилятору нужна практически вся информация о кодируемом протоколе. Конечно, на коленке за неделю фиг сделаешь, так что отсылаю туда же — в готовый опенсорс.
V>>В общем, стоило взглянуть на проблему хоть одним глазком, прежде чем делать столь громкие утверждения. ASN.1 гораздо более распространён, чем ты думаешь: V>>http://asn1.elibel.tm.fr/en/uses/index.htm — наиболее популярные применения V>>http://asn1.elibel.tm.fr/en/uses/rfc.htm — список одних лишь только стандартов семейства RFC, описанных на базе ASN.1 (а сколько еще не-RFC?) C>Это ерунда, нишевые применения. Ты же понимаешь, что список только применения того же XML растянется на мегабайты. Про HTTP я вообще молчу.
Ну да, управление полётами и управляемой посадкой, автомобилестроение, безопасность, сервисы сотовой связи и т.д. и т.п. — это весьма нишевые применения. Однако, всё гораздо проще уже сегодня, есть мапперы со схем XML в ASN.1, так что в любом проекте можешь использовать свой любимый XML, но будь потребность многократного сжатия траффика, ты легко сможешь прыгнуть на бинарный протокол. В какой-то мере на сегодняшний день это всё практически прозрачно и не тема для холи варз.
Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента.
C>>>CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное. V>>Она пошла в топку совсем по другой причине — по причине медленного становления как "mature" стандарта, почему так получилось — отчасти я упомянул в предыдущем посте, разрабатывать свой бинарный протокол с 0-ля — это было очень большой ошибкой, т.к. в бинарных протоколоах (вот новость) очень много тонких моментов. C>GIOP, AFAIR, не менялся особо. Да и не сложный он в CORBA, не в нём дело.
Менялся значительно, в плане кодировок.
C>CORBA умерла из-за своей переусложнённости и отсутствии фокуса.
Фокус в интероперабельности гетерогенных систем. Другого фокуса не было и нет. Большинство стандартных служб CORBA — это лишь стандартизация наиболее востребованных сценариев, ничего более. Никто не заставляет тебя их использовать.
C>Например, в первых стандартах CORBA предполагалось, что IORы — это непрозрачные ссылки. Чтобы сравнить два IORа — требуется сетевой вызов. Решение не очень хорошее, но это было обосновано идеологическими причинами — созданием полностью прозрачной распределённой среды. Но в последующих стандартах про это просто забыли и забили.
Немного не так, масштабируемость не подкосили. Сейчас IOR можно сравнить на клиенте, но все реализации при неудачном сравнении запрашивают сервак, т.е. они просто внесли некую оптимизацию в процесс сравнения. А вообще странный у тебя аргумент, зачём вообще сравнивать IOR-ы, не объяснишь? ИМХО, сценарий предположительного их использования не предусматривает сравнения в клиентском коде (может я чего-то упустид? ).
C>А ещё в CORBA совсем никак с работой в реальных условиях — в гетерогенных сетях с высокой латентностью и кучей файрволов. Дальше локалки CORBA живёт с большим трудом.
Это проблема относится не конкретно к CORBA, а вообще к распределённым приложениям. Обратные асинхронные вызовы — зло, это относится к любой современной распределённой среде. Если же ты используешь сервис-ориентированный подход, то CORBA живёт там, например, где живёт собственно TCP (mapping GIOP onto TCP), т.е. далеко за пределами локалки.
C>>>Не нужны в IT такие "общие теории всего". V>>Извини, но это отдаёт поверхностностью. Дотнет и Ява — гораздо более "общая теория всего", однако они полезны именно как сборник хорошо взаимодействующих частностей. C>Нет, Java/.NET — это просто языки с хорошими библиотеками. И самое главное — их не надо самому реализовывать.
CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более.
C>>>Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак) и язык HTML. V>>И GSM, и 802.xx и еще тонна популярных стандартов. C>GSM — это уже к телекомщикам. 802.xx — к железячникам.
И что? И там и там большинство штата — программисты, не хуже чем в "обычной" софтовой конторе.
Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Ага, ага. Только вот в чём фигня — это он разве что для Python/Perl/Ruby/etc. будет так хорошо выглядеть, потому что там один тип "строки", один штатный "целого числа произвольного размера", "списка данных произвольного содержания" (для sequence of, в котором могут быть числа, строки и так далее, и совершенно не обязательно её состав и размер заранее определён)...
Значит, протокол такой, в чём отличие от подобной ситуации с XML? Там тоже подобные структуры могуть описываться.
N>А в случае C или C++ его ещё надо связывать с той библиотекой, которая именно в данном проекте выбрана для таких представлений, и структурой классов (чтобы какой-нибудь TStreamedBigInteger происходил от общего TStreamedObject). И вот тут-то весь код парсера ASN.1 пойдёт нафиг, как только правила для данного проекта поменяются.
Во-первых, не проекта, а протокола. Во-вторых, только лишь в кусках кода, оперирующих изменёнными типами полей, т.е. тех частей, где ты используешь эти данные в прикладном коде (например, маппинга на int теперь недостаточно, и везде должен использовать long для интересующего поля). Ну а в-третьих, тоже самое тебя ожидает в случае аналогичного изменения типа даже при использовании XML-протоколов.
Но в любом случае замечание подобного рода применимо к системам на основе C# и Java, например для C++ прикладные типы данных всё-равно определяют через typedef, агрегатные структуры — как шаблонные т.е. изменений в коде клиента — ровно 0. Далее, обход коллекций в C#/Java принято реализовывать через некоторые общепринятые интерфейсы (т.е. не всегда нужна завязка на конретику либы), а в C++ — делать выход на STL алгоритмы. Насчёт Pascal — наверно неудобнее всего, согласен, ни первого, ни второго.
N>XML'ный парсер для SAX стиля, при том что соответствующий код надо писать руками — это сделает именно так, как нужно для данного проекта, с использованием именно тех средств, которые нужны именно в нём.
Открою маленький секрет. Если для C#/Java небходимо полностью подключать базовые (иногда монстрообразные) сборки некоего ASN.1-парсера от некоего производителя, то для C/C++ в случае статической линковки из библиотек возмется лишь самое необходимое, т.е. только те куски, которые реально вызываются в целевом коде (именно с этой целью выход ASN.1-парсера так же лучше оформлять в виде библиотечного модуля, а не вставлять в целевой, т.к. в реальном применении редко протокол используется целиком, приличная часть протокола для одной из сторон используется только как read-only, это очевидно). Я именно это имел вввиду, когда отвечал рядом, что футпринт для железячек в случае небольших протоколов получается очень маленьким.
V>>Мы тут все забываем еще об одном моменте. Например, написать простейший SUX XML-парсер может и легко, но помимо этого нужен будет код, который конвертирует текстовое представление в типизированное и распихивает по прикладным структурам данных, точно так же нужен код, который из своих структур порождает XML. C>А зачем? Это далеко не всегда нужно.
Как это — нужно передавать данные, но не нужно их интерпретировать?
C>А когда нужно — выясняется, что байндить не так-то просто из-за того, что многие языки имеют свои понятия о типах.
Совершенно верно. И на другой стороне может работать система, использующая свою систему типов. Но этот аргумент относится как к XML, валидирующимся по схеме, так и к ASN.1, так и вообще к гетерогенности как таковой. И не надо говорить, что валидировать не надо, это пока экспериментируешь — необязательно, а в конечном коммерческом продукте надо обязательно.
V>>В случае ASN.1 мы уже имеем код, который выполняет всю эту работу, причём куда как более безошибочно. C>Угу. А для sed у тебя есть ASN.1-парсер? Мне вот как раз сегодня слегка напильничком надо было XML обработать. xpath+sed+perl+такая-то-матерь — и всё замечательно.
Почему именно sed? Sed лишь выбранный тобой инструмент (не самый подходящий для обработки XML, согласись), а не цель твоей задачки.
Твоя задача была бы где-то так если уж интересно: XML схема -> ASN.1 описание -> такая-то-матерь -> XER
Но и это перебор, когда есть специально придуманный для этих задач XSLT.
E>>>Если я правильно помню, то не проблема найти свободный и бесплатный ASN.1 компилятор, который поддерживает BER. А вот с PER уже ситуация была сложнее. V>>Последние годы полегче: http://lionet.info/asn1c/ V>>Под удобной BSD лицензией. C>Целый один проект. Прогресс.
Почти стандарт, и идёт как стандартный dev tool в коробках линухов.
Есть еще куча других, например в рамках h323plus, всякие open LDAP, open SSL и т.д., но там обычно реализуется лишь один вид кодировки, требуемый конкретному проекту, так что я просто упомянул проект, сосредоточенный на ASN.1 как таковом.
C>Кстати, нашёл недавно вообще зверскую вещь: http://parabix.costar.sfu.ca/ — разбор XML с помощью SSE-инструкций (!!!). Работает примерно в 10 раз быстрее libxml...
Интересный проект, но пока не вижу как это даст ускорения в случае коротких тагов (до 8-ми символов).
Здравствуйте, netch80, Вы писали:
N>Да ты знаешь... почему-то с помощью портовского/iptel'овского rtpproxy я успешно пробиваю на практике любые каскады NAT'ов, и условий к этому совсем немного — 1) чтобы тот кто за NAT послал хотя бы один пакет с любого из портов (RTP, RTCP), 2) чтобы он использовал один и тот же адрес (хост:порт) для приёма и передачи. ~99% конечных юзерских UA'шек эти условия соблюдают, и сервера (софтсвичи) тоже, и проблемы с NAT нет.
Пробить NAT мало,
N>Если вдруг суметь исправить все NAT'ы чтобы они были и конусовыми, и держали трансляции подолгу — может, и будет работать. Местами.
UDP-трансляции никто по-долгу держать не будет, а в VoIP бывают паузы, однако (ну просто человек слушает, а не говорит), во время которых трафик практически отсутствует. Стандартов на таймауты "удержания" нет, к сожалению.
N>А если у вас "работало" — это до первого затыка. Видимо, кроме NAT'ов остальные сетевые условия были слишком идеальные. Передавать голос поверх потока — диверсия, потому что voip — трафик не наливной, а изохронный.
Спасибо за ликбез.
VoIP трафик к тому же непостоянен, я не зря про деджтитер упомянул, ты видать не обратил внимание. Мы используем шумоподавление, т.е. не шлём пакеты в периоды молчания. Мы анализировали трафик, так вот, даже если беспрерывно без пауз говорить, то всё-равно постоянно шли паузы по 50-150мс, что ослабляет общую нагрузку.
Добавлю.
V>>И всё же, в ситуации если нам надо именно типизированные данные с веб-сервиса получать... Мне что, свой парсер писать? S>Ну, да.
Как-то стрёмно самому. Вот у нас тут десятки структур надо передавать, для использования SOAP нам ни одного лишнего телодвижения делать не надо, просто используем готовый инструментарий прямо из Visual Studio, и развиваем систему по-тихоньку. Не уверен, что мы успевали бы столько надёжно развивать самописные парсеры под новые структуры или изменения существующих.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Cyberax, Вы писали:
V>>>Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500) C>>А для XML — бесплатно. И с открытыми исходниками.
V>Бесплатно что именно? Помимо самого парсера XML тебе нужен некий маппер на твои прикладные структуры + валидатор, вон для дотнета XML-сериализация бесплатна, но уж очень и очень ограничена, ввиду чего я постоянно вижу рукописный маппинг (да и сам неоднократно грешен).
Не очень понятно. Во-первых, для подавляющего количества применений весь "рукописный маппинг" сводится к расстановке атрибутов на членах класса.
Во-вторых, валидация по XSD встроена во все известные мне XML библиотеки.
V> Тут рядом я давал ссылку на бесплатный опенсорсовый ASN.1 под BSD лицензией, напомню, что помимо собственно разбора/формирования потока, парсер/сериализатор полностью осуществляет маппинг и валидацию, т.е. использование в клиентском коде более чем простое.
V>Ну да, управление полётами и управляемой посадкой, автомобилестроение, безопасность, сервисы сотовой связи и т.д. и т.п. — это весьма нишевые применения. Однако, всё гораздо проще уже сегодня, есть мапперы со схем XML в ASN.1, так что в любом проекте можешь использовать свой любимый XML, но будь потребность многократного сжатия траффика, ты легко сможешь прыгнуть на бинарный протокол. В какой-то мере на сегодняшний день это всё практически прозрачно и не тема для холи варз.
V>Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента.
Ну да. Непонятно только, к чему это делать, если найти платформу с отсутствием готового бесплатного парсера и валидатора.
V>Это проблема относится не конкретно к CORBA, а вообще к распределённым приложениям. Обратные асинхронные вызовы — зло, это относится к любой современной распределённой среде. Если же ты используешь сервис-ориентированный подход, то CORBA живёт там, например, где живёт собственно TCP (mapping GIOP onto TCP), т.е. далеко за пределами локалки.
Лично мне ближе ресурсно-ориентированный подход. Он вообще очень хорошо масштабируется в современной распределенной среде.
V>CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более.
Неужели с тех пор, как я смотрел на корбу в последний раз, появились какие-то особо полноценные бесплатные брокеры? Раньше их по какой-то причине продавали за большие деньги.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Как-то стрёмно самому. Вот у нас тут десятки структур надо передавать, для использования SOAP нам ни одного лишнего телодвижения делать не надо, просто используем готовый инструментарий прямо из Visual Studio, и развиваем систему по-тихоньку. Не уверен, что мы успевали бы столько надёжно развивать самописные парсеры под новые структуры или изменения существующих.
Я как бы не против использования SOAP "для передачи структур".
Я против того, чтобы изначально проектировать архитектуру веб-сервиса так, чтобы в нем требовалось как-то "передавать структуры". Точно так же, как в СУБД не принято оперировать с файлами как с потоками, в которые можно засунуть байт и прочитать байт (см. Big Blue C, главу про getch/putch), потому как реальные винчестеры принимают и отдают данные екстентами, в распределенных системах лучше представлять разделяемые данные в виде подходящим образом гранулированного набора ресурсов, которые находятся в достаточно стабильных состояниях. Чем лучше удается определить эту гранулярность и обеспечить стабильность состояний, тем эффективнее работает кэширование.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Не очень понятно. Во-первых, для подавляющего количества применений весь "рукописный маппинг" сводится к расстановке атрибутов на членах класса.
В случае коллекций иногда простой расстановки мало, приходится руками генерить. (про то, как надо работать с типизированными/нетипизированными коллекциями во встроенной XML-сериализации я знаю всё, говорю заранее, чтобы диалог не свелся к ликбезу )
S>Во-вторых, валидация по XSD встроена во все известные мне XML библиотеки.
Ну дык спор оживился после упоминания лёгкости написания собственного простейшего XML-парсера. Я лишь придерживаюсь мнения, что в конечном итоге это ничего не даёт, т.к. всё-равно потребуется полновесный.
V>>Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента. S>Ну да. Непонятно только, к чему это делать, если найти платформу с отсутствием готового бесплатного парсера и валидатора.
V>>Это проблема относится не конкретно к CORBA, а вообще к распределённым приложениям. Обратные асинхронные вызовы — зло, это относится к любой современной распределённой среде. Если же ты используешь сервис-ориентированный подход, то CORBA живёт там, например, где живёт собственно TCP (mapping GIOP onto TCP), т.е. далеко за пределами локалки. S>Лично мне ближе ресурсно-ориентированный подход. Он вообще очень хорошо масштабируется в современной распределенной среде.
Он stateless, от того хорошо масштабируется, и от того имеет свои ограничения. В общем, тут опять попахивает обсуждением stateless vs statefull. Конкретно в нашей задаче по-сути statefull внутри мы общаемся по stateless SOAP веб-сервисам.
V>>CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более. S>Неужели с тех пор, как я смотрел на корбу в последний раз, появились какие-то особо полноценные бесплатные брокеры? Раньше их по какой-то причине продавали за большие деньги.
Сейчас полноценные за очень маленькие для С++ (в районе $50-$100 на разработчика), для дотнета полноценный IIOP.Net — бесплатный.
--------------------------
А вообще, причиной рыночной неразвитости CORBA я считаю так же появление в своё время DCOM. В то время как брокеры и инфраструктуры стоили бешенных денег и были плохо совместимы с т.з. прикладного кода (т.е. поменять серверную часть с одного поставщика CORBA-решения на другой было весьма непросто, с клиентским кодом попроще), DCOM был бесплатен, с можщной поддержкой инфраструктуры (безопасность в т.ч., COM+ весьма удобен для хостинга чего угодно) и т.д. В конечном итоге DCOM успешно сдох в плане популярности, но и развитие CORBA замедлил как минимум на десяток лет. Всё равно потребность в statefull-архитектуре для некоторых классов приложений останется, и всё-равно будет потребность в гетерогенности для таких приложений, так что CORBA будет жить еще очень долго. До тех пор пока все управляемые среды не сольются в экстазе, ликвидировав понятие гетерогенности.
S>Я против того, чтобы изначально проектировать архитектуру веб-сервиса так, чтобы в нем требовалось как-то "передавать структуры".
Но вот есть некое общедоступное расписание занятости некоего ресурса с заведомо ограниченной обслуживаемой ёмкостью, например. Клиенту мы передаём текущее расписание, чтобы он смог выбрать и зарезервировать в нём ячейку. Клиентом может быть как серверное HHTP-приложение (суть общедоступное GUI к сервису шедуллера), так и клиентское VoIP-приложение (т.е. никак не браузер). Как тут без структур в случае клиента?
S>в распределенных системах лучше представлять разделяемые данные в виде подходящим образом гранулированного набора ресурсов, которые находятся в достаточно стабильных состояниях.
Вот если в твоём высказывании "лучше представлять" заменить на "в случае приводимости", то дописать в конце можно "то рекомендуется HTTP, со всей его инфраструктурой кеширования в клиентских браузерах"
S>Чем лучше удается определить эту гранулярность и обеспечить стабильность состояний, тем эффективнее работает кэширование.
Насчёт кеширования как раз и так понятно, непонятно про "обеспечение стабильности состояний". ИМХО, не очень большой класс задач радует нас некритичными к актуальности состояния требованиями.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>Да ты знаешь... почему-то с помощью портовского/iptel'овского rtpproxy я успешно пробиваю на практике любые каскады NAT'ов, и условий к этому совсем немного — 1) чтобы тот кто за NAT послал хотя бы один пакет с любого из портов (RTP, RTCP), 2) чтобы он использовал один и тот же адрес (хост:порт) для приёма и передачи. ~99% конечных юзерских UA'шек эти условия соблюдают, и сервера (софтсвичи) тоже, и проблемы с NAT нет.
V>Пробить NAT мало,
N>>Если вдруг суметь исправить все NAT'ы чтобы они были и конусовыми, и держали трансляции подолгу — может, и будет работать. Местами.
V>UDP-трансляции никто по-долгу держать не будет, а в VoIP бывают паузы, однако (ну просто человек слушает, а не говорит), во время которых трафик практически отсутствует. Стандартов на таймауты "удержания" нет, к сожалению.
Вообще-то voice activity detection, как это называется, по умолчанию отключено практически везде. Именно поэтому.
А если даже включено — нормальная реализация должна слать пустой RTP пакет хотя бы раз в секунду, трафика это много не нагонит по сравнению с реальным потоком, а все таймауты NAT'а побьёт (я вообще нигде не видел их менее минуты).
N>>А если у вас "работало" — это до первого затыка. Видимо, кроме NAT'ов остальные сетевые условия были слишком идеальные. Передавать голос поверх потока — диверсия, потому что voip — трафик не наливной, а изохронный. V>Спасибо за ликбез. :)
Пожалуйста.
V>VoIP трафик к тому же непостоянен, я не зря про деджтитер упомянул, ты видать не обратил внимание. Мы используем шумоподавление, т.е. не шлём пакеты в периоды молчания. Мы анализировали трафик, так вот, даже если беспрерывно без пауз говорить, то всё-равно постоянно шли паузы по 50-150мс, что ослабляет общую нагрузку.
Ослабляет нагрузку чего? Просто на канал? Не вопрос. И с джиттером это мало связано — если пакет пропущен, но следующий приходит с адекватным timestamp, проблем нет — просто пропуск части данных. А теперь рассказываю, что будет, если связь просто пропадёт (например, при перестройке глобального раутинга какое-то время пакеты шли в интерфейс Null0): первый раз TCP сделает перепосылку через последний известный RTT, а второй — уже через три секунды (во всех известных мне реализациях). "А вот вам меч!" И страдайте теперь при мечтаниях про 150 миллисекунд.
).
