C>Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
Не в курсе как в SIP, а в H323 по каналу "Call Control" можно с вызовом делать что угодно, т.е. при необходимости начать новую процедуру инициализации RTP-сеанса на другом серваке, без обрыва логического соединения. Думаю, в SIP можно делать то же самое, ведь там собственно SIP-канал живёт отдельно от RTP-каналов.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Cyberax, Вы писали:
C>>Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
V>Не в курсе как в SIP, а в H323 по каналу "Call Control" можно с вызовом делать что угодно, т.е. при необходимости начать новую процедуру инициализации RTP-сеанса на другом серваке, без обрыва логического соединения. Думаю, в SIP можно делать то же самое, ведь там собственно SIP-канал живёт отдельно от RTP-каналов.
Здравствуйте, vdimas, Вы писали:
V>Относительно SIP вообще смешно получилось. Session Initiation Protocol, типа производит установление сессии. Для тех кто не в курсе, скажу, что там в 99.99% случаев происходит обмен парой сообщений длиной по сотне байт каждое с целью установления RTP-сессии (RTP живёт поверх UDP, опять же). Где здравый смысл? Зачем устанавливать TCP-сессию перед тем как начать процесс установки UDP-based сессии?
Ну, во-первых, типичное сообщение занимает примерно 500-900 байт.
Во-вторых, насколько я вижу реальность вокруг себя — SIP обычно бегает именно по UDP, а не по TCP. Хотя некоторые силы в IETF'е пытаются упорно склонять в сторону TCP (меня особенно посмешили последние версии CoMedia drafts, в которых по TCP предполагалось пускать весь RTP).
Но если SIP'овые сообщения перестанут влезать в один пакет — таки без TCP или SCTP будет не обойтись.
V>В общем, потоковый транспортный протокол в системах типа запрос-ответ смотрится малость неуклюже, сливая многократно аналогичной системе, построенной на близком по характеру транспортном протоколе без установления связи. (Сразу оговорюсь, что к HTTP это не может относиться хотя бы из-за произвольного объема передаваемых в обе стороны данных)
Чушь. Не из-за произвольного объёма, а из-за ориентации на наливной характер данных (не знаю, как тут лучше перевести bulk). Поверх RTP тоже можно гнать произвольные объёмы, но если важнее скорость доставки, а не потери. HTTP ориентирован на наливной трафик — которому лучше помедленнее, но без потерь и сбоев. SIP сигнализация — на управляющий трафик. Это три основных и принципиально несовместимых типа трафика, и странно, что Вы вместо адекватных обозначений вспоминаете что угодно, но не их.
Здравствуйте, vdimas, Вы писали: V>И как REST соотносится с веб-сервисами?
Читать книгу издательства O'Reilly "RESTful Web Services" V> ИМХО, это понятия из разной области совершенно. Большинство фич HTTP веб-сервисы не используют, ибо эти фичи к задаче транспортировки сообщений не применимы по принципиальным соображениям.
Ты, наверное, несправедливо сужаешь термин "веб-сервисы" до "SOAP web services". Хороший веб сервис не занимается "задачей транспортировки сообщений", он должен заниматься задачей управления ресурсами. Именно это я имел в виду, когда написал
Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста.
V>Проще гораздо, т.к. ты компилятору ASN.1 скармливаешь описание формата, на выходе получаешь готовый парсер. Это что-то вроде регекспов для текста, только гораздо мощнее (значительно больший класс грамматик захватывает).
А потом неясно, как этот парсер куда подключать и что делать с его результатами.
Здравствуйте, Sinclair, Вы писали:
V>>И как REST соотносится с веб-сервисами? S>Читать книгу издательства O'Reilly "RESTful Web Services" V>> ИМХО, это понятия из разной области совершенно. Большинство фич HTTP веб-сервисы не используют, ибо эти фичи к задаче транспортировки сообщений не применимы по принципиальным соображениям. S>Ты, наверное, несправедливо сужаешь термин "веб-сервисы" до "SOAP web services".
Я не сужаю, я именно его и имею ввиду.
S>Хороший веб сервис не занимается "задачей транспортировки сообщений", он должен заниматься задачей управления ресурсами. Именно это я имел в виду, когда написал S>
Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
И всё же, в ситуации если нам надо именно типизированные данные с веб-сервиса получать... Мне что, свой парсер писать? SOAP мне нравится тем, что это транспорт удалённого вызова процедур, не требующий выделенной инфраструктуры, даже банального отдельного TCP порта, ибо клиенты не любят открывать иные сервисы, кроме 80-го TCP. (Всё остальное мне в нём решительно не нравится, но упомянутая фича своим приоритетом давит многие возражения)
V>>Проще гораздо, т.к. ты компилятору ASN.1 скармливаешь описание формата, на выходе получаешь готовый парсер. Это что-то вроде регекспов для текста, только гораздо мощнее (значительно больший класс грамматик захватывает).
N>А потом неясно, как этот парсер куда подключать и что делать с его результатами.
Примерно туда же подключать, куда и парсер XML, и примерно то же делать с результатами, с той лишь разницей, что вместо нетипизированного дерева из XML nodes ты получаешь типизированные и валидированные структуры на выходе. В общем, выполняет бинарную сериализацию/десериализацию + валидацию на обоих сторонах.
ASN.1 компиляторы для C# генерят либо исходники, либо готовые сборки, которые подключаешь и используешь в своей программе. Т.е. часть структур данных ты описываешь, не на C#, а на ASN.1, притом что большой класс задач валидирования описывается тобой декларативно.
Кстати, разработчики ASN.1 ругают CORBA-комитет за то, что они разрабтали собственный "велосипедик" GIOP (тоже бинарный протокол), вместо того, чтобы воспользоваться готовым ASN.1 в котором прописать пару служебных структур (профайлы) и пару сообщений для удалённого вызова методов. В результате GIOP болеет многими детскими болезнями до сих пор (особенно в плане кодировок строк, big-endians, плохая совместимость протоколов ранних версий и т.д.), что не есть хорошо, ибо GIOP в CORBA — это уровень №0 всей инфраструктуры. Более того, сама инфраструктура предполагает очень и очень экономный подход в плане сетевого трафика (среди систем удалённого вызова методов объектов — самая экономная на сегодня), но прикол в том, что взяв за основу ASN.1 PER, можно было сделать еще гораздо эффективнее. Опять же — расширяемость. GIOP-сериализация нерасширяема на сегодня, в том плане, что эту расширяемость нельзя задать декларативно в IDL, можно подставлять свои самописные хендлеры типов в CORBA-платформы некоторых производителей, но нет ни стандартов, ни в итоге совместимости этих приблуд (что ведет к потере цели использования самой CORBA)
N>Чушь. Не из-за произвольного объёма, а из-за ориентации на наливной характер данных (не знаю, как тут лучше перевести bulk). Поверх RTP тоже можно гнать произвольные объёмы, но если важнее скорость доставки, а не потери. HTTP ориентирован на наливной трафик — которому лучше помедленнее, но без потерь и сбоев. SIP сигнализация — на управляющий трафик. Это три основных и принципиально несовместимых типа трафика, и странно, что Вы вместо адекватных обозначений вспоминаете что угодно, но не их.
Потому что вместо того, чтобы просто упомянуть один из 5-ти уровней транспортного обслуживания из OSI , мы имеем по сути только 2 (из них один порой обкладывается TOSами и QOSами, но суть не меняется). А замечания твои и так как бы понятны, просто не будешь же каждый раз писать столько слов об известном каждому.
Кстати, интересный факт вспомнил:
N>Хотя некоторые силы в IETF'е пытаются упорно склонять в сторону TCP (меня особенно посмешили последние версии CoMedia drafts, в которых по TCP предполагалось пускать весь RTP).
Да ты знаешь... При обычном деджиттере на 100-200мс у нас по VPN неплохо всё работало с серваком на другом конце Земли. Потому как другого способа пробить их каскад NAT-ов не было, RTP никак не жил. В общем, проблема RTP в том, что он может не жить (и часто не живёт) там, где живёт TCP. (А ты думаешь, отчего я в той ветке про протоколы на весь IP взъелся? Разве осишным сеткам нужны были бы STUN да ICE? Разве там прохождение пакетов зависит от типа обслуживания? То-то...)
Здравствуйте, vdimas, Вы писали:
S>>Ты, наверное, несправедливо сужаешь термин "веб-сервисы" до "SOAP web services". V>Я не сужаю, я именно его и имею ввиду.
Я пять постингов назад писал, что есть не-SOAP веб сервисы. Так что всё-таки сужаешь. S>>Хороший веб сервис не занимается "задачей транспортировки сообщений", он должен заниматься задачей управления ресурсами. Именно это я имел в виду, когда написал S>>
Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
V>И всё же, в ситуации если нам надо именно типизированные данные с веб-сервиса получать... Мне что, свой парсер писать?
Ну, да. V> SOAP мне нравится тем, что это транспорт удалённого вызова процедур,
Ага. Именно тем он и отвратителен, что сделан для удаленного вызова процедур. Сама концепция удаленного вызова процедур — зло. Есть ситуации, когда без нее не обойтись, но лучше стараться проектировать так, чтобы это было не надо.
Характерный пример — google maps vs MapPoint. Карты гугла рулят (как и live maps от MC), а маппоинт — сосет. Именно потому, что он СОАП — даже если бы его сделали бесплатным, никто бы не стал пользоваться столь неудобной и медленной инфраструктурой. V>не требующий выделенной инфраструктуры, даже банального отдельного TCP порта, ибо клиенты не любят открывать иные сервисы, кроме 80-го TCP. (Всё остальное мне в нём решительно не нравится, но упомянутая фича своим приоритетом давит многие возражения)
Ну, про тех, кто еще и требует отдельного порта, мы вообще здесь не говорим. Они живут в другой реальности
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>ASN.1 компиляторы для C# генерят либо исходники, либо готовые сборки, которые подключаешь и используешь в своей программе. Т.е. часть структур данных ты описываешь, не на C#, а на ASN.1, притом что большой класс задач валидирования описывается тобой декларативно.
Нафиг его.
Почти все современные успешные технологии обладают тем свойством, что средства для них можно разрабатывать итеративно. Минимальный SAX-парсер для XML пишется за час на коленке. Более сложный — за день. С разрешением entities, кодировками — за неделю. С поддержкой DOM — уже месяцы. Простейший парсер или клиент для HTTP пишется за час. Более сложный, с поддержкой redirect'ов — за день. И т.д.
Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное.
Не нужны в IT такие "общие теории всего".
Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак) и язык HTML.
Здравствуйте, Cyberax, Вы писали:
C>Почти все современные успешные технологии обладают тем свойством, что средства для них можно разрабатывать итеративно. Минимальный SAX-парсер для XML пишется за час на коленке. Более сложный — за день. С разрешением entities, кодировками — за неделю. С поддержкой DOM — уже месяцы. Простейший парсер или клиент для HTTP пишется за час. Более сложный, с поддержкой redirect'ов — за день. И т.д.
C>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное.
C>Не нужны в IT такие "общие теории всего".
C>Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак)
С TCP/IP то же самое. Linux где-то до 1.3.* не умел обрабатывать ICMP. Можно реализовать TCP без масштабируемых окон, без SACK, тонкого flow control (даже без slow start; про Reno/Vegas/NewReno/etc. и не вспоминаем). Можно сделать в раутинговой таблице понимание двух записей (сеть на ближайшем эзернете плюс default).
Кстати, и про ASN.1 я бы так не сказал. Ничто не мешает выпустить из виду некоторых редких зверей вроде SET OF. Или например CER и DER — они ведь были придуманы не только ради установления единственно возможного представления (чтобы его можно было потом побайтово сравнить), но и для того, чтобы не нужно было парсить всякие chunked представления (забыл, как они в BER зовутся). Но масштаб общей базы, которую нужно понимать, действительно слишком велик — один компилятор текстового представления чего стоит.
Но польза от минимальных реализаций технологий на самом деле немного не в этом.:) Сейчас, когда носителей данных на ближайшей раскладке меньше чем на 4.7GB трудно найти — минимальность реализации не важна. У кого много ресурсов — тот сможет взять готовую библиотеку для Java и подключить её.:) Важно то, как оно лезет в embedded условия. Вот тут и начинается цирк — впихнуть в несколько килобайт минимальный HTTP сервер не проблема, а про IP вообще молчу — если железяка будет уметь TCP на уровне RFC793 и не выше, она всё равно будет способна отдать свою морду управления. Засовывать же в железяку с мегабайтом оперативки поддержку OSI или скомпилированный ASN.1 парсер — мне, честно говоря, жалко эту железяку: для неё есть значительно больше полезных применений.
SIP в этом плане, кстати, тоже не слишком удачен — очень много странных требований, которые вроде бы и мелочи, но попробуй наруши — обязательно с кем-то не согласуешься.
Здравствуйте, Cyberax, Вы писали:
C>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное.
На самом деле, нет. OpenSSL трахается с ASN'ом посредством Сишных макросов, а не компилятора. Думаю, что первая версия комплекта этих макросов была где-то за пару дней и написана.
Если ASN.1 пойдет в топку, он прихватит с собой SSL/TLS, SNMP, LDAP, ...
Здравствуйте, Pzz, Вы писали:
C>>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку. CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное. Pzz>На самом деле, нет. OpenSSL трахается с ASN'ом посредством Сишных макросов, а не компилятора. Думаю, что первая версия комплекта этих макросов была где-то за пару дней и написана.
Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов.
Pzz>Если ASN.1 пойдет в топку, он прихватит с собой SSL/TLS, SNMP, LDAP, ...
ASN.1 уже в топке, де-факто. В этих протоколах он остался просто как исторический артефакт.
Здравствуйте, Cyberax, Вы писали:
Pzz>>На самом деле, нет. OpenSSL трахается с ASN'ом посредством Сишных макросов, а не компилятора. Думаю, что первая версия комплекта этих макросов была где-то за пару дней и написана. C>Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов.
Насколько я понял, они там вполне универсальны, и позволяют разбирать более-менее любые структуры данных, описанные ASN'ом.
Pzz>>Если ASN.1 пойдет в топку, он прихватит с собой SSL/TLS, SNMP, LDAP, ... C>ASN.1 уже в топке, де-факто. В этих протоколах он остался просто как исторический артефакт.
Ну не скажите. Joost, например, использует внутри себя ASN.1 для описания своих протоколов.
Здравствуйте, Pzz, Вы писали: C>>Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов. Pzz>Насколько я понял, они там вполне универсальны, и позволяют разбирать более-менее любые структуры данных, описанные ASN'ом.
Если бы это было так, никаких компиляторов ASN.1 было бы не надо. Pzz>>>Если ASN.1 пойдет в топку, он прихватит с собой SSL/TLS, SNMP, LDAP, ... C>>ASN.1 уже в топке, де-факто. В этих протоколах он остался просто как исторический артефакт. Pzz>Ну не скажите. Joost, например, использует внутри себя ASN.1 для описания своих протоколов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>>Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов. Pzz>>Насколько я понял, они там вполне универсальны, и позволяют разбирать более-менее любые структуры данных, описанные ASN'ом. S>Если бы это было так, никаких компиляторов ASN.1 было бы не надо.
Компилятор нужен для тех, кто хочет писать на настоящем ASN.1, а не на openssl'ных макросах странного вида.
Здравствуйте, Cyberax, Вы писали:
C>Почти все современные успешные технологии обладают тем свойством, что средства для них можно разрабатывать итеративно. Минимальный SAX-парсер для XML пишется за час на коленке. Более сложный — за день. С разрешением entities, кодировками — за неделю. С поддержкой DOM — уже месяцы. Простейший парсер или клиент для HTTP пишется за час. Более сложный, с поддержкой redirect'ов — за день. И т.д.
ASN.1 компилятор в кодировку BER можно накатать за неделю, только я так и не понял этого странного довода. Затраты на собственную разработку инструментария (даже наколенного) окупаются только при большом масштабированнии, например внутри большой фирмы. Купить однопользовательскую версию практически любого инструмента сейчас куда как дешевле, чем потратить неделю собственного труда. (инструменты в среднем стоят $50-$500)
C>Для ASN.1 такое невозможно. Нужен сразу полный компилятор, который является для пользователя "чёрным ящиком". Поэтому ASN.1 пошёл в топку.
Мдее... я уверен, что стандарт BER-кодировки лично ты осилишь за 10 мин, и меньше чем за час накатаешь парсер какого-нить простейшего протокола (текстовый чат в T120-семействе, например) в этой кодировке безо-всяких "чёрных ящиков", то бишь без компиляторов.
В общем, стоило взглянуть на проблему хоть одним глазком, прежде чем делать столь громкие утверждения. ASN.1 гораздо более распространён, чем ты думаешь: http://asn1.elibel.tm.fr/en/uses/index.htm — наиболее популярные применения http://asn1.elibel.tm.fr/en/uses/rfc.htm — список одних лишь только стандартов семейства RFC, описанных на базе ASN.1 (а сколько еще не-RFC?)
Бинарные протоколы были, есть и будут, но крайне глупо разрабатывать их с 0-ля. ASN.1 даёт БАЗУ для бинарных протоколов, в которой уже решена куча моментов. Преимущество еще в том, что воспользовавшись этой базой, станут доступны многие готовые и отлаженные кодировки, которые различаются как по трафику, так и по требованию к быстродействию и объёму кода (простейшую BER-кодировку реализуют большинство датчиков современных автомобилей, так что если ты владеешь современным авто, то твоё заявление с большой вероятностью обретает оттенок пикантности ). Есть еще и XER-кодировка, думаю ты догадался по названию, что это такое.
C>CORBA, кстати, тоже в топку пошла — так как попыталась объять необъятное.
Она пошла в топку совсем по другой причине — по причине медленного становления как "mature" стандарта, почему так получилось — отчасти я упомянул в предыдущем посте, разрабатывать свой бинарный протокол с 0-ля — это было очень большой ошибкой, т.к. в бинарных протоколоах (вот новость) очень много тонких моментов.
C>Не нужны в IT такие "общие теории всего".
Извини, но это отдаёт поверхностностью. Дотнет и Ява — гораздо более "общая теория всего", однако они полезны именно как сборник хорошо взаимодействующих частностей. CORBA — примерно то же самое, в реальном проекте нужна менее чем 10%-ая доля стандарта.
C>Исключений из этого правила не так уж много. Из популярных: семейство TCP/IP (без них — уж совсем никак) и язык HTML.
И GSM, и 802.xx и еще тонна популярных стандартов.
, мы имеем по сути только 2 (из них один порой обкладывается TOSами и QOSами, но суть не меняется). А замечания твои и так как бы понятны, просто не будешь же каждый раз писать столько слов об известном каждому.
