Тычеблин wrote: >> > учитывать такой показатель, как * объем памяти* на одно соединение.. > C>Несерьезно, gzip/gunzip для сжатия XML на внешних интерфейсах занимают > C>*столько времени*, что о нем просто говорить смешно. > ....мы про насосы, а нам про колесы > харе запускать дурочку....
Объем памяти? Оверхед от gzip — примерно 64 килобайта на соединение.
Можно и меньше — будет меньше степень сжатия.
Вообще, советую поработать в реальных проектах с custom'ными бинарными и
текстовыми протоколами. Тогда, может, поймешь разницу.
Здравствуйте, Тычеблин, Вы писали:
Т>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, Тычеблин, Вы писали:
Т>>>все широко распостраненное, имеющее недавнею историю типа ICQ, MSN.... как правило имеет бинарный протокол.
К>>XMPP?
Т>Jabber — больше ничего на ум не приходит, ну так это просто микроб в ставнении...
Ну так-то да, только вот лично Google Talk пользую и очень даже доволен (иногда аська глючит, перехожу на него)
какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...
C>Ты, видимо, никогда не отлаживал программы с бинарными протоколами.
хочешь чтобы я это комментировал?
C>Когда днями приходится искать почему сообщения не проходят — и C>оказывается, что в checksum считается один лишний байт.
это если ты бармэном работаешь, тогда да, большой разницы между 401 каплей или 402 нет.
в IT, даже один бит имеет значение.... вне зависимости XML это или нет.
Здравствуйте, Тычеблин, Вы писали:
Т>расжимать-то в каждом соединениее полученный XML куда будем?
Подавать на вход десериализатору, построенному на SAX-парсере. Это если надо. Так что выключай дурочку.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Тычеблин, Вы писали: Т>какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...
Ну объясни мне тогда, почему между Триллианом и ICQ кириллица в одну сторону ходит, а в другую — нет? Почему наш аськовый сервер в homenet не пускает моего кошерного 5.1 клиента?
Там это согласование протоколов сделано через дупу. Еще раз повторяю: аськовый протокол — очень плохой пример. Начиная от версионной несовместимости, которая до сих пор не решена, и заканчивая обилием критических уязвимостей, кои в частности и привели к внедрению многих из версий. Лучше бы ты привел какой-нибудь TDS. Т>в IT, даже один бит имеет значение.... вне зависимости XML это или нет.
В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты".
Хотя, должен признать, во многом это теория. Вон на PHP SOAP реализовать — страшный геморрой. Периодически он начинает гнать на самый невинный вроде XML. Типа алиас неймспейса по-другому обзываем — и все, приехали. В итоге никто не пишет вызовы "по спецификации", а просто копируют заведомо рабочие примеры, и с осторожностью сапера меняют параметры.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Тычеблин, Вы писали:
Т>>расжимать-то в каждом соединениее полученный XML куда будем? S>Подавать на вход десериализатору, построенному на SAX-парсере. Это если надо. Так что выключай дурочку.
а расжатый XML и SAX-парсер хранить где будем?
как сферического коня — в вакууме?
Здравствуйте, Тычеблин, Вы писали: Т>а расжатый XML и SAX-парсер хранить где будем?
Гм. Ты как бы в курсе, что такое SAX-парсер? Я говорю о потоковой десериализации, которой не нужно держать в памяти весь XML.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну объясни мне тогда... какое отношение криво написанный софт имеет к достоинствам или недостаткам бинарного/небинарного протокола? или на XML невозможно написать кривого софта?
S> Лучше бы ты привел какой-нибудь TDS.
откуда ж я знал, что у твох приятелей руки до TDS еще не дошли
Т>>в IT, даже один бит имеет значение.... вне зависимости XML это или нет. S>В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты".
какие средства? какой диагностики? у TCP/IP этих средств выше крыши?
лично мне хватает или
хочешь сказать, что с уровня TCP/IP можно получить битую информацию?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Тычеблин, Вы писали: Т>>а расжатый XML и SAX-парсер хранить где будем?
S>Гм. Ты как бы в курсе, что такое SAX-парсер? Я говорю о потоковой десериализации, которой не нужно держать в памяти весь XML.
1)обрати внимание на выделенное, где ты видишь весь
2)буфер нужен ?
3)при всех прочих равных утверждаю, при бинарном исполнении это все работает намного эффективнее.
Здравствуйте, Тычеблин, Вы писали:
Т>Здравствуйте, Sinclair, Вы писали:
S>>Ну объясни мне тогда... Т> какое отношение криво написанный софт имеет к достоинствам или недостаткам бинарного/небинарного протокола?
Гм. И в третий раз пошел он за елкой... Повторяю: Протокол ICQ — плохой пример бинарного протокола. Он демонстрирует ровно все недостатки бинарности. Поэтому не надо его использовать для критики XML. Придумай другой пример.
Т>откуда ж я знал, что у твох приятелей руки до TDS еще не дошли
Дело не в том, что дошли или не дошли. Существует более одной независимой реализации TDS; несмотря на многолетнюю историю использования, сам протокол существенно не изменился; за все время ровно в одной реализации была обнаружена ровно одна уязвимость. Я опять же могу насчет него сильно заблуждаться, т.к. внутрь его никогда не лез и вообще полагал его проприетарным, пока не услышал про независимые реализации. Т>>>в IT, даже один бит имеет значение.... вне зависимости XML это или нет. S>>В XML очень развиты средства диагностики. Которые как раз очень помогают отловить вот эти "одинбиты". Т>какие средства? какой диагностики?
Выключи дурочку. Элементарная опечатка в теге будет обнаружена еще на этапе разбора, и вместо undefined behavior ты получишь вменяемое исключение от парсера. Т>у TCP/IP этих средств выше крыши?
У TCP/IP вообще никаких средств нету. Напомню, что сам протокол не страхует тебя даже от NUXI problem. В то время, как в XML запротоколирована поддержка BOM, обеспечивающая корректное согласование неоднобайтовых енкодингов.
Т>лично мне хватает или Т>хочешь сказать, что с уровня TCP/IP можно получить битую информацию?
Конечно можно. TCP/IP не предоставляет никаких методов контроля семантических ошибок. Мусор на входе — мусор на выходе. В XML встроены средства контроля как синтаксической корректности, так и семантической (хоть и ограниченной). В итоге очень небольшой процент ошибок добирается до собственно прикладного уровня. И их уже не так трудно отловить. А бинарные данные очень просто испортить, если изобретенный протокол не содержит специальных средств контроля. Взял ты, к примеру, и в сервере заменил двухбайтовое поле на четырехбайтовое. А клиент не знал и отправил два байта. В итоге имеем реинтерпретацию данных и хорошо, если это не приведет к переполнению буфера.
Сделать удачный бинарный протокол не так уж и просто.
С удачными текстовыми я близко знаком. К примеру, HTTP 1.1 — очень хороший протокол. Его до сих пор не на все 100% используют. Особенно удачных XML протоколов я не знаю. С бинарными протоколами работал очень мало; с тем, с чем работал — опыт скорее негативный. Отладка была сущим кошмаром, но это не показатель — опыта у меня тогда было в 10 раз меньше, чем сейчас, да и протоколы были построены поверх RS232, а не TCP/IP.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Тычеблин, Вы писали:
Т>>Здравствуйте, Sinclair, Вы писали:
S>Гм. Он демонстрирует ровно все недостатки бинарности.
ничего кроме криворукости конкретных разработчиков он не демонстрирует. и то не понятно конкретно каких. тех кто создавали протокол или тех кто пытались подражать.
Т>>откуда ж я знал, что у твох приятелей руки до TDS еще не дошли S>Дело не в том, что дошли или не дошли. Существует более одной независимой реализации TDS; несмотря на многолетнюю историю использования, сам протокол существенно не изменился; за все время ровно в одной реализации была обнаружена ровно одна уязвимость.
именно подобными вещами я однажды и занимался, черпая информацию из декомпилированного MS JDBC драйвера. и то это была очень экзотическая ситуация когда понадобилось мультиплатформенность и эффективность.возможно есть отчаяные парни выставляющие SQL в интернет, только зачем? совсем другое дело ICQ.
Т>>лично мне хватает или Т>>хочешь сказать, что с уровня TCP/IP можно получить битую информацию? S>Конечно можно. TCP/IP не предоставляет никаких методов контроля семантических ошибок.
отлаженный, сериализующий софт таких ошибок не допускает.
а вот когда в фаре начинают править — сколько угодно. нефиг
S>....примеру, и в сервере заменил двухбайтовое поле на четырехбайтовое.А клиент не знал и отправил два байта. В итоге имеем
предлагаешь обсудить как кто-то сделал что-то криво?
S> С бинарными протоколами работал очень мало; с тем, с чем работал — опыт скорее негативный. Отладка была сущим кошмаром, но это не показатель — опыта у меня тогда было в 10 раз меньше, чем сейчас, да и протоколы были построены поверх RS232, а не TCP/IP.
у меня другая эволюция...
долго цеплялся за все готовое в надежде — ну не дураки ведь писали.
пока однажды не написал свой лисапет.
Здравствуйте, Тычеблин, Вы писали:
Т>1)обрати внимание на выделенное, где ты видишь весь Т>2)буфер нужен ?
Гм. Размер буфера при этом столь невелик, что им можно пренебречь. Принципиально то, что это O(1) буфер, и потребление памяти не зависит от размера данных. Т>3)при всех прочих равных утверждаю, при бинарном исполнении это все работает намного эффективнее.
Эффективнее — да. Насчет "всё" — не уверен. В XML реализовано очень много "всего". Не факт, что все из этого нужно. Не факт, что нужное нельзя заменить чем-то другим. Эффективность — не самая главная проблема в XML, поверь мне.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Тычеблин, Вы писали:
Т>ничего кроме криворукости конкретных разработчиков он не демонстрирует.
Включи дурочку. Это утверждение нужно еще доказывать. В стотридцатьпервый раз повторяю: не надо привлекать ICQ как пример торжества бинарного протокола. Ну не работает он! Бери позитивные примеры.
Т>именно подобными вещами я однажды и занимался, черпая информацию из декомпилированного MS JDBC драйвера. и то это была очень экзотическая ситуация когда понадобилось мультиплатформенность и эффективность.возможно есть отчаяные парни выставляющие SQL в интернет, только зачем?
При чем здесь выставление в интернет? TDS, вроде как, используется и в интранете.
Т>отлаженный, сериализующий софт таких ошибок не допускает.
Выключи дурочку. Гарантии целостности желательно реализовать на уровне протокола. Напомнить тебе, что IP содержит свой чексум, хотя вроде бы Ethernet фреймы имеют свой? Вроде бы отлаженный стек TCP/IP не должен получать битых фреймов, так? Т>предлагаешь обсудить как кто-то сделал что-то криво?
Конечно предлагаю. Интернет — это такое место, где все делают все криво. И вот HTTP, к примеру, к этому устойчив. И XML к этому устойчив.
Далее, не обязательно, чтобы это была непременно ошибка. Просто сменили версию протокола, и не все об этом вовремя узнали. На одном конце софт одной версии, на другом еще не успели перекомпилять.
Крайне желательно, чтобы такие ошибки были гарантированно детектированы, а не приводили к undefined behavior.
Например, валдиный XML оборудован схемой. И если отправитель сменил в нем схему, я это сразу замечу. А если он нарушил схему, то он даже и отправить-то документ по валидирующему каналу не сможет. Такой вот принудительный механизм соблюдения договоренностей. А ты в своем бинарном протоколе как utf-16 сериализуешь, расскажи? Нет риска нарваться на разный byte order? А floating point ты по какому стандарту передаешь? А даты как енкодятся? А часовой пояс при этом передается, или они обязаны быть в GMT? Как предполагается расширять формат? А как передаются фрагменты переменной длины — длина вначале или маркер конца?
Т>у меня другая эволюция... Т>долго цеплялся за все готовое в надежде — ну не дураки ведь писали. Т>пока однажды не написал свой лисапет.
Ну можешь свой лисапет на общий суд выставить. Правда, я подозреваю, что он не выдержит критики как общее решение. И даже в частном случае запросто могут найти в нем косяки, на которые ты не наступил просто в силу везения
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Тычеблин wrote: > расжимать-то в каждом соединениее полученный XML куда будем?
В память. С чего ты взял, что распарсеный бинарный протокол займет
меньше места?
Короче, несерьезно это. У нас сервер сообщений, использующий ASN.1 с PER
занимает столько же памяти, сколько и он же переписаный на XML. Нагрузка
примерно 1000 сообщений в секунду с датчиков телеметрии.
> C>Вообще, советую поработать в реальных проектах с custom'ными бинарными и > C>текстовыми протоколами. Тогда, может, поймешь разницу. > советую не советовать, у меня свой, реально работающий под нагрузкой, > application server (.NET) со своим бинарным протоколом. > я знаю о чем говорю.
Ну а я писал драйвера для железок, для которых у меня была только
спецификация протокола. Больше не хочу.
А вот с железками, которые общаются в XML работать вообще просто сказка.
Можно писать для них драйверы, просто смотря на wire protocol.
Здравствуйте, Sinclair, Вы писали:
S>Например, валдиный XML оборудован схемой. И если отправитель сменил в нем схему, я это сразу замечу. А если он нарушил схему, то он даже и отправить-то документ по валидирующему каналу не сможет.
Это при условии, что отправитель не поменял содержимое самой схемы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это при условии, что отправитель не поменял содержимое самой схемы.
Ну, по идее, обе стороны используют одну и ту же схему.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ГВ>>Это при условии, что отправитель не поменял содержимое самой схемы. S>Ну, по идее, обе стороны используют одну и ту же схему.
Я неудачно сформулировал. Вопрос должен быть таким: что делать, если софт у получателя остался прежним, а схема валидации XML поменялась? Прилетает совершенно валидное XML-сообщение, к которому не готов софт получателя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
1.2.0 alpha rev. 655
какое отношение криво написанный софт имеет к достоинствам или недостаткам бинарного/небинарного протокола? или на XML невозможно написать кривого софта?
