Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
Итак, тема многолога: Протокол HTTP и его немерянная крутизна.
Парни, в последнее время я неоднократно слышал этакую "критику походя" в адрес HTTP. Ну там, типа, "да ведь это .овно использует корявый HTTP", или "вы что, всерьез предполагаете передавать бинарный контент через HTTP?", или даже "Некоторые предлагают использовать кривые костыли вроде HTTP".
Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня.
Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
Миф номер 1: Протокол HTTP обладает избыточностью, из-за того что он текстовый.
На самом деле это сразу два мифа. Во-первых, в HTTP текста не так уж много — только header сообщения текстовый. Тело вполне может быть (и на практике бывает) бинарным.
Во-вторых, HTTP устроен так, что "не надо платить за то, чего не используешь". Если модные сервисы от него не нужны, то накладные расходы на заголовки HTTP близки к нулю.
Обычно те, кто делает подобные м.1. заявления, подразумевают "вот если бы я реализовал свой протокол, то ух я бы сделал его супероптимальным".
Вот это — тоже миф. Дело в том, что в HTTP уже встроены возможности по оптимизации, до которых обычно у "творцов протоколов" никогда не доходят руки. Например, кэширование, частичная передача контента (т.н. докачка), и компрессия данных. В итоге, с учетом этого, зачастую реальное приложение, построенное поверх http, потребляет меньше трафика, чем "TCP/IP" аналог.
Миф номер 2: Так ведь клиент там будет тяжеловесный. Вот то ли дело сокет.
Я, если честно, не мерил, сколько ресурсов отжирает WinInet. Но ничего в нем ракетного нет. Если есть острое недоверие к стандартной реализации клиента, велком — никто не запрещает открыть сокет на порт 80, послать стандартный реквест, и получить нужный респонс. В некоторых особо торжественных случаях это и есть самый кошерный способ — естественно, если нет нужды поддерживать редиректы, компрессию, кэширование, куки, и прочие вещи, традиционно встроенные в http-клиента.
Если под "тяжеловесным клиентом" понимается веб-браузер, то надо понимать, что во-первых, он нужен только для человека. Программному клиенту браузер не нужен. А альтернативный клиент, который будет внутри себя обрабатывать HTTP, будет ненамного эффективнее, чем браузер (и уж точно менее распространен).
Миф номер 3: Ага! Клиент-то может и маленький, а сервер? Он же тормозит!
Ну, вообще-то, смотря какой сервер, и что понимается под "тормозит". Обычно, stateless HTTP сервер рвет аналогичный по функционалу сервер с удержанием соединения как тузик грелку. Потому, что HTTP клиент работает в "импульсном" режиме: сбегал к серверу (за 40 миллисекунд), и тупит локально, до следующего запроса. Редкий пользователь кликает ссылку ежесекундно.
(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален)
Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.
Ну а если то, что вам нужно отдавать на клиента, лежит в готовом виде в файловой системе, то опередить современный HTTP сервер вряд ли удастся. Потому что редкий хардкорный программист рискнет писать свой драйвер режима ядра — а именно это делает, к примеру, IIS 6 и новее.
Миф номер 4: Ну и ладно. Мне всё равно недостаточно чистого HTTP, а значит придется строить свой протокол.
Не совсем. Большинство из того, чего вам не хватает, в HTTP либо предусмотрено (см. RFC 2616), либо предусмотрен способ расширять протокол. Таким образом, сохраняются все преимущества готовой реализации, но при этом необязательно ограничиваться ею. Ваш контент лучше сжимать не gzip, а каким-нибудь fluxe? Ок, пусть клиент передает его в Accept-Encoding, а сервер научится передавать в нем. Если к вам придет старая версия клиента, вам не надо думать, как это понять и передать ей контент в несжатом виде.
Вам не нравится digest authentication? Отлично, придумайте свой протокол и включите его в negotiation.
Напоследок порекомендую для ознакомления книжку O'Reilly "RESTful Web Services" для осознания того, как правильно строить свои протоколы на базе HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Во-вторых, HTTP устроен так, что "не надо платить за то, чего не используешь". Если модные сервисы от него не нужны, то накладные расходы на заголовки HTTP близки к нулю.
Небольшая мысль вслух того, кто чувствует эти нулевые накладные расходы ежемесячно.
Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
В качестве примера победы разума над текстом могу формат PDF вспомнить, который изначально тоже был весь из себя такой текстовый, но когда стало понятно что ни один нормальный человек никогда его руками набивать не станет, а текстовое кодирование бинарного содержания жрет много места, его взяли и сделали бинарным (хотя заголовок все равно оставили текстовым, залипли ребята).
Здравствуйте, Pzz, Вы писали:
Pzz>Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно.
HTTP/1.1 поддерживает keep-alive
Pzz>Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут.
ну значит сами себе злобные буратины.
Pzz>Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов.
Еще как позволяет.
Схема такая:
Посылаешь первый запрос с заголовком connection: keep-alive
Если сервер ответил утвердительно то ты можешь послать все остальные запросы не дожидаясь ответа от сервера.
А потом получить ответы на них в томже порядке в котором послал.
Pzz>Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
Если keep-alive не использовать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, misha_irpen, Вы писали: S>>Миша, а какой у вас cache hit ratio? _>А что это?
Сейчас, Миша, я вам все расскажу.
Для начала — небольшой session transcript:
GET /an1cEUD0cpz1600NjEyOTh2fDAwMDAxMTFkYXxIZWxsbw.gif HTTP/1.1
Accept: */*
Accept-Language: en-us,ru-RU;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: ticker.7910.org
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie: lg=en; b=b
HTTP/1.0 200 OK
Server: nginx/0.4.13
Date: Mon, 07 Apr 2008 02:57:52 GMT
Content-Type: image/gif
Content-Length: 15808
Last-Modified: Mon, 07 Apr 2008 02:57:19 GMT
Accept-Ranges: bytes
X-Cache: MISS from gw2.plesk.ru
Connection: keep-alive
GET /an1cEUD0cpz1600NjEyOTh2fDAwMDAxMTFkYXxIZWxsbw.gif HTTP/1.1
Accept: */*
Accept-Language: en-us,ru-RU;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 07 Apr 2008 02:57:19 GMT; length=15808
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Proxy-Connection: Keep-Alive
Host: ticker.7910.org
Pragma: no-cache
Cookie: lg=en; b=b
HTTP/1.0 304 Not Modified
Server: nginx/0.4.13
Date: Mon, 07 Apr 2008 02:58:05 GMT
Last-Modified: Mon, 07 Apr 2008 02:57:19 GMT
X-Cache: MISS from gw2.plesk.ru
Connection: keep-alive
Это я состряпал себе линеечку, посмотрел ее, и нажал F5.
Что интересного можно здесь увидеть?
В ответ на второй запрос мне приходит 304. Это радует, это вы экономите исходящий трафик. Давайте взглянем на статистику объема данных:
Отправлено Принято
Первый запрос: 369 16057
Второй запрос: 433 189
Что мы видим в статистике? Видим мы 433 байта входящего трафика, которые вас убивают. А знаете, почему? Потому, что вы сэкономили на хидерах cache-control.
У вас же данные исключительно time based. Вы можете предсказывать точное время, когда картинка изменится. А user-agent, увидев правильный хидер expired, не будет посылать вам эти 433 байта и забирать 189.
Попробуйте научить ваш сервер отдавать нормальные хидеры, и ваш входящий трафик уменьшится в разы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
S>Итак, тема многолога: Протокол HTTP и его немерянная крутизна.
Здравствуйте, vdimas, Вы писали: V>Но вот есть некое общедоступное расписание занятости некоего ресурса с заведомо ограниченной обслуживаемой ёмкостью, например. Клиенту мы передаём текущее расписание, чтобы он смог выбрать и зарезервировать в нём ячейку. Клиентом может быть как серверное HHTP-приложение (суть общедоступное GUI к сервису шедуллера), так и клиентское VoIP-приложение (т.е. никак не браузер). Как тут без структур в случае клиента?
Ты всё время пропускаешь слова в моих фразах. Я не сказал "без структур", я сказал "без передачи структур".
В данном случае имеет смысл представить расписание в виде набора ресурсов таким образом, чтобы с ним было удобно работать.
Предположим, что расписание делается для одного ресурса и состоит из фиксированных слотов длиной в 30 минут, итого 48 слотов в сутки.
Информация о занятости слотов представлена в виде XHTML файлов и поделена по границам суток.
Таким образом, чтобы получить информацию о свободных слотах на 8 мая 2008 года, я делаю GET реквест по адресу
.../2008/05/08/
В ответ я получаю список занятых слотов.
Выбрав один из подходящих свободных, я делаю PUT реквест на адрес нужного мне слота, к примеру
.../2008/05/08/18.30/
В теле запроса я передаю документ с информацией о занятости.
Если всё хорошо, я получаю 201 object created и радуюсь. Если междy GET и PUT кто-то успел вклиниться, я получаю 409 conflict.
Вся идея сводится к тому, что клиент как правило знает желаемое время получения слота с точностью до суток. Поэтому в случае наличия свободных мест он получит слот за два реквеста.
Более интересные сценарии в данном протоколе:
1. Первый запрос не вернул ни одного свободного слота. Клиент скорее всего запросит следующий день (если речь идет о задаче "получить ресурс ASAP"), и повторит поиск.
2. Клиент уже получал данные о занятости, но просто так — поинтересоваться. Прошло некоторое время, и вот теперь он снова хочет их получить. Поскольку копия индексного документа лежит в кэше, выполняется conditional get, который может вернуть 304 в случае удачи.
Заметь, что у слотов фиксированные адреса — вторая идея в том, что состояние занятости отдельных слотов меняется редко.
Мы могли бы реализовать отдельное представление для очереди свободных слотов — это бы упростило реализацию клиента. Но очередь будет 100% модифицироваться при каждом резервировании слота, а среди индексных документов поменяется только один. Таким образом, предложенная схема — более cache-friendly, и небольшие трудности для клиента с лихвой окупятся за счет удешевления запросов.
Теперь вернемся к SOAP в частности и RPC-style протоколам в целом. Как будет выглядеть API для этой системы в RPC-стиле? Сколько вызовов будет делать в среднем клиент при резервировании слота? Как будет выполняться масштабирование? Что делать при развитии системы — к примеру, когда у нас появится более чем 1 ресурс? Что делать, когда мы захотим перейти от фиксированных слотов к слотам произвольной длины? Я имею в виду такое развитие, которое сохраняет обратную совместимость с обеих сторон — т.е. клиент версии 2.0 должен уметь работать с сервером версии 1.0, и наоборот.
V>Вот если в твоём высказывании "лучше представлять" заменить на "в случае приводимости", то дописать в конце можно "то рекомендуется HTTP, со всей его инфраструктурой кеширования в клиентских браузерах"
Дело не только в клиентских браузерах. Браузер вообще достаточно плохой веб клиент. Дело в прокси, реверс прокси, а также в клиентских библиотеках.
V>Насчёт кеширования как раз и так понятно, непонятно про "обеспечение стабильности состояний". ИМХО, не очень большой класс задач радует нас некритичными к актуальности состояния требованиями.
Имхо, это как раз очень-очень большой класс задач. Тут вот по соседству ребята приводили пример с линеечками. Я смеялся до упаду. Типичное применение линеечки — в подписи к форумным постингам. И вот заходишь в такой типичный форум: на одной странице десять-пятнадцать постов от вот такого "облинейченного" активиста. Что мы имеем? Имеем 10-15 запросов к серверу с интервалом в 5-10 миллисекунд. Даже если бы линеечка устаревала за 60 секунд, правильное использование кэширования снизило бы нагрузку на десятичный порядок.
А ведь задач с требованиями к актуальности состояния в 60 секунд — очень и очень мало. Главное — умение разрулить конфликт в том редком случае, если он всё-таки произойдет. См. выше насчет 409.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Текстовые конфигурационные файлы, при всех их недостатках, обладают одним несомненным достоинством: на них можно посмотреть глазками и поправить обычным текстовым редактором. Их можно сравнивать diff'ом и хранить историю изменений в source control system. По ним можно сказать grep. В общем, с ними можно проделывать все те штуки, которые можно проделывать с обычным текстом.
Точно так же текстовые протоколы, при всех их несостатках, обладают одним существенным достоинством: на них можно посмотреть глазками, и понять, что происходит. Можно поговорить с сервером телнетом (вручную) и получить осмысленную реакцию.
Не надо считать юниксоидов полными идиотами. В конце концов, многие вещи пришли именно оттуда, а это что-нибудь да значит.
Здравствуйте, Игoрь, Вы писали:
И>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.
Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям".
И>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему.
Давайте тогда не останавливаться на половине пути и сделаем текстовыми еще и исполняемые файлы вместе с базами данных. Вообще отлаживать просто будет.
И>Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола).
Для тестов и отладки можно (и нужно) написать отладочный инструмент. А эти отладочные "удобства" в мир выпускать не нужно. Вы исполняемые файлы, собранные в "target: debug", тоже распространяете?
И>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто кна ура, а можно и автогенераторами воспользоваться.
Какие проблемы есть лично у меня я уже написал, а вы поскипали.
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
Прошу считать мой случай крайней необходимостью.
И>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.
....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал
И>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук.
когда ты последний раз отлаживал TCP/IP?
И>А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола).
да ты крут....визуально английскую и русскую А Е и О отличаешь...
И>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться.
очень удобно пользоваться специализированными инструментами. например IDE для программинга, где в основе банальные текстовые файлы. или ноутпэд наш выбор? ....дикари!
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
(по крайней мере SMPP и EMI/UCP -- точно, посколько они как раз и создавались для асинхронного взаимодействия, поэтому в самом протоколе оговаривается, что ответы могут приходить совсем не в том порядке, в котором инициировались запросы).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Mamut, Вы писали:
M>Search Engine Optimization
Это следовало бы назвать SEF — Search Engine Fooling. Идиотичное по самой своей природе занятие, которое рано или поздно неизбежно отомрёт. (Не знаю как, но бесконечно жить и здравствовать оно просто не имеет права.)
Сюда же надо добавить лёгкую интергацию в существующую инфраструктуру: NAT, прокси, куча библиотек и модулей. Всё это не надо писать заново, а можно тупо воспользоваться.
Здравствуйте, Shabi, Вы писали:
_>>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. S>...эти все подлянки из юниксов вестимо...задолбало такое наследие
Полностью солидарен. Юниксоидам традиционнно влом писать модули конфигурации своих программ (даже для комстроки) и они переложили задачу формирования конфигурационных данных на юзера. В итоге все конфиги текстовые, но каждый со своим уникальным и часто совершенно придурочным синтаксисом. В одном имя и значение разделены пробелом, в других символом равенства, в третих двоеточием, в четвертых исключительно табуляцией (за последнее вообще убивать на месте нужно). Аналогично с коментариями, придумывают все что бог на душу положит.
Вот вся это свистопляска и перекочевала в протоколы. Тут конечно могут возразить что мол архитектуры ЭВМ бывают разные, с разной разрядностью и разной последовательностью байт в слове и что бинарные данные будут соответствовать только одной из них. Это все конечно так, но дело в том, что текстовые данные не соответствуют вообще ни одной. Никакая операция приведения разрядности и перестановки байт не сравнится с парсингом псевдочеловеческого исходника с последующим преобразованием строкового представления числа в бинарное. А про объемы я уже говорил выше.
Здравствуйте, Shabi, Вы писали:
И>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>....попробуй объяснить загадку природы TCP/IP. :xz: как бы бинарный и о таких проблеммах не слышал
Ты что курил? У него эти проблемы в полный рост — если не сделаешь ntohl при вытаскивании хоста из пакета, результат будет, мягко говоря, не тот, что ожидался. И странно бы, если где-то было бы хоть как-то иначе.
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>когда ты последний раз отлаживал TCP/IP?
Я не думаю, что у кого-то тут есть собственная реализация TCP/IP, но я, например, смотрел tcpdump'ы и запускал tshark я не далее чем вчера. И таки да, видел бинарную часть и даже умудрялся в ней читать те поля, смещения которых знаю наизусть (а остальные пропускал, ибо лезть открывать /usr/include/netinet/in.h было облом). Ты вот навскидку сможешь прочитать список опций TCP и указать, где именно в пакете описано, например, scale размера окна? Только не подглядывать в доку.
И>>А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола). S>да ты крут....визуально английскую и русскую А Е и О отличаешь... :wow:
Английская и русская буквы ни при чём. Это проблемы того уровня, который в таких протоколах крайне редко случается (и для них можно, например, шрифты iso-1 включить), может, один случай на десять тысяч, обычно реже, и необходимость копать в этом направлении видна сразу. Если ты вспоминаешь контекст баз данных — да, там такое бывает часто. Но не в служебных данных сетевого протокола.
И>>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться. S>очень удобно пользоваться специализированными инструментами. например IDE для программинга, где в основе банальные текстовые файлы. или ноутпэд наш выбор? ....дикари!
Дикарь тут именно ты. Потому что вместо использования передового опыта человечества (который сводится в данном случае к одной простой норме: "лучше делать удобнее для человека, чем для компьютера, если это не слишком дорого") — трясёшься над заветами отцов, которые их выработали находясь на крайнем севере где нечего есть кроме рыбы и ягеля, то есть прошу прощения — на компьютерах мощности в пару тысяч "слов" странной размерности, где не было нормального компилятора и приходилось дрожать над каждым битом.
И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный. S>странный опыт...
У тебя — да. Потому что ты до сих пор не освободился от опыта тех времён и мест, где надо было экономить каждый байт и где не было нормальных средств вообще ни для чего.
Там где текст был бы реально слишком дорог — например, уровни 1-4 традиционной народной OSI, или исполняемые файлы — его никто не втискивает. Там же, где его можно использовать — его используют.
Здравствуйте, Sergey, Вы писали:
S>А при чем здесь "лежит в готовом виде в файловой системе"?
Файлы действительно можно отправлять без участия кода пользователя. См HTTP_DATA_CHUNK FromFileHandle
S>Для того, чтобы отсылать готовое файло, есть функция TransmitFile.
Она делает ReadFile + send.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Было бы все так красиво — жил бы себе не тужил. Лучше не воспевать достоинства, а учитывать недостатки.
Про асинхронку уже было сказано. А вот про то, что это текстовой формат — нет. Проблема в том, что он не просто текстовой(я говорю не о боди). Он US-ANSII. То что мы в url видим всякую фигню — это полбеды. Сам заголовок приходится перекодировать. И не просто перекодировать. А еще с учетом 78/998. (rfc2822
2.1.1. Line Length Limits). При этом, если больше 78 — то бывают глюки клиентов.
Говорить о том, что http простой протокол не приходится. Для выяснения того, или иного вопроса приходится бегать по куче RFC. Клиенты в связи со сложностью — достаточно глючные. Ну например из показательных, IE в случае если в доменном имени встретилось подчеркивание — обрубает куки. Почему не выводит ошибки, непонятно. Зависимость между куками и url — очень плохо прослеживается. Opera и Firefox — вообще не обрабатывают такую ситуацию, и безошибочно работают.
Сложность расширения с помощью DAV. Ну нет нормальной поддержки в которую можно внедрится безопасно и сэмулировать fs ни в IIS, ни в Apache. Только ручная реализация(по крайней мере IIS). О клиенте вообще не говорю.(поддержка Dav в виндах выключена в целях безопасности).
Здравствуйте, Mamut, Вы писали:
M>Думаю, Михаил (misha_irpen) за такие запросы туда-сюда просто порэжет на куски, да
Не обязательно
Я бы предложил так: при подключении, еще до запроса, сервер сразу компактно говорит клиенту что ему нужно (FTP/SMTP, вон, тоже сразу клиента привествуют и не рассыпаются). А клиент уже формирует свой запрос исходя из этих данных. Причем я бы еще сделал так, что если клиент положил в заголовок больше чем его просили, совсем отказывать в обслуживании этого запроса, ибо нефиг.
GZ>Попробуй напиши это правильно. Так чтобы работало.
А это-то тут причем? 78 символов относится исключительно к заголовкам.
Ограничения на длину URL в стандарте HTTP нету. Большинство реализаций сервера ограничивают URL в 65K — ты устанешь придумывать такую ссылку.
То, что браузеры не умеют работать с URL длиннее 2K, тоже не является виной протокола.
S>>Смотря для чего. Еще раз напомню, что не пользуешься — не платишь. Не нужны русские символы в заголовках (а это редкость, кроме filename в Content-Disposition вроде и некуда особо запихать-то) — не учи RFC 2047. GZ>Есть еще Content-Description. Но задача по Content-Disposition встречается в каждом втором проекте. Значит учить RFC 2047 нужно в 50% случаев. Это если ты один делаешь весь проект. А в реальных проектах хэндлеры, которые отдают файлы для Save As, занимают меньше 1% кода, значит в среднем только 1% команды нуждается в деталях этого RFC. Архитектор или Dev Lead, конечно же должен это знать. Но для такой позиции глубокие познания в протоколах и расширениях занимают даже не 50% нужной квалификации. Еще до хрена чего надо знать. Ну а вы как хотели? Лингва латина нон пенис канина. Разработка софта никогда не была простой деятельностью.
GZ>Да понимаешь в чем дело. Не нарушает это Microsoft стандарт. Я то разрабатываю. А администратор ставит.
Ниче не понял. Набор слов какой-то. Есть ясный стандарт на то, что может, а что не может быть доменным именем. За пределами этого поддержка GZ>ASP.NET приложение каждый запрос пытается аутентифицироваться. Ему и не надо знать что такое http only куки.
Кому не надо? GZ>Юникс системы он видел только на картинках. Он спец по Microsoft. В результате, потратив свое время на то, чтобы испробоваnm все что можно он звонит не адвокату, не в Microsoft, а мне.. Тратит мое время. А я это — не люблю. Мне платят за разработку.
Ок, значит надо сделать себе отметку, чтобы Login страница сразу выкидывала Exception с текстом "Could not authenticate site located on a host with "_" in name, see RFC 952".
Тогда администратор значительно быстрее поймет, в чем именно он дурак.
Это из области таких вещей, которые неприятно осложняют жизнь, но несмертельны. Туда же идут P3P хидеры — пока что ASP.NET ничего про них не знает, и разработчики раз за разом наступают на грабли типа "сессия теряется в IFRAME". Это gotcha — способ легко унизить на собеседовании кандидата, который думал, что он хорошо разбирается в вопросе.
GZ>>>Ну нет нормальной поддержки в которую можно внедрится безопасно и сэмулировать fs ни в IIS, ни в Apache. S>>Это не проблема протокола. Не вижу принципиальной проблемы сделать WebDAV Server Framework на, к примеру, .Net. GZ>Именно этим и приходится периодически заниматься. Опять же, я ленив. Мне нужно блюдечко с голубой каемочкой. А его там нет.
Это не вина протокола. Блюдечка с голубой кайомочкой нет нигде. Я вот всю жизнь сталкивался с тем, что то, чего мне хотелось, в природе отсутствовало. Только потом, лет через пять, это оказывалось самым что ни на есть мейнстримом и попадало в руки индусам. Но к тому моменту передо мной уже стояла следующая задача, и опять везде полный вакуум.
S>>Я вообше пока не уверен, что DAV — сильно хорошая идея. Уж очень он радикально HTTP расширяет. Хотя есть некоторые и удобства — скажем, автоматическая доступность контента в Generic Http клиенте. GZ>Трабла в том, что прозрачно из DAV файловая система не эмулируется. И соответсвенно, поддержка простых редакторов данной FS — сложная задача. Microsoft вообще работает по нескольким своим стандартам чтобы эмулировать файловую систему через http.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Игoрь, Вы писали:
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ? И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Здравствуйте, netch80, Вы писали:
N>Два разных кода для дебага и релиза?
Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
>Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком)
Ну насчет всерьез — уже поздно. Раньше думать надо было.
N>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.
А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Здравствуйте, Sinclair, Вы писали:
S>Бинарность/небинарность с точки зрения оптимизации отходят на второй план. За исключением тех случаев, когда вышеописанные возможности исчерпаны, а результаты не устраивают.
самое интересное происходит в момент преобразование полученной информации в вид пригодный для програмной обработки...и обратно — сериализация...
парсрование бинарного протокола намного проще, а смое главное эффективнее (память, CPU...). что в контексте сервера особливо важно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PaulMinelly, Вы писали: PM>>А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно. S>Ну, такой поддержки GET конечно же в Апаче нет. Тем не менее, для статического файлового контента семантика GET хорошо определена и встроена в сервер.
Здравствуйте, VGn, Вы писали:
S>>Способов много, но надо учитывать, что шифрование без удостоверения личности второй стороны — фикция. Потому что глупо надеяться на то, что злоумышленник сможет подслушать линию, и не сможет в неё вклиниться.
VGn>При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может.
это если он ключи не перехватит.
Здравствуйте, 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...
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика
Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые обытки, в отличии от исходящего.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. S>(Побежал в гугл читать про SIP)
Про него есть замечательная книга — Demistifying SIP. Ее можно найти в электронном виде. Она показывает, как SIP вписывается в Internet Conferencing Architecture, дополняя другие протоколы IETF.
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)
Здравствуйте, netch80, Вы писали:
N>Я не столь пессимистичен здесь, как Cyberax — но ты где-то реально видел реализацию, которая бы способна была перенести диалог на хост с другим IP? (Да, я знаю, что можно в h_Route, h_Record-Route, h_Via писать имена, но опять же вопрос в конкретных реализациях.) А вариант, где нельзя сохранить диалог потому что нода упала — меня не интересует. А с транзакциями — ещё хуже — потому что их минимум в 2 раза больше, а при хоть каком-то signaling keepalive — не в 2 раза, а может быть и в десятки. А (повторюсь) отказ одной транзакции рушит весь диалог, потому что так по RFC3261 положено.
Эта реализация у нас уже работает. Применяется подход с virtual IP — который описан в документе, который ты назвал общим трепом.
Для случая простого SIP Proxy — это вообще не проблема, он ничего не помнит даже о текущей о транзакции. Для stateful proxy — надо реплицировать состояние транзакции между серверами — это уже задача прикладной логики и ни разу не фокус. Пример stateful proxy — это forking proxy, которая звонит тебе одновременно на несколько телефонов, пытаясь тебя найти. Для call stateful proxy — проблема полностью аналогична Web Application Server.
Причем, если тебе реально не требуется stateful и call stateful proxy, и ты можешь обойтись простым proxy (что более чем достаточно для обычного PBX) — то тебе даже состояние не надо реплицировать по кластеру.
N>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты.
Мы применяем virtual IP. Нам хватает.
N>Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти.
Для реальной надежности я могу дать клиенту отказ в продвинутом сервисе. Мне главное, чтобы а) это остальных клиентов не затронуло, и б) для этого клиента работал базовый сервис. Откинулся сервер — порвались его сессии, однако фэловер телефонов прошел — люди перезвонят, и все будет в порядке. Это вполне адекватная отказоустойчивость — сервер не каждый день ломается. А при программном сбое — последствия этого сбоя затронут только того UA, кто вызвал сбой.
G>>А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.
N>Ещё раз: если транзакция началась и сорвалась — диалог гибнет весь, потому что одна из сторон получает 408 или его аналог (внутренний таймаут), а ответ второй стороны может не дойти и поэтому суммарное состояние становится некорректным (расхождение между мнениями про, например, SDP). Поэтому писать, как ты пишешь,
stateless серверов, которыми являются proxy и stateful proxy
— некорректно. Даже если в момент гибели ноды транзакцию проходили 0.1% диалогов — эти 0.1% диалогов погибнут. Именно в этом проблема такой системы для прокси.
Корректно вполне. Виртуальные IP, и нет проблем. Умерла нода — ее IP мигрировал на соседний кластер. А если что там через сервер проходило — ничего страшного, SIP рассчитан на работу поверх UDP и потеря одного пакета ничего не означает.
К тому же, я не понимаю что плохого в том, что умрут диалоги в случае аппаратного сбоя. Это полная херня, пусть умирают. Перезвонят, не обломятся, не так часто аппаратные сбои происходят.
Вообще рассуждать о том насколько отказоустойчив SIP абстрактно, вне контекста приложений — довольно странное занятие.
N>Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно.
Что ты пишешь такое, что тебе принципиальна семантика B2BUA, и что тебе мешает воспользоваться virtual IP и реплицировать состояние на кластере — как это делают в веб? Медия у тебя как идет? Тоже через сервер? Короче, опиши приложение.
G>>Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.
N>Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".
1) Производительность сильно не просядет. SIP-сигнализация — не такая уж быстрая и требовательная к пропускной способности штука.
2) Не будет такого race condition. Не пошлет UA следующую транзакцию в диалоге, не дождавшись завершения предыдущей, а ведь ты не будешь завершать предыдущую транзакцию не отреплицировав состояние? Ну, если не вредитель конечно?
Вообще, странные вы, парни, проблемы находите. Эти проблемы ровным счетом ничем не отличаются от кластеров веба. Просто та же фигня, один в один.
Здравствуйте, eao197, Вы писали:
S>>Ну, обычно базовый разбор заголовков входит в обязанности HTTP-клиента. E>Тогда, как мне кажется, твое противопоставление сложности парсинга не актуально, посколько обычному программисту не приходится ручками работать с ASN.1 и с HTTP-заголовками.
Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
S>Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
_>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола). С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться.
В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
Здравствуйте, misha_irpen, Вы писали:
F>>То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично? _>Что-то я не уловил мысль. Входящий трафик на 100% состоит из HTTP-заголовкаов, а это значит что уменьшение их объема в пять раз, во столько же раз уменьшит эту составляющую (именно она является основной проблемой при поиске подходящего хостера).
Странная у Вас арифметика, какая-то сферическая в вакууме.
Если считать обычный GET состоящим из 450 байт (это я скормил своему браузеру URL на картинку и померял его) — на один запрос будет израсходовано:
1. TCP SYN — 46 байт
2. TCP ACK — 38 байт
3. GET — 40+450 байт
4. ACK на ответы сервера — ну раз картинки маленькие, посчитаем 5 ACK'ов по 38 байт
5. ACK на FIN сервера — 38 байт (считая, что сервер закрыл соединение первым)
Это я всё взял из реального tcpdump'а.
Если считать трафик по IP, то служебного содержания — 328 байт. (328+90)/(328+450) == 0.537..., то есть все безумные усилия по 5-кратному сокращению HTTP заголовка запроса дадут менее чем двукратное (46%) сокращение входящего трафика. Если трафик считается по Ethernet, то ещё хуже (ко всем размерам прибавить 14 и размер меньший чем 64 заменить на 64) — будет всего 35% сокращения.
А теперь попробуем вычислить, что сделать с протоколом, чтобы он все эти интересные подробности типа
во всех их видах сжал в 5 раз. Я не представляю себе, как это сделать.:)) Ну максимум полтора раза, и то — с натяжкой.
А полуторакратное сокращение GET'а даст 20% экономии входящего трафика. Стоит ли это той борьбы? Может, лучше просто пользоваться менее жлобским хостером?
There is some confusion about whether Apache supports the PUT method. In fact, Apache handles PUT exactly like it handles the POST method. That is, it supports it, but in order for it to do anything useful you need to supply a suitable CGI program. This is on contrast to the GET method, which Apache supports internally by sending back files or SSI documents.
На всякий случай перевожу главную фразу:
То есть, он [Апач] поддерживает их [GET и POST], но чтобы он мог сделать что-нибудь полезное, ты должен предоставить подходящую CGI-программу
А вообще, приличные веб сервера в таких случаях отдают не 200 ok, а 405 Method not allowed (кстати, первый попавшийся мне под руку Апач так и делает для PUT)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
_pk_sly wrote:
> S>HTTP > > Сюда же надо добавить лёгкую интергацию в существующую инфраструктуру: > NAT, прокси, куча библиотек и модулей. Всё это не надо писать заново, а > можно тупо воспользоваться.
Ещё элементарно добавляется s к концу... https то бишь.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
> Ну а если то, что вам нужно отдавать на клиента, лежит в готовом виде в > файловой системе, то опередить современный HTTP сервер вряд ли > удастся. Потому что редкий хардкорный программист рискнет писать свой > драйвер режима ядра — а именно это делает, к примеру, IIS 6 и новее.
А при чем здесь "лежит в готовом виде в файловой системе"? Для того,
чтобы отсылать готовое файло, есть функция TransmitFile. А IIS'овский
http.sys, если верить MS, занимается слудующим:
• Routing HTTP requests to the correct request queue.
• Caching of responses in kernel mode.
• Performing all text-based logging for the WWW service.
• Implementing Quality of Service (QoS) functionality, which includes
connection limits, connection timeouts, queue-length limits, and bandwidth
throttling
Т.е., непосредственно к оптимизации передачи относится, насколько я понимаю,
"Caching of responses in kernel mode". Причем сделано это, очевидно, в
первую голову для кэширования динамического контента — статический и так FS
закэширует.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sinclair, Вы писали:
S>Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
S>Итак, тема многолога: Протокол HTTP и его немерянная крутизна.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно. Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут. Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов. Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
Здравствуйте, Pzz, Вы писали:
C>>Зачем же сразу велосипеды? C>>Можно XMPP например использовать.
Pzz>Здесь, по-моему, надо соотносить свои потребности с имеющимися возможностями, и не впадать в крайности. С одной стороны, глупо изобретать самодельный HTTP. С другой стороны, не менее глупо пытаться загнать в рамки существующего протокола то, что в эти рамки не лезет. Конкретный выбор протокола очень зависит от задачи. Но обсуждать достоинства/недостатки существующих протоколов тем не менее осмысленно.
Конечно зависит от задачи. Голову ведь никто ещё не отменял . Просто зачастую, если хорошо поискать, можно найти готовый протокол с существующей реализацией, который подходит на 99%
Тут проблема не в текстовой природе. Все-таки жать по серьезному информацию нельзя, так как она обрабатывается оборудованием. А проблема в объеме информации. Тебе всегда нужно узнавать что какие CLR установлены, или форматы в Accept? Тебе нужно знать кто есть referer? Но вся эта требуха передается.
А текст хорош тем, что его легко расширять и вставлять туда можно все что угодно. Бинаризация — только сильно усложнит сам протокол без особого выйгрыша.
Здравствуйте, misha_irpen, Вы писали:
_>Здравствуйте, Игoрь, Вы писали:
_>Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям".
Бред. Вот как раз в случае бинарного протокола и будет: "ни себе ни людям". Ты вообще представляешь себе, что такое переносимый и расширяемый бинарный протокол прикладного уровня? Хоть с одним из них разбирался и работал? Тебе в любом случае придется делать маршалинг/анмаршалинг параметров, только в случае с текстом это будет гораздо проще и сделать можно в любой среде, а вот с бинарными данными — облом-с. Единственное преимущество бинарных протоколов — скорость. Которая нивелируется современными техническими средствами.
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. _>Давайте тогда не останавливаться на половине пути и сделаем текстовыми еще и исполняемые файлы вместе с базами данных. Вообще отлаживать просто будет. _>Для тестов и отладки можно (и нужно) написать отладочный инструмент. А эти отладочные "удобства" в мир выпускать не нужно. Вы исполняемые файлы, собранные в "target: debug", тоже распространяете?
Блин, да причем здесь бинарные и исполняемые файлы? К исполняемым файлам совсем другие требования, и не надо их сюда приплетать.
Кроме отладки есть еще поддержка, мониторинг и пр. Для текстового протокола я могу написать простой тестовый скрипт (или простенький клиент) практически на любом языке под любой платформой, админ может сделать тоже самое, в случае же бинарного протокола перспективы не радужные.
И>>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто кна ура, а можно и автогенераторами воспользоваться. _>Какие проблемы есть лично у меня я уже написал, а вы поскипали.
И какие, 100 месячных гиг? не смеши.
Здравствуйте, Sinclair, Вы писали:
GZ>>Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки? S>Ну, конечно же основная ошибка в том, что URL строится вручную, а не по-взрослому:
[skipped]
По взрослому, это с помощью вещей которые еще не вышли с беты? Вообще же автоматические перекодировщики — это драконы с несколькими головами. С одной стороны в тривиальных случаях хорошо. С другой стороны, для нетривиальных постоянно приходится сверять где и во что перекодируется и в какой вид. Если тебе get запрос надо выполнить в JavaScript, то придется сверяться в каком виде он будет на сервере, в HTML, в JavaScript, и наконец-то будет отослан в виде запроса. При этом амперсенды должны сохраняться в первозданном виде.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Игoрь, Вы писали:
И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ? И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Два разных кода для дебага и релиза? Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком;))
P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER;)) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.:)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Debug не распространяют, но тем не менее определенные отладочные средства в релиз таки включают, типа снятия мини-дампов в случае падения, логирования. Реальность ведь такова, что невозможно отловить все баги на этапе тестирования. А в случае с серверами ситуация немного другая. Во-первых, воспроизвести проблему бывает достаточно сложно, особенно, когда проявляется только под нагрузкой, и далеко не всегда есть возможность полной эмуляции рабочей системы. И как здесь может помочь дебажная версия протокола, если нужно продиагносцировать проблему на рабочем сервере? Во-вторых, цена простоя сервера бывает очень высока, это с экзешником можно ковыряться сколько угодно (хотя тоже не всегда), а с серверами проблему часто нужно фиксить "на лету" и быстро. Поэтому протокол лучше делать сразу читабельным.
Что касается двух версий протокола debug/release, это несерьезно. Если уж нужна читабельная отладочная информация, то конвертить бинарные данные лучше перед выводом в лог, но и здесь могу быть свои проблемы, например, в случае некорректности входных данных. Короче говоря, не нужно усложнять то, что можно не усложнять
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
PD>>>#ifdef DEBUG PD>>>...
N>>Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
PD>А что, замена одного формата данных на другой (при том. что между ними имееется взаимно-однозначное соответствие, о других вариантах и речи нет) так-таки и меняет логику ?
А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?
;)))
N>>Ну это только у вас с вижуал студией такие сложности.;)) В более... мнэээ... нормальных местах делается иначе. PD>No comment. :-)
Эт' хорошо — что Вы хотя бы понимаете, что не MSDev единым живо человечество.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму
Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п. Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
И>>Что касается двух версий протокола debug/release, это несерьезно. PD>Не debug/release (я это просто в качестве примера привел), а просто двух версий. Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму, остальные суть содержимое запроса. Кстати, конвертировать из бинарного в текстовый мог бы сам сервер (IIS) перед передачей приложению, так что ты бы ничего и не заметил.
Это сейчас и так есть — называется gzip encoding.
Она не захватывает заголовки, но это не создаёт особой разницы кроме некторых упомянутых частных случаев.
Здравствуйте, netch80, Вы писали:
N>Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально.
Я все-таки не понимаю. Если запрос будет переводиться из текстового вида в двоичный на выходе из броузера, а потом IIS переведет его обратно в текстовый перед тем, как отдать тебе, какой-такой разный код будет в твоем приложении ?
А если и не будет такого преобразования — не надо из мух слонов делать. Word поддерживает два десятка форматов, и чтение/запись в них — это разный код. И ничего страшного. Запись и чтение файла — это 1% от того, что содержит в себе Word.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>>?! Смотри, как это делается. Несколько способов. G>>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf C>Да я знаю. Костыли можно поставить кое-где.
Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC.
G>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами.
SIP НЕ stateful. Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Да я знаю. Костыли можно поставить кое-где. G>>Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC. C>С их помощью нельзя сделать failover для транзакций и диалогов. Поэтому идут в топку.
Для транзакций файловер вообще-то на практике не нужен. Но если очень хочется — то надо применять virtual IP. В точности так же, как и для HTTP.
G>>>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>>>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами. G>>SIP НЕ stateful. C>Нет. Он ЯВНО stateful, так как в самом протоколе прописаны транзакции, захватывающие несколько запросов (см. со страницы 122 в rfc3261).
Протокол — НЕ stateful, Cyberax. Ну что ты мне рассказываешь, а? SIP Proxy не обязан ничего помнить даже о текущей незавершенной транзакции. Спорим на деньги?
Насчет rfc — укажи название метода и конкретно — что за транзакция такая там прописана сказочная, которая через обычный Proxy пролезть не может.
G>>Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь? C>Да. Покажи мне SIP-сервер, который умеет делать failover в середине транзакции.
Да что мне его искать — он у нас работает в конторе сейчас. Приезжай в Москву — покажу . Построен на базе whackamole. Для этого подойдет вообще любой SIP Proxy Server. Потому что он не помнит состояния транзакции, он стэйтлес.
C>А я тебе покажу приложение, которое прозрачно делает failover для HTTP-запросов.
Virtual IP. Что мне смотреть-то на него? Отказоустойчивость в SIP и HTTP серверах обеспечивается СОВЕРШЕННО ОДИНАКОВО. Понимаешь? SIP by design так устроен .
>> В Апаче POST принимается расширением? .>Ещё можно добавить, что глагол может быть любым, можешь свой глагол придумать (webdav использует кучу разных глаголов, скажем COPY, MOVE, LOCK, MKCOL), веб-сервер же понимает только GET, остальное тупо спихивает пользовательским скриптам/модулям. Типичный веб-браузер умеет только GET и POST. Но это не ограничения протокола HTTP.
Из Яваскрипта уже можно и PUT и DELETE, если мне память не изменяет
Здравствуйте, 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 сигнализация — на управляющий трафик. Это три основных и принципиально несовместимых типа трафика, и странно, что Вы вместо адекватных обозначений вспоминаете что угодно, но не их.
Здравствуйте, Sinclair, Вы писали:
C>>>Там макросы для конкретного формата данных сделаны, AFAIR. Т.е. это примерно как разбор XML с помощью регэкспов. Pzz>>Насколько я понял, они там вполне универсальны, и позволяют разбирать более-менее любые структуры данных, описанные ASN'ом. S>Если бы это было так, никаких компиляторов ASN.1 было бы не надо.
Компилятор нужен для тех, кто хочет писать на настоящем ASN.1, а не на openssl'ных макросах странного вида.
Здравствуйте, 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>Здравствуйте, 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 миллисекунд.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>Ослабляет нагрузку чего? Просто на канал? Не вопрос. И с джиттером это мало связано — если пакет пропущен, но следующий приходит с адекватным timestamp, проблем нет — просто пропуск части данных.
V>На слух это ужасно, ведь пакеты не просто пропускаются, а иногда приходят не в том порядке.
Если Вы не заметили — в общем заголовке RTP по смещению 2 находится поле sequence number, а по смещению 4 — находится поле timestamp. Вот их достаточно, чтобы при приходе пакетов не в том порядке — упорядочить их как следует. А задержки вопроизведения согласно ожидаемому jitter'у — чтобы выходящий с ЦАП звук не рвался.
Главное, чтобы приёмная сторона не пыталась безумно увеличивать jitter buffer и соответствующую задержку только от того, что у передающей включился VAD.
N>>А теперь рассказываю, что будет, если связь просто пропадёт (например, при перестройке глобального раутинга какое-то время пакеты шли в интерфейс Null0): первый раз TCP сделает перепосылку через последний известный RTT, а второй — уже через три секунды (во всех известных мне реализациях). "А вот вам меч!" И страдайте теперь при мечтаниях про 150 миллисекунд.
V>Ну дык пауза в 3 сек и делов-то. И бывает это раз в пятилетку.
Увы, значительно чаще. Ваши условия слишком тепличны.
Здравствуйте, netch80, Вы писали: N>Кстати, для HTTP это тоже было бы полезно. Сейчас клиентские приложения вынуждены поллить сервер за новыми данными. А можно было бы сделать двустороннюю связь.
Не уверен, что это было бы полезно. Поллинг масштабируется гораздо лучше, чем двусторонняя связь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VGn, Вы писали:
G>>это если он ключи не перехватит. VGn>Педевикия
И что? Учим матчасть:
Боб выбирает пару (e, d) и отправляет e Алисе.
Но Джек, который сидит посредине открытого канала, выбирает свою пару ключей (e1, d1) и отправляет алисе e1.
Теперь Алиса шифрует сообщение m ключом Джека и отправляет ему с. Джек при помощи d1 дешфирует его, подменяет на m1, шифрует ключом e и отправляет Бобу. В итоге Алиса уверена, что отправляет тексты Бобу, а Боб ни в чём не уверен, потому что он опубликовал ключ для кого угодно.
Это называется атакой типа man-in-the-middle, и именно от нее защищают сертификаты, которые тебе так не нравятся.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше?
Здравствуйте, Pzz, Вы писали:
Pzz>Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно. Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут. Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов. Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
А какой протокол позволяет послать одновременно несколько запросов через одно соединение?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Pzz, Вы писали:
HB>>А какой протокол позволяет послать одновременно несколько запросов через одно соединение?
Pzz>Самодельный.
А, все понял. Не совсем "несколько запросов одновременно"; просто возможность послать следующий запрос, не дожидаясь ответа на предыдущие, так?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Curufinwe, Вы писали:
C>Зачем же сразу велосипеды? C>Можно XMPP например использовать.
Здесь, по-моему, надо соотносить свои потребности с имеющимися возможностями, и не впадать в крайности. С одной стороны, глупо изобретать самодельный HTTP. С другой стороны, не менее глупо пытаться загнать в рамки существующего протокола то, что в эти рамки не лезет. Конкретный выбор протокола очень зависит от задачи. Но обсуждать достоинства/недостатки существующих протоколов тем не менее осмысленно.
Здравствуйте, eao197, Вы писали:
E>Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
S>>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
E>Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
1. "Самописанные", т.е. нестандартизованные протоколы
2. Бинарные RMI/Corba
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey, Вы писали:
S>Т.е., непосредственно к оптимизации передачи относится, насколько я понимаю, S>"Caching of responses in kernel mode". Причем сделано это, очевидно, в S>первую голову для кэширования динамического контента — статический и так FS S>закэширует.
Нет. На всякий случай напомню, что FS кэширует дисковые страницы. А в httpResponse уезжают вовсе не они. Например, response может быть пожат gzip-ом.
Фишка в том, что статический контент отдается без перехода в user mode. Три драйвера договариваются между собой в режиме ядра.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Curufinwe, Вы писали:
C>А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше?
Честно признаюсь — XMPP не смотрел. На первый взгляд, удержание соединения обходится неприлично дорого. С другой стороны, для messaging, которое не сохраняет history на серверной стороне, такая схема может оказаться эффективнее. Надо изучать точнее. Асинхронное двустороннее общение (ака Email) совершенно точно прекрасно ложится в HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали: Pzz>Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно. Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут.
Кто "все"? Спецификация протокола явно описывает, как управлять соединением. Если кто-то рвет — это его дело. Pzz>Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов.
Что значит "одновременно"?
На всякий случай напомню, что в сокете ровно 1 stream, в который нужно писать байты по очереди.
Если речь о том, что клиенту нужно дожидаться ответа на каждый запрос, то это заблуждение. Читайте раздел 8.1.2.2 Pipelining:
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
Pzz> Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
Поэтому HTTP работает быстро, даже для коротких запросов с небольшим количеством возвращаемых данных.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Если речь о том, что клиенту нужно дожидаться ответа на каждый запрос, то это заблуждение. Читайте раздел 8.1.2.2 Pipelining: S>
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
Pzz>> Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных. S>Поэтому HTTP работает быстро, даже для коротких запросов с небольшим количеством возвращаемых данных.
ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос
q1 выполняется долше всего...
Здравствуйте, Shabi, Вы писали: S>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>q1 выполняется долше всего...
Открывай несколько параллельных коннектов. S>...я ж говорю...HTTP ОТСТОЙ
А какой протокол умеет автоматически переупорядочивать запросы?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
HB>>А какой протокол позволяет послать одновременно несколько запросов через одно соединение?
E>Short Message Peer-to-Peer (SMPP) E>External Machine Interace/Universal Computer Protocol (EMI/UCP).
+
Blocks Extensible Exchange Protocol (BEEP)
Здравствуйте, eao197, Вы писали: E>Short Message Peer-to-Peer (SMPP)
Ну, реально его основное отличие — это умение сервера возврашать acknowlegement in skew order. Это, конечно, оно да. В HTTP простыми средставми малодостижимо.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
> S>Т.е., непосредственно к оптимизации передачи относится, насколько я > понимаю, > S>"Caching of responses in kernel mode". Причем сделано это, очевидно, в > S>первую голову для кэширования динамического контента — статический и так > FS > S>закэширует. > Нет. На всякий случай напомню, что FS кэширует дисковые страницы. А > в httpResponse уезжают вовсе не они. Например, response может быть пожат > gzip-ом.
Что мешает положить на диск готовые ответы?
> Фишка в том, что статический контент отдается без перехода в user mode. > Три драйвера договариваются между собой в режиме ядра.
Это да. Хотя в случае статического контента на мой взгляд это совсем уж
копейки.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sinclair, Вы писали:
C>>А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше? S>Честно признаюсь — XMPP не смотрел. На первый взгляд, удержание соединения обходится неприлично дорого. С другой стороны, для messaging, которое не сохраняет history на серверной стороне, такая схема может оказаться эффективнее. Надо изучать точнее. S>Асинхронное двустороннее общение (ака Email) совершенно точно прекрасно ложится в HTTP.
В случае с email согласен, но для instant messaging HTTP может хоть как-то подойти только в виде COMET — т.е. опять постоянное удержание соединения.
Миф номер 3: Ага! Клиент-то может и маленький, а сервер? Он же тормозит!
S>Ну, вообще-то, смотря какой сервер, и что понимается под "тормозит". Обычно, stateless HTTP сервер рвет аналогичный по функционалу сервер с удержанием соединения как тузик грелку. Потому, что HTTP клиент работает в "импульсном" режиме: сбегал к серверу (за 40 миллисекунд), и тупит локально, до следующего запроса. Редкий пользователь кликает ссылку ежесекундно. S>(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален) S>Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.
Случай с веб-сервисами. Запросов через веб-сервисы легко может быть до сотен и тысяч в секунду.
Здравствуйте, vb-develop, Вы писали:
S>>(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален) S>>Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.
VD>Случай с веб-сервисами. Запросов через веб-сервисы легко может быть до сотен и тысяч в секунду.
От одного клиента?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vb-develop, Вы писали:
S>>>(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален) S>>>Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.
VD>>Случай с веб-сервисами. Запросов через веб-сервисы легко может быть до сотен и тысяч в секунду. S>От одного клиента?
Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
GZ>Было бы все так красиво — жил бы себе не тужил. Лучше не воспевать достоинства, а учитывать недостатки. GZ>Про асинхронку уже было сказано. А вот про то, что это текстовой формат — нет. Проблема в том, что он не просто текстовой(я говорю не о боди). Он US-ANSII. То что мы в url видим всякую фигню — это полбеды. Сам заголовок приходится перекодировать. И не просто перекодировать. А еще с учетом 78/998.
Непонятно, зачем тебе бинарные данные в заголовке. Стандарт на представление non-ASCII characters в Header устоялся уже очень давно. Стандарт на переносы длинных строк — тоже.
GZ>Говорить о том, что http простой протокол не приходится.
Смотря для чего. Еще раз напомню, что не пользуешься — не платишь. Не нужны русские символы в заголовках (а это редкость, кроме filename в Content-Disposition вроде и некуда особо запихать-то) — не учи RFC 2047.
GZ> Для выяснения того, или иного вопроса приходится бегать по куче RFC.
Это да. Зато такая дикость позволяет процветать профессионалам. Вот почему ты думаешь адвокаты в Штатах столько зарабатывают?
GZ>Клиенты в связи со сложностью — достаточно глючные. Ну например из показательных, IE в случае если в доменном имени встретилось подчеркивание — обрубает куки.
Ну, не то чтобы обрубает... Он просто не считает хост, на который ты идешь, соответствующим тому хосту, для которого кука.
А вот нехрен делать подчерк в имени хоста — это нарушает стандарт. GZ>Почему не выводит ошибки, непонятно. Зависимость между куками и url — очень плохо прослеживается. Opera и Firefox — вообще не обрабатывают такую ситуацию, и безошибочно работают.
GZ>Сложность расширения с помощью DAV.
Не понял. Все расширения в протоколе делаются более-менее одинаково. GZ>Ну нет нормальной поддержки в которую можно внедрится безопасно и сэмулировать fs ни в IIS, ни в Apache.
Это не проблема протокола. Не вижу принципиальной проблемы сделать WebDAV Server Framework на, к примеру, .Net. GZ>Только ручная реализация(по крайней мере IIS). О клиенте вообще не говорю.(поддержка Dav в виндах выключена в целях безопасности).
Я вообше пока не уверен, что DAV — сильно хорошая идея. Уж очень он радикально HTTP расширяет. Хотя есть некоторые и удобства — скажем, автоматическая доступность контента в Generic Http клиенте.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Curufinwe, Вы писали:
C>>>А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше? S>>Честно признаюсь — XMPP не смотрел. На первый взгляд, удержание соединения обходится неприлично дорого. С другой стороны, для messaging, которое не сохраняет history на серверной стороне, такая схема может оказаться эффективнее. Надо изучать точнее. S>>Асинхронное двустороннее общение (ака Email) совершенно точно прекрасно ложится в HTTP. C>В случае с email согласен, но для instant messaging HTTP может хоть как-то подойти только в виде COMET — т.е. опять постоянное удержание соединения.
HTTP для IM не предназначался изначально, потому и использовать его для этих целей не стоит. HTTP разрабатывался для гипертекстовых систем, где работа осуществляется по принципу "запрос-ответ".
Здравствуйте, anonymous, Вы писали:
A>HTTP для IM не предназначался изначально, потому и использовать его для этих целей не стоит. HTTP разрабатывался для гипертекстовых систем, где работа осуществляется по принципу "запрос-ответ".
Замечательно
А то тут пытаются нас убедить, что HTTP подходит для всего кроме двухстороннего media streaming
Здравствуйте, vb-develop, Вы писали:
VD>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
Могло. Если lag существенный по сравнению со временами обработки сервера/простоя на клиенте.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Curufinwe, Вы писали:
A>>HTTP для IM не предназначался изначально, потому и использовать его для этих целей не стоит. HTTP разрабатывался для гипертекстовых систем, где работа осуществляется по принципу "запрос-ответ". C>Замечательно C>А то тут пытаются нас убедить, что HTTP подходит для всего кроме двухстороннего media streaming
Сейчас есть множество расширений протокола, но от заложенного изначально "ограничения" полностью избавиться нельзя, т. е. полноценного дуплекса мы не получим.
Здравствуйте, Sinclair, Вы писали:
>Непонятно, зачем тебе бинарные данные в заголовке. Стандарт на представление non-ASCII characters в Header устоялся уже очень давно. Стандарт на переносы длинных строк — тоже.
Устоялся. Только это называется — ноги от Arpanet'а(RFC 822)
Ну примерно:
Попробуй напиши это правильно. Так чтобы работало.
GZ>>Говорить о том, что http простой протокол не приходится. S>Смотря для чего. Еще раз напомню, что не пользуешься — не платишь. Не нужны русские символы в заголовках (а это редкость, кроме filename в Content-Disposition вроде и некуда особо запихать-то) — не учи RFC 2047.
Есть еще Content-Description. Но задача по Content-Disposition встречается в каждом втором проекте.
S>Это да. Зато такая дикость позволяет процветать профессионалам. Вот почему ты думаешь адвокаты в Штатах столько зарабатывают? S>Ну, не то чтобы обрубает... Он просто не считает хост, на который ты идешь, соответствующим тому хосту, для которого кука. S>А вот нехрен делать подчерк в имени хоста — это нарушает стандарт.
Да понимаешь в чем дело. Не нарушает это Microsoft стандарт. Я то разрабатываю. А администратор ставит. ASP.NET приложение каждый запрос пытается аутентифицироваться. Ему и не надо знать что такое http only куки. Юникс системы он видел только на картинках. Он спец по Microsoft. В результате, потратив свое время на то, чтобы испробоваnm все что можно он звонит не адвокату, не в Microsoft, а мне.. Тратит мое время. А я это — не люблю. Мне платят за разработку.
GZ>>Ну нет нормальной поддержки в которую можно внедрится безопасно и сэмулировать fs ни в IIS, ни в Apache. S>Это не проблема протокола. Не вижу принципиальной проблемы сделать WebDAV Server Framework на, к примеру, .Net.
Именно этим и приходится периодически заниматься. Опять же, я ленив. Мне нужно блюдечко с голубой каемочкой. А его там нет.
GZ>>Только ручная реализация(по крайней мере IIS). О клиенте вообще не говорю.(поддержка Dav в виндах выключена в целях безопасности). S>Я вообше пока не уверен, что DAV — сильно хорошая идея. Уж очень он радикально HTTP расширяет. Хотя есть некоторые и удобства — скажем, автоматическая доступность контента в Generic Http клиенте.
Трабла в том, что прозрачно из DAV файловая система не эмулируется. И соответсвенно, поддержка простых редакторов данной FS — сложная задача. Microsoft вообще работает по нескольким своим стандартам чтобы эмулировать файловую систему через http.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Shabi, Вы писали: S>>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>>q1 выполняется долше всего... S>Открывай несколько параллельных коннектов.
ну...объясни — зачем все эти извращения?
S>>...я ж говорю...HTTP ОТСТОЙ S>А какой протокол умеет автоматически переупорядочивать запросы?
причем тут переупорядочивание ищи по теме full duplex protocol
(я использую самописный протокол. открываеца только один сокет... клиенту ненужно думать о том в какой последовательности кидать вопросы и в какой последовательности придут ответы)
полагаешь мне обеспечена медалька за прорыв в коммуникациях?
Здравствуйте, vb-develop, Вы писали:
S>>От одного клиента?
VD>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
Здравствуйте, Sinclair, Вы писали:
S>>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>>q1 выполняется долше всего... S>Открывай несколько параллельных коннектов.
Уж лучше сразу вернуть статус "ОК" (типа, принято в очерель) + послать потом N команд типа, вернуть результат первого выполненного (или результаты M-выполненых запросов) запроса. Но это еще один протокол сверху получается.
Здравствуйте, Shabi, Вы писали:
S>Здравствуйте, vb-develop, Вы писали:
S>>>От одного клиента?
VD>>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему.
S>как бы не наоборот...ухудшило
Здравствуйте, Curufinwe, Вы писали:
C>Здравствуйте, Mamut, Вы писали:
GZ>>>Тебе нужно знать кто есть referer?
M>>На этом весь SEO держится Знать надо
C>Who is f**ing SEO?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vb-develop, Вы писали:
VD>>Была потребность отправлять через веб-сервисы до сотни запросов в секунду от одного клиента. Работало медленно в первую очередь из-за синхронности запросов. Думаю использование keep-alive могло решить эту проблему. S>Могло. Если lag существенный по сравнению со временами обработки сервера/простоя на клиенте.
Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже.
Здравствуйте, Mamut, Вы писали:
M>На этом весь SEO держится Знать надо
И что из этого? Разве нельзя получать нужную информацию другим запросом? К тому же, получение referer — не гарантировано. Многие прокси их отрубают в целях безопасности.
Здравствуйте, Mamut, Вы писали:
GZ>>И что из этого? Разве нельзя получать нужную информацию другим запросом? M>Каким?
Да например, при первом запросе, сервер проверяет какие параметры есть в хедере, ну например, установлен ли Java или CLR. Если данной информации нет, то он возвращает запрос с каким-то не 200-ым кодом, и говорит что для работы с сайтом нужна такая-то информация в хедере. Клиент вставляет повторяет запрос уже с информацией о версии Java или CLR. Также он вставляет данную информацию для всех запросов на данный сайт.
GZ>>>И что из этого? Разве нельзя получать нужную информацию другим запросом? M>>Каким? GZ>Да например, при первом запросе, сервер проверяет какие параметры есть в хедере, ну например, установлен ли Java или CLR. Если данной информации нет, то он возвращает запрос с каким-то не 200-ым кодом, и говорит что для работы с сайтом нужна такая-то информация в хедере. Клиент вставляет повторяет запрос уже с информацией о версии Java или CLR. Также он вставляет данную информацию для всех запросов на данный сайт.
Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)...
HB>А, все понял. Не совсем "несколько запросов одновременно"; просто возможность послать следующий запрос, не дожидаясь ответа на предыдущие, так?
Почти, по идее можно и так:
Здравствуйте, Mamut, Вы писали:
M>Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)...
Нет — однонаправленный. Если посмотришь на Microsoft безопасность, то она обходится двумя односторонними вызовами.
Ну еще раз:
1. Эксплорер направляет запрос на страницу
2. Сервер знает что для отображения данной страницы нужно наличие Java5. Он отправляет в ответ только Http заголовок, например с параметром, Required: Java5 и кодом возврата 333.
3. Эксплорер увидев код 333, читает required и если у него зарегистрирована Java5, то оно добавлет в Http заголок информацию о поддержке Java5, и отправляет тот же запрос заново.
4. Сервер увидев что в запросе все нужные параметры есть — начинает обработку.
Если информация клиентом уже указана, то это один запрос. Не указана — два запроса. Но зато все адресно, и расширяемо. Так можно указывать заказывать информацию технического характера. И это управляется сервером, а не клиентом.
M>Имхо, слишком сложно без явных выгод.
Выгоды в принципе есть. У меня в заголовке пересылается информация о всех FW и Java. Да тут даже выйгрыш не в объеме, а в гибкости. Можно предоставлять больше информации о возможностях клиента.
M>>Не представляю, как это сделать так, чтобы оно работало Например, если мне вдруг понадобился какой-то заголовок, то я просто напишу в любом месте своего кода что-нить типа headers('HTTP_REFERER'). А в предложеном варианте как минимум усложняются анализаторы языков программирования, которые должны вычленить все запросы, на каждый запрос устроить общение с клиентом (предположим, что у нас диалог двунаправленый, а не однонаправленый, как сейчас)... GZ>Нет — однонаправленный. Если посмотришь на Microsoft безопасность, то она обходится двумя односторонними вызовами. GZ>Ну еще раз:
[skip]
Думаю, Михаил (misha_irpen) за такие запросы туда-сюда просто порэжет на куски, да
M>>Имхо, слишком сложно без явных выгод. GZ>Выгоды в принципе есть. У меня в заголовке пересылается информация о всех FW и Java. Да тут даже выйгрыш не в объеме, а в гибкости. Можно предоставлять больше информации о возможностях клиента.
Возможно. Но ту схему надо еще продумывать и продумывать. Особенно придумывать защиту от дурака-программиста
Здравствуйте, misha_irpen, Вы писали:
S>>Во-вторых, HTTP устроен так, что "не надо платить за то, чего не используешь". Если модные сервисы от него не нужны, то накладные расходы на заголовки HTTP близки к нулю. _>Небольшая мысль вслух того, кто чувствует эти нулевые накладные расходы ежемесячно.
_>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика. А то я могу и на бинарке сотни терабайт накопать:)) И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы.
_>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
Затем, что автоматически получается гибкость, расширяемость, простота диагностики, а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем.
Здравствуйте, Shabi, Вы писали:
S>Здравствуйте, misha_irpen, Вы писали:
_>>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей.
S>...эти все подлянки из юниксов вестимо...задолбало такое наследие
Вот не надо с больной головы на здоровую переваливать.
Юниксоеды отлично знают, где нельзя текст применять. А также знают, чем хорошо его применять там, где можно.
Здравствуйте, netch80, Вы писали:
N>Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика.
Тут уже писал: http://rsdn.ru/forum/message/2904051.1.aspx
N>И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы.
Страницы как таковой нет, 99.999% запросов к серверу идут из <img src=..., расположенных на левых сайтах.
N>Затем, что автоматически получается гибкость, расширяемость, простота диагностики,
размер, необходимость парсинга.
N>а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем.
Я не готов просто взять и немедленно предложить бинарную альтернативу, я просто указал на живой пример поблемы, связанной с текстовой рулезностью HTTP.
T>Кстаааааати, исполняемые файлы говорите... Хм, пойду оформлю патент... А, блин, это ж называется распространением в исходниках.
Нееееее!
Я предложил сделать текстовыми именно исполняемые файлы. Или другими словами повсеместно перейти на скрипты (и даже процессоры заставить испольнять эти скрипты непосредственно).
Здравствуйте, Игoрь, Вы писали:
_>>Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям". И>Бред.
Ну бред так бред. Чего с бредящим споришь-то? Я свою точку зрения высказал, а доказывать свое здравомыслие не собирался ни секунды.
Здравствуйте, misha_irpen, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика. _>Тут уже писал: http://rsdn.ru/forum/message/2904051.1.aspx
5%. В общем, не цифра. А извращённые хостеры... ну да, бывают. Им же надо стероиды применять, чтобы крутыми казаться.
N>>И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы. _>Страницы как таковой нет, 99.999% запросов к серверу идут из <img src=..., расположенных на левых сайтах.
Эти img src на каких-то таки страницах. Но я понял.:)
N>>Затем, что автоматически получается гибкость, расширяемость, простота диагностики, _>размер, необходимость парсинга.
Обратите внимание, что раньше 5-го уровня OSI текст не применяют. Вот там действительно критично. А на верхних, как Вы заметили — 5%. Редко где больше. Зато читается.
А вот про необходимость парсинга — см. ниже.
N>>а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем. _>Я не готов просто взять и немедленно предложить бинарную альтернативу, я просто указал на живой пример поблемы, связанной с текстовой рулезностью HTTP.
Ну вот именно, что предложить альтернативу Вы не можете, зато проехаться тяжёлым танком — сколько угодно. Думаете, остальные не знают, что текст надо парсить и что это проблема? Мне SIP с этими заморочками уже снится. Но когда я пытаюсь нарисовать, как бы выглядел протокол, который в этом плане сильно легче — получаются совсем уже нецензурные монстры. В лучшем случае это тот же BER.
Здравствуйте, misha_irpen, Вы писали:
T>>Кстаааааати, исполняемые файлы говорите... Хм, пойду оформлю патент... ;) А, блин, это ж называется распространением в исходниках. :-\ _>Нееееее! :) _>Я предложил сделать текстовыми именно исполняемые файлы. Или другими словами повсеместно перейти на скрипты (и даже процессоры заставить испольнять эти скрипты непосредственно).
В какой-то мере это происходит. Например, с явой или дотнетом и JIT. Но для "нативного" приложения — смысла нет именно потому, что в 99% систем файл мапится в память и должен быть по возможности временно отмаплен (когда VM чистит память). С тем, что парсится, так не получится. Не думаю, что Вы этого не знаете. Но — продолжаете ёрничать.:(
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика _>Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые обытки, в отличии от исходящего.
То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично?
То есть понятно, лишнее — да, но вроде это не составляет кардинальной разницы даже в данном случае...?
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика _>>Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые убытки, в отличии от исходящего. F>То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично?
Что-то я не уловил мысль. Входящий трафик на 100% состоит из HTTP-заголовкаов, а это значит что уменьшение их объема в пять раз, во столько же раз уменьшит эту составляющую (именно она является основной проблемой при поиске подходящего хостера).
F>То есть понятно, лишнее — да, но вроде это не составляет кардинальной разницы даже в данном случае...?
Средний рамер отдаваемого файла -- 15 килобайт, тут заголовок не так критичен, но тут и страфиком проблем меньше.
Здравствуйте, netch80, Вы писали:
N>Если считать обычный GET состоящим из 450 байт (это я скормил своему браузеру URL на картинку и померял его) — на один запрос будет израсходовано:
Вот из этих 450 байт и набегает 100-130 ГБ в месяц.
N>Ну максимум полтора раза, и то — с натяжкой.
А данному сервису все эти мегаинтересные подробности, простите, нафиг не упали. Если бы протокол был еще и адаптивным, то вероятно это решило бы проблему.
N>А полуторакратное сокращение GET'а даст 20% экономии входящего трафика. Стоит ли это той борьбы? Может, лучше просто пользоваться менее жлобским хостером?
Тут все в деньги упирается, сервису нужно не менее 2.5 ТБ суммарного трафика в месяц, а при нежлобском хостере это вываливается в сумму, которая выше дохода от рекламы. Вот такая сферическая арифметика...
Здравствуйте, Pzz, Вы писали:
Pzz>Не надо считать юниксоидов полными идиотами. В конце концов, многие вещи пришли именно оттуда, а это что-нибудь да значит.
Идиотами? Да вы что! Лично мне некоторые юниксоидные вещи очень нужны и в виндах (например меня сильно "расстраивает", когда программа не понимает параметров командной строки). Но все перечисленные вами удобства хороши на этапе отладки, а в реальной эксплуатации от них немало проблем добавляется.
Здравствуйте, misha_irpen, Вы писали:
N>>Ну максимум полтора раза, и то — с натяжкой. _>А данному сервису все эти мегаинтересные подробности, простите, нафиг не упали. Если бы протокол был еще и адаптивным, то вероятно это решило бы проблему.
И как? Особенно без лишнего round-trip'а.
Здравствуйте, anonymous, Вы писали: A>Сейчас есть множество расширений протокола, но от заложенного изначально "ограничения" полностью избавиться нельзя, т. е. полноценного дуплекса мы не получим.
Я не очень понимаю, что называется "полноценным дуплексом", но вообще говоря, в HTTP нет только message reordering. Сервер и клиент могут вести передачу достаточно асинхронно, это заложено в протоколе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shabi, Вы писали: S>ну...объясни — зачем все эти извращения?
В общем случае — затем, что сервер должен понимать семантику запросов, в частности зависимость результатов запросов от порядка выполнения.
В твоем случае протокол устроен так, что зависимости нет — HTTP об этом не знает. Единственный способ
S>>>...я ж говорю...HTTP ОТСТОЙ S>>А какой протокол умеет автоматически переупорядочивать запросы? S>причем тут переупорядочивание ищи по теме full duplex protocol
Поискал. Либо ты используешь какое-то самоизобретенное значение для известного термина, либо я чего-то не понимаю.
Вот смотри: http://www.computerhope.com/jargon/f/fulldupl.htm
В HTTP так и есть: сервер может отдавать данные одновременно с клиентом. Приведи, пожалуйста, свое определение full duplex protocol, можно даже без источника.
S>(я использую самописный протокол. открываеца только один сокет... клиенту ненужно думать о том в какой последовательности кидать вопросы и в какой последовательности придут ответы)
Вот это и есть — переупорядочивание ответов. S>полагаешь мне обеспечена медалька за прорыв в коммуникациях?
Думаю, что нет. Думаю, что наверняка готовый протокол с поддержкой переупорядочивания сообщений уже есть, и не один.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vb-develop, Вы писали: VD>Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже.
Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, misha_irpen, Вы писали: _>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Миша, а какой у вас cache hit ratio?
Покажи пожалуйста на этот сервер — хочу посмотреть, что и куда ездит.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
GZ>>Попробуй напиши это правильно. Так чтобы работало. S>А это-то тут причем? 78 символов относится исключительно к заголовкам.
Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки?
GZ>>ASP.NET приложение каждый запрос пытается аутентифицироваться. Ему и не надо знать что такое http only куки. S>Кому не надо?
Админу.
S>Это не вина протокола. Блюдечка с голубой кайомочкой нет нигде. Я вот всю жизнь сталкивался с тем, что то, чего мне хотелось, в природе отсутствовало. Только потом, лет через пять, это оказывалось самым что ни на есть мейнстримом и попадало в руки индусам. Но к тому моменту передо мной уже стояла следующая задача, и опять везде полный вакуум.
Вот и Http — это не блюдечко. Его делали умные люди, но у него серьезные проблемы в связи с наследием Arpanet. У него правда есть одно достоинство которое перевешивает все. Этот стандарт глобален, и поддерживается различными инструментами. И эти инструменты всегда под руками. Посему, пока альтернативы нет, и не будет. Даже когда и появится альтернатива, то ситуация будет напоминать ситуацию с TCPv6. Назрело, но серьезного повсеместного внедрения нет. TCPv4 — поддерживается глобально.
GZ>>>Попробуй напиши это правильно. Так чтобы работало. S>>А это-то тут причем? 78 символов относится исключительно к заголовкам. GZ>Это задача не на длину, а на перекодирование. Ты серьезно не заметил здесь ошибки?
Ну, конечно же основная ошибка в том, что URL строится вручную, а не по-взрослому:
GZ>Вот и Http — это не блюдечко. Его делали умные люди, но у него серьезные проблемы в связи с наследием Arpanet. У него правда есть одно достоинство которое перевешивает все. Этот стандарт глобален, и поддерживается различными инструментами. И эти инструменты всегда под руками.
Угу. И очень много вещей, которые автору самопального протокола надо еще продумать, уже продуманы. GZ>Посему, пока альтернативы нет, и не будет. Даже когда и появится альтернатива, то ситуация будет напоминать ситуацию с TCPv6. Назрело, но серьезного повсеместного внедрения нет. TCPv4 — поддерживается глобально.
Это дополнительное преимущество.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю... S>Миша, а какой у вас cache hit ratio?
А что это?
S>Покажи пожалуйста на этот сервер — хочу посмотреть, что и куда ездит.
ticker.7910.org
Здравствуйте, GlebZ, Вы писали:
GZ>Вообще же автоматические перекодировщики — это драконы с несколькими головами. С одной стороны в тривиальных случаях хорошо. С другой стороны, для нетривиальных постоянно приходится сверять где и во что перекодируется и в какой вид. Если тебе get запрос надо выполнить в JavaScript, то придется сверяться в каком виде он будет на сервере, в HTML, в JavaScript, и наконец-то будет отослан в виде запроса. При этом амперсенды должны сохраняться в первозданном виде.
Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки.
Еще как стремятся. Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых.
Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. Тебе не надо сериализовать запросы в другую среду, типа Html, или JavaScript. И там нет конфликтующих перекодировок типа HTML.
Здравствуйте, GlebZ, Вы писали:
AVK>>Только почему то в SQL вроде как уже не стремяться параметры в запрос передавать конкатенацией строки. GZ>Еще как стремятся.
Если только от большого ума.
GZ> Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых.
То есть лично ты дату отдаешь строкой, как это делаешь в случае URL?
GZ>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры.
Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY. Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Gaperton, Вы писали: G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. (Побежал в гугл читать про SIP)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
[стошнило]
SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.
Здравствуйте, misha_irpen, Вы писали:
_>Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
А мне кажется, что если бы формат заголовков был бинарным, то размеры не сократились бы в разы... Так..процентов на 10% наверное. Ведь URL и те же cookie, которые составляют основную по объему часть GET запроса всё равно остались бы текстовыми строками. А можешь привести типичный запрос GET на тот сайт, про который ты написал. Интересно посмотреть сколько всё-таки информации можно сэкономить на бинарном формате.
Здравствуйте, misha_irpen, Вы писали:
_>Спасибо, учтем.
Расскажешь о результатах?
Я бегло посмотрел сервера линеечек в рунете — 100% делают ту же самую ошибку. Т.е. использовать nginx и возвращать 304 догадались все. У вас есть шанс стать первыми, кто сервит линеечки вовсе без обращения к серверу
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
GZ>> Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых. AVK>То есть лично ты дату отдаешь строкой, как это делаешь в случае URL?
Ессно — нет. Есть стандартный способ передачи параметров через DbParameters или аналогичные структуры в любом интерфейсе работы с БД. Не использовать его по назначению могут только новички.
GZ>>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. AVK>Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY.
Второе — зависит от используемой базы. Первое, так как целочисленное значение, легко делается и так.
AVK>Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием.
При чем тут LinkLabel? LinkLabel — winform'овская штукенция предназначенная для использования WinForms. Пример был описан от ASP.NET. А трабла тут следующая. Строка запроса должна быть переведена в стандарт Html а затем в стандарт Url. При этом, Html стандарт держит различные кодировки, но для Url — кодировка одна. Все что больше 7 бит, пробелы и служ. символы должно переводится в процентики с кодами. Амперсенд — служебный в обоих случаях.
Стандартные способы на генерации get запроса(из того что выпущено на данный момент):
1. Uri, UriBuilder — подходит для WebRequest но не для ASP.NET. В Html формат — не перекодирует.
2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату.
3. HttpUtility, HttpServerUtility — практически то что нужно, но море ручного труда по той же сборки в строку запроса GET.
А нормальных, не ручных, средств сборки get запросов — нету. В отличие от той же базы данных.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
...The AMQP model was conceived with the following goals:
1. To support the semantics required by the financial services industry.
2. To provide the levels of performance required by the financial services industry.
3. To be easily extended for new kinds of message routing and queuing.
4. To permit the server's specific semantics to be programmed by the application, via the protocol.
5. To be flexible yet simple.
...The design of the AMQP Model was driven by these requirements:
1. To guarantee interoperability between conforming implementations.
2. To provide explicit control over the quality of service.
3. To support any middleware domain: messaging, file transfer, streaming, RPC, etc.
4. To accommodate existing open messaging API standards (for example, Sun's JMS).
5. To be consistent and explicit in naming.
6. To allow complete configuration of server wiring via the protocol.
7. To use a command notation that maps easily into application-level API's.
8. To be clear, so each operation does exactly one thing.
The design of the AMQP transport layer was driven by these main requirements, in no particular order:
1. To be compact, using a binary encoding that packs and unpacks rapidly.
2. To handle messages of any size without significant limit.
3. To permit zero-copy data transfer (e.g. remote DMA).
4. To carry multiple sessions across a single connection.
5. To allow sessions to survive network failure, server failover, and application recovery.
6. To be long-lived, with no significant in-built limitations.
7. To be asynchronous.
8. To be easily extended to handle new and changed needs.
9. To be forward compatible with future versions.
10. To be repairable, using a strong assertion model.
11. To be neutral with respect to programming languages.
12. To fit a code generation process.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. AVK>>Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY. GZ>Второе — зависит от используемой базы.
Ты думаешь я об этом не знал?
AVK>>Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием. GZ>При чем тут LinkLabel? LinkLabel — winform'овская штукенция предназначенная для использования WinForms.
Я про WebForms, не помню как там аналогичный контрол называлсч. Главное, у него есть свойство Uri, которое при генерации HTML закодируется как оно надо. Полный аналог параметров SQL запроса.
GZ>Строка запроса должна быть переведена в стандарт Html а затем в стандарт Url. При этом, Html стандарт держит различные кодировки, но для Url — кодировка одна. Все что больше 7 бит, пробелы и служ. символы должно переводится в процентики с кодами. Амперсенд — служебный в обоих случаях.
Ты думаешь я об этом не знал?
GZ>2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату.
Напиши своего наследника, делов то.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>[стошнило] C>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.
Здравствуйте, netch80, Вы писали:
C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>А что для этого нужно? Давай RFC draft нарисуем
Для чего нужны load ballancing и failover?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Я про WebForms, не помню как там аналогичный контрол называлсч. Главное, у него есть свойство Uri, которое при генерации HTML закодируется как оно надо. Полный аналог параметров SQL запроса.
Нету. Было-бы, я бы так не возмущалси, не плакалси горючими слезами.
GZ>>2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату. AVK>Напиши своего наследника, делов то.
Наследников нужно будет чуть ли не на 50 процентов контролов делать . Get — запросы это не только в HyperLink. А исчо есть клиентские контролы. Они ваще не перекодируют в html, а требуют чтобы в них так и писали. То есть:
<a href="MyPage.html?name=n1&name" />
и
<asp:Hyperlink runat="server" NavigateUrl="MyPage.html?name=n1&name"/>
сгенерят разный код. Первый сгенерит амперсанды один в один. Второй заменит & на &. А еще иногда нужно всю эту шарагу на уровне JavaScript собирать. Там тоже те же тараканы, весом поменьше.
Вобщем, сборка строки в SQL и URL — разные по сложности вещи.
Здравствуйте, GlebZ, Вы писали:
GZ>Наследников нужно будет чуть ли не на 50 процентов контролов делать
Только это не проблема HTTP, а проблема ASP.NET.
GZ>Вобщем, сборка строки в SQL и URL — разные по сложности вещи.
Они разные по сложности, потому что в одном случае есть готовая реализация, а в другом нету. Инкапсулировать все эти СТРАШНЫЕ УЖАСЫ в простенькое API — задачка для студента 3 курса.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, GlebZ, Вы писали:
GZ>Наследников нужно будет чуть ли не на 50 процентов контролов делать . Get — запросы это не только в HyperLink. А исчо есть клиентские контролы. Они ваще не перекодируют в html, а требуют чтобы в них так и писали. То есть: GZ><a href="MyPage.html?name=n1&name" />
Так писать неправильно. Символ '&', являющийся частью URI, при использовании в HTML должен кодироваться в &.
Здравствуйте, Shabi, Вы писали:
И>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал
А функции типа htons/htonl видел?l
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>когда ты последний раз отлаживал TCP/IP?
Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня.
Здравствуйте, WolfHound, Вы писали:
C>>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>>А что для этого нужно? Давай RFC draft нарисуем WH>Для чего нужны load ballancing и failover?
Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
Здравствуйте, netch80, Вы писали:
C>>[стошнило] C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>А что для этого нужно? Давай RFC draft нарисуем
Ну "большой" телеком это вроде умеет, осталось только узнать как
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Shabi, Вы писали: S>>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>>q1 выполняется долше всего... S>Открывай несколько параллельных коннектов. S>>...я ж говорю...HTTP ОТСТОЙ S>А какой протокол умеет автоматически переупорядочивать запросы?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ?
Например, HTTP вполне себе поддерживает оба PD>И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Угу. И получить странности поведения в релизе, которые не воспроизводятся в дебаге? Отличная идея.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Я не думаю, что у кого-то тут есть собственная реализация TCP/IP, но я, например, смотрел tcpdump'ы и запускал tshark я не далее чем вчера.
Кстати, у меня есть, на базе cipsuite
Так как у меня требование, чтобы TCP-сессии выживали между перезагрузками устройства.
Здравствуйте, Gaperton, Вы писали:
G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
Полностью согласен! После довольно продолжительных ковыряний в данном протоколе о нем остались самые лучшие воспоминания
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>[стошнило] C>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.
?! Смотри, как это делается. Несколько способов. http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
Здравствуйте, Gaperton, Вы писали:
C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>?! Смотри, как это делается. Несколько способов. G>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Да я знаю. Костыли можно поставить кое-где.
G>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>Здравствуйте, Gaperton, Вы писали:
G>>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>>[стошнило] C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. G>?! Смотри, как это делается. Несколько способов. G>http://www.cs.columbia.edu/techreports/cucs-011-04.pdf
Ага, ага. Ключевая фраза:
To avoid storing SIP transaction states in the subnet router, this method is only recommended for stateless
SIP proxies that use only UDP transport and treat each request as independent without maintaining any
transaction state.
Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
G>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Два разных кода для дебага и релиза? PD>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
Это не разный код (надеюсь), а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
>>Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком;)) PD>Ну насчет всерьез — уже поздно. Раньше думать надо было.
Этого не понял.
N>>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER;)) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.:) PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Потому, что твоя аналогия с debug/release сборками некорректна.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
KP>Полностью согласен! После довольно продолжительных ковыряний в данном протоколе о нем остались самые лучшие воспоминания :up:
Значит, ты не столкнулся с тем, что нет вообще ни одной реализации без багов и тараканов подхода. Ух завидую.
Здравствуйте, Centaur, Вы писали:
C>Так писать неправильно. Символ '&', являющийся частью URI, при использовании в HTML должен кодироваться в &.
Именно об этом и речь.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А не преувеличиваешь ли все эти проблемы ? Почему все же для EXE это никого не смущает, более того, только так и бывает — никто не отлаживает сразу Release, и никто не распространяет Debug ?
Не преувеличивает. И есть люди, которые отлаживают Release (а что ты имел в виду под "проблемы известны, но решаемы"?), и есть даже те, кто поставляет дебаг.
Но это, впрочем, не очень важно.
Я бы хотел услышать хоть один аргумент в пользу такого подхода. То, что ты можешь объявить любые проблемы несущественными, я понял уже давно.
Ок, зачем нам эти несущественные проблемы? Что мы выиграем? Трафик? Бугога. Как известно, лучшие оптимизации — алгоритмические.
В данном случае это означает, что гораздо больше трафика можно выиграть, научившись вообще не передавать никакие данные в уместных случаях.
А также за счет прозрачного сжатия контента. Прозрачность хороша тем, что прикладному программисту не нужно заниматься сжатием вручную, осваивая тонкости протокола.
А также за счет умения передавать данные по частям.
А также за счет умения передавать не сами данные, а только разницу между предыдущим закэшированным состоянием и новым.
Бинарность/небинарность с точки зрения оптимизации отходят на второй план. За исключением тех случаев, когда вышеописанные возможности исчерпаны, а результаты не устраивают.
А это и есть та самая крайняя необходимость, о которой говорит Игорь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Pavel Dvorkin, Вы писали:
N>>>Два разных кода для дебага и релиза? PD>>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
N>Это не разный код (надеюсь),
Нет, не надейся. Разный бинарный код. Да, впрочем, и source иногда тоже
#ifdef DEBUG
...
а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
Можно. Но не стоит. Проблем с библиотеками не оберешься — они для Debug и Release разные, а две одновременно подключить сложно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, Pavel Dvorkin, Вы писали:
N>>>>Два разных кода для дебага и релиза? PD>>>Между прочим, это обычная ситуация для EXE файлов. И проблемы с тем, что Debug работает, а Release нет — известны, но вполне решаются.
N>>Это не разный код (надеюсь),
PD>Нет, не надейся. Разный бинарный код. Да, впрочем, и source иногда тоже
PD>#ifdef DEBUG PD>...
Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
N>>а разные режимы компиляции, между которыми можно и переходный сделать (дебаг только части файлов).
PD>Можно. Но не стоит. Проблем с библиотеками не оберешься — они для Debug и Release разные, а две одновременно подключить сложно.
Ну это только у вас с вижуал студией такие сложности.;)) В более... мнэээ... нормальных местах делается иначе.
PD>>#ifdef DEBUG PD>>...
N>Пока это различие не меняет основную логику — код одинаковый. А делать, чтобы оно меняло основную логику — это ССЗБ.
А что, замена одного формата данных на другой (при том. что между ними имееется взаимно-однозначное соответствие, о других вариантах и речи нет) так-таки и меняет логику ?
N>Ну это только у вас с вижуал студией такие сложности.) В более... мнэээ... нормальных местах делается иначе.
Здравствуйте, Игoрь, Вы писали:
И>Что касается двух версий протокола debug/release, это несерьезно.
Не debug/release (я это просто в качестве примера привел), а просто двух версий. Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму, остальные суть содержимое запроса. Кстати, конвертировать из бинарного в текстовый мог бы сам сервер (IIS) перед передачей приложению, так что ты бы ничего и не заметил.
Впрочем, ладно, не стоит продолжать. Я просто хотел сказать, что выбор или-или не единственный, вот и все.
> И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать > текстовый формат, и только в случае крайней необходимости — бинарный. > > PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один > из них, реализовать оба ? И написать конвертор из одного в другой ? При > отладке используем текстовый, в релизе — бинарный ? > > Два разных кода для дебага и релиза? Я надеюсь, среди нормальных людей нет > таких, кто всерьёз (а не потрепаться) думает о таком) > > P.S. На самом деле, один частный случай подобного рода можно придумать. Но > с границей не между отладочной и релизной версией, а скорее между режимами > работы для каждой из них — если есть проверенная библиотека ASN.1 > представлений, можно переключаться между BER (или вообще PER) для > обычной работы и XER для случая, когда надо в чём-то разобраться. Но я > думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ > и, возможно, с её автором. >
На самом деле ничего страшного в подобном подходе нет, я при разработке
самопальной rpc примерно так и делал. Переключалось правда не
дебагом/релизом, а опцией в конфиге сервера.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
C>Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
Ты не понял. Я сам офигел от постановки вопроса.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, netch80, Вы писали:
N>P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER) для обычной работы и XER для случая, когда надо в чём-то разобраться.
В WCF тоже похожая фишка есть — XML там все равно, но можно передавать его в бинарном виде.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vb-develop, Вы писали: VD>>Ну да, сервер удаленный, время отклика порядка 40-50 мс. Хотя я еще не до конца понимаю как на ws клиенте такое реализовать. Все-таки подразумевается синхронный запрос к серверу. А это больше на асинхронные похоже. S>Если речь про SOAP webservices, то это хрень — беги от них подальше Надо делать нормальные веб-сервисы, построенные по правилам HTTP, а не вопреки им.
Какие, например? (так для общего развития)
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Shabi, Вы писали:
И>>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>>....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал C>А функции типа htons/htonl видел?l
нет. эти?
Как известно, порядок байт в целых числах, представление которых занимает более одного байта, может быть для различных компьютеров неодинаковым. Есть вычислительные системы, в которых старший байт числа имеет меньший адрес, чем младший байт (big-endian byte order), а есть вычислительные системы, в которых старший байт числа имеет больший адрес, чем младший байт (little-endian byte order). При передаче целой числовой информации от машины, имеющей один порядок байт, к машине с другим порядком байт мы можем неправильно истолковать принятую информацию. Для того чтобы этого не произошло, было введено понятие сетевого порядка байт, т.е. порядка байт, в котором должна представляться целая числовая информация в процессе передачи ее по сети (на самом деле – это big-endian byte order). Целые числовые данные из представления, принятого на компьютере-отправителе, переводятся пользовательским процессом в сетевой порядок байт, в таком виде путешествуют по сети и переводятся в нужный порядок байт на машине-получателе процессом, которому они предназначены. Для перевода целых чисел из машинного представления в сетевое и обратно используется четыре функции: htons(), htonl(), ntohs(), ntohl().
не поленись перечитай то о чё писал я ....
(на всякий случай разжевываю. САМ протокол TCP/IP о проблеммах little/big endian НИЧЕГО незнает. ибо конкретно на этом уровне принято одно решение для всех. а вот на уровне приложения.... )
И>>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>>когда ты последний раз отлаживал TCP/IP? C>Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня.
тоже иногда занимаюсь отлаживанием протоколов (чаще бинарных)....да мои отладчики несколько сложнее, чем примитивный notepad. но как то грусти совершенно никакой нет.
S>Я не очень понимаю, что называется "полноценным дуплексом",
помимо того что для того чтобы послать очередной запрос на сервер ничего ждать ненужно...но и
это когда...информация клиену передается сразу, как только на сервере становиться доступной для передачи.
и не факт, что ответ на какой либо запрос будет передан сразу целиком.
часто быстрее ответы передать кусками (пакетами) от разных запросов и собрать их на клиенте.
Здравствуйте, Shabi, Вы писали: S>помимо того что для того чтобы послать очередной запрос на сервер ничего ждать ненужно...но и S>это когда...информация клиену передается сразу, как только на сервере становиться доступной для передачи.
Гм. Во всех известных мне протоколах информация клиенту передается сразу, как только становится доступной для передачи. Если не включать явную буферизацию. S>и не факт, что ответ на какой либо запрос будет передан сразу целиком.
Ага, не факт. Читать про стек протоколов, про IP-пакеты и Ethernet-датаграммы. S>часто быстрее ответы передать кусками (пакетами) от разных запросов и собрать их на клиенте.
Ага. Вот только к слову "дуплекс" это никакого отношения не имеет. "Алиса, никогда не употребляй слова только за то, что они длинные и красивые" (с).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
N>А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?
Благородный дон действительно считает эту разницу маловажной по сравнению с задачей написания собственно приложения. Поскольку ввод/вывод в десктопном приложении обычно представляет собой 1% от задачи или около того.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Запрос может, грубо говоря, передаваться в двух формах, первый байт определяет форму
AVK>Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п.
Господи! Уж банальный дескриптор превратился в проблему!
>Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.
Я вроде в этом разделе ни о каких реальных требованиях не говорил.
Здравствуйте, Shabi, Вы писали:
S>парсрование бинарного протокола намного проще, а смое главное эффективнее (память, CPU...). что в контексте сервера особливо важно. S>(неужели даже с этим найдуца несогласные....)
1. Ты не мог бы постараться писать на русском языке?
2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста. Даже с учетом RFC 2047.
3. Еще раз поясняю для тех кто в танке: нас мало интересуют накладные расходы на сериализацию/десериализацию. В большинстве случаев они пренебрежимо малы по сравнению с расходами на пересылку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
N>>А что, благородный дон не видит разницы между, например, fprintf(out, "%d", val) и fput_be32(out, val)?
PD>Благородный дон действительно считает эту разницу маловажной по сравнению с задачей написания собственно приложения. Поскольку ввод/вывод в десктопном приложении обычно представляет собой 1% от задачи или около того.
Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Вообще, потрясающе: рассуждая о глобальной архитектуре ты пишешь о том, какой байт чего содержит, о RVA и т.п.
PD>Господи! Уж банальный дескриптор превратился в проблему!
Не, дескриптор не проблема, проблема в том, что ты за деревьями не видишь леса. Это как, рассуждая о тенденциях в проектировании автомобилей, обсуждать хим. процесс получения пластика для плафона освещения багажника.
>>Зато как речь заходит от реальных требованиях, сразу всплывают сферические сервера в вакууме.
PD>Я вроде в этом разделе ни о каких реальных требованиях не говорил.
Здравствуйте, Shabi, Вы писали:
И>>>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>>>....попробуй объяснить загадку природы TCP/IP. :xz: как бы бинарный и о таких проблеммах не слышал C>>А функции типа htons/htonl видел?l S>не поленись перечитай то о чё писал я .... S>(на всякий случай разжевываю. САМ протокол TCP/IP о проблеммах little/big endian НИЧЕГО незнает. ибо конкретно на этом уровне принято одно решение для всех. а вот на уровне приложения.... )
Вы можете "разжёвывать" сейчас сколько угодно, но Ваше предыдущее утверждение, что бинарный TCP/IP избавляет от различий платформ, мягко говоря, некорректно. Охотно верю, что сейчас Вы бы выразились иначе. Но как бы это ни было выражено, это будет методически неправильно: протокол (формат) ни от чего не избавляет. Он может от них уходить или разрешением нескольких вариантов с возможностью однозначно детекта (как делают с юникодными UTF*), или разрешением только одного варианта (как большинство сетевых).
И>>>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>>>когда ты последний раз отлаживал TCP/IP? C>>Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня. S>тоже иногда занимаюсь отлаживанием протоколов (чаще бинарных)....да мои отладчики несколько сложнее, чем примитивный notepad. но как то грусти совершенно никакой нет.
Ну вот расскажите, сколько наворотов нужно сделать в "отладчике" чтобы разобрать протокол.
Здравствуйте, Sinclair, Вы писали:
S>2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста.
ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, eao197, Вы писали:
E>>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.
WF>А как там с расширяемостью?
Замечательно. В самой ASN.1 нотации присутствует способ определить специальные точки, в которых структура данных может быть расширена в будущем. Например:
Здравствуйте, eao197, Вы писали:
E>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще.
Ты не поверишь, программисту, использующему XML, обычно тоже не приходится этим заниматься вообще. Потому, что используются специальные компиляторы, которые генерируют код сериализации/десериализации по описанию структур.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>ASN.1 вообще-то подразумевает использование специальных ASN-компиляторов, которые берут ASN-описание структур данных и генерируют код сериализации/десериализации. Поэтому программисту, использующему ASN.1 не приходится этим заниматься вообще. S>Ты не поверишь, программисту, использующему XML, обычно тоже не приходится этим заниматься вообще. Потому, что используются специальные компиляторы, которые генерируют код сериализации/десериализации по описанию структур.
Поверю. Но ведь ASN.1 противопоставлялся не XML, а HTTP:
Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста. Даже с учетом RFC 2047.
Есть ли такие компиляторы для HTTP?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Есть ли такие компиляторы для HTTP? S>Эмн... S>Ну, обычно базовый разбор заголовков входит в обязанности HTTP-клиента.
Тогда, как мне кажется, твое противопоставление сложности парсинга не актуально, посколько обычному программисту не приходится ручками работать с ASN.1 и с HTTP-заголовками.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали: C>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, дескриптор не проблема, проблема в том, что ты за деревьями не видишь леса. Это как, рассуждая о тенденциях в проектировании автомобилей, обсуждать хим. процесс получения пластика для плафона освещения багажника.
Что-то не врубаюсь. Я всего лишь сказал, что возможны два формата — текстовый и бинарный. Десктопных программ, которые в нескольких форматах сохраняют, хоть пруд пруди (у того же Word их сколько ?), это вообще банальность. При чем тут деревья и лес — как-то непонятно.
Ты лучше это замечание Синклеру переадресуй, я писал там про иерархические запросы, а он меня упорно пытал — а как же там кеширование будет
Здравствуйте, PaulMinelly, Вы писали:
PM>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
А как Вы это себе представляете? Частичная закачка — это семантика файлов, а HTTP совсем не файловый (в основе) протокол.
Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, PaulMinelly, Вы писали:
PM>>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
N>А как Вы это себе представляете? Частичная закачка — это семантика файлов, N>а HTTP совсем не файловый (в основе) протокол.
А как Вы это узнали? В rfc так и написано вверху "передаем только гипертекст. Ни в коем случае не передаем файлы. Поэтому будьте осторожны."
N>Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере.
Не знаю, не знаю, по-моему это один из хреновых недочетов HTTP который исправить в его рамках нельзя.
Серверу сигнал можно не давать, а достаточно сказать объем закачиваемых данных — пусть он сам решает все пришло или нет.
Здравствуйте, PaulMinelly, Вы писали: PM>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
Непонятно, что именно имеется в виду. В HTTP вообще нет понятия "upload". Есть PUT, есть POST.
В самом протоколе требования поддерживать Ranges в PUT/POST нету.
На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
Даже для того, чтобы принимать файлы целиком, нужно этого "каждого сервера" расширять.
Характерный пример такого расширения — SVN. SVN клиент умеет передавать на SVN сервер только изменения, а не сами файлы. И всё это по протоколу HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом. ANS>Стандартный кто?
Стандартный java.io.URLConnection
Здравствуйте, netch80, Вы писали:
N>Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
И вот это: The Stream Control Transmission Protocol (SCTP)
as a Transport for the Session Initiation Protocol (SIP) http://www.ietf.org/rfc/rfc4168.txt
Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the
addresses, but if it becomes unreachable, data sent to one can
migrate to a different address. This improves fault tolerance;
network failures making one interface of the server unavailable do
not prevent the service from continuing to operate. SIP servers
are likely to have substantial fault tolerance requirements. It
is worth noting that, because SIP is message oriented and not
stream oriented, the existing SRV (Service Selection) procedures
defined in [5] can accomplish the same goal, even when SIP is run
over TCP. In fact, SRV records allow the 'connection' to fail
over to a separate host. Since SIP proxies can run statelessly,
failover can be accomplished without data synchronization between
the primary and its backups. Thus, the multihoming capabilities
of SCTP provide marginal benefits.
G>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет?
N>На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP.
Для HTTP при наличии серверной логики сессия живет гораздо длиннее, чем сессия SIP в случае телефонии.
А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.
Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.
Здравствуйте, Gaperton, Вы писали:
C>>Да я знаю. Костыли можно поставить кое-где. G>Вообще-то на это тему есть RFC, и никаких костылей не требуется. Стандартной для SIP техникой обеспечения отказоустойчивости и рапределенности является специальное правило трактовки записей DNS SRV и NAPRT, закрепленное в специальном SIP-овском RFC.
С их помощью нельзя сделать failover для транзакций и диалогов. Поэтому идут в топку.
G>>>Вопрос — я видимо чего-то не понимаю — почему HTTP совместим на load balancing и failover, а SIP, который имеет те же design principles — нет? C>>SIP — он STATEFUL. HTTP банально баллансируется простым раскидываением запрос между backend-серверами. G>SIP НЕ stateful.
Нет. Он ЯВНО stateful, так как в самом протоколе прописаны транзакции, захватывающие несколько запросов (см. со страницы 122 в rfc3261).
G>Там четыре уровня серверов — просто proxy, stateful proxy (хранит состояние транзакции — например INVITE — в этом смысле у тебя и HTTP stateful), call stateful proxy (хранит состяние звонка), и B2BUA (самая жесть). Первые два типа серверов формируют центральную часть сети, и они по сути stateless. На них уже можно сделать PBX. Остальные два — имеют мало отличий с Web Application Servers, стоят на переферии сети, и их можно откластеризовать на уровне сессий. В чем проблема? Не понимаю. Принципиальных отличий от веба не вижу. Покажешь?
Да. Покажи мне SIP-сервер, который умеет делать failover в середине транзакции. А я тебе покажу приложение, которое прозрачно делает failover для HTTP-запросов.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, netch80, Вы писали:
N>>Настоящего failover'а там нет (при котором разделяются и используются всеми данные транзакций и диалогов), а то что есть — общий трёп на тему "в DNS можно писать более одного адреса для имени". Шарят данные регистраций — ну это сейчас любой умеет.
G>RFC — это общий треп?
Нет, этот pdf — общий трёп.
G> На, почитай внимательно.
Я не столь пессимистичен здесь, как Cyberax;) — но ты где-то реально видел реализацию, которая бы способна была перенести диалог на хост с другим IP? (Да, я знаю, что можно в h_Route, h_Record-Route, h_Via писать имена, но опять же вопрос в конкретных реализациях.) А вариант, где нельзя сохранить диалог потому что нода упала — меня не интересует. А с транзакциями — ещё хуже — потому что их минимум в 2 раза больше, а при хоть каком-то signaling keepalive — не в 2 раза, а может быть и в десятки. А (повторюсь) отказ одной транзакции рушит весь диалог, потому что так по RFC3261 положено.
G>locating SIP servers. G>http://www.ietf.org/rfc/rfc3263.txt
Естественно, я его читал.:)) И даже внимательно.:))
G>И вот это: The Stream Control Transmission Protocol (SCTP) G> as a Transport for the Session Initiation Protocol (SIP) G>http://www.ietf.org/rfc/rfc4168.txt G>
G> Multihoming: An SCTP connection can be associated with multiple IP
G> addresses on the same host.
"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты.
G>
over to a separate host. Since SIP proxies can run statelessly,
G> failover can be accomplished without data synchronization between
G> the primary and its backups. Thus, the multihoming capabilities
G> of SCTP provide marginal benefits.
Во-во — marginal оно и есть marginal.
N>>На HTTP ты можешь между разными серверами расшарить, например, состояние корзины покупателя (которую он модифицирует каждым кликом в браузере)? Ну да, можешь, но цена абсолютно та же, что для SIP — общее состояние, его репликация... И для HTTP каждый отдельный запрос/ответ живёт короче, чем диалог в SIP. G>Для HTTP при наличии серверной логики сессия живет гораздо длиннее, чем сессия SIP в случае телефонии.
Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти.
G>А в простом случае — тебя для SIP хватит stateless серверов, которыми являются proxy и stateful proxy. Состояние длительное время хранится ТОЛЬКО в случае B2BUA и call stateful proxy — но это никак не отличается от случая Web App Server.
Ещё раз: если транзакция началась и сорвалась — диалог гибнет весь, потому что одна из сторон получает 408 или его аналог (внутренний таймаут), а ответ второй стороны может не дойти и поэтому суммарное состояние становится некорректным (расхождение между мнениями про, например, SDP). Поэтому писать, как ты пишешь,
stateless серверов, которыми являются proxy и stateful proxy
— некорректно. Даже если в момент гибели ноды транзакцию проходили 0.1% диалогов — эти 0.1% диалогов погибнут. Именно в этом проблема такой системы для прокси.
Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно.
G>Что до разделения состояния корзины между серверами, так HTTP тут не при чем. Он никак не регламентирует такие фокусы прикладной логики — хочешь делай, хочешь нет. Я точно так же могу зашарить и состояние call stateful proxy, и применить виртуальные IP адреса, как делается и в случае веб иногда. И все, никаких проблем.
Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, netch80, Вы писали:
N>>Проблема не в затратах, а в том, что это таки разный код. И глюк в релизном коде ты не сможешь поймать отладочной версией. Вот это тут таки принципиально. PD>Я все-таки не понимаю. Если запрос будет переводиться из текстового вида в двоичный на выходе из броузера, а потом IIS переведет его обратно в текстовый перед тем, как отдать тебе, какой-такой разный код будет в твоем приложении ? PD>А если и не будет такого преобразования — не надо из мух слонов делать. Word поддерживает два десятка форматов, и чтение/запись в них — это разный код. И ничего страшного. Запись и чтение файла — это 1% от того, что содержит в себе Word.
У ворда _один_ родной формат (у каждой версии свой). Все остальные — экспортно-импортные, неродные. Во-первых, их конвертеры хуже тестируются и вообще пишутся. Во-вторых, это всё-таки отдельное преобразование.
Если ты хочешь уподобить ситуацию тому, как работает ворд — у тебя будет внутренние протокол и формат (по твоему вкусу — двоичные) и внешние текстовые для тех, кто этого хочет (как в случае HTTP). Значит, ты будешь отлаживать и одно, и другое. Да, в этом случае у тебя не будет проблемы между релизом и дебагом. Но эта часть работы удвоится. Тебе мало работы?;)
Здравствуйте, PaulMinelly, Вы писали:
PM>Здравствуйте, netch80, Вы писали:
N>>Здравствуйте, PaulMinelly, Вы писали:
PM>>>Клево, а поддержза возобновления _закачки_ (upload) тоже в http есть? Или надо для этого расширять каждого клиента и сервера?
N>>А как Вы это себе представляете? Частичная закачка — это семантика файлов, N>>а HTTP совсем не файловый (в основе) протокол. PM>А как Вы это узнали? В rfc так и написано вверху "передаем только гипертекст. Ни в коем случае не передаем файлы. Поэтому будьте осторожны."
Что-то я не понял — Вы тут знак вопроса пропустили?
Узнал потому, что по всему тексту rfc мало случаев слова file и они специально оговорены условиями применения.
N>>Если сервер будет отрабатывать просто файлопомойку, то, думаю, он согласится с PUT + h_Range. Но если что-то более сложное — основная проблема будет в том, как дать серверу сигнал, что всё закачали и можно что-то делать с файлом. А это уже — уровень исполняемой логики на сервере. PM>Не знаю, не знаю, по-моему это один из хреновых недочетов HTTP который исправить в его рамках нельзя. PM>Серверу сигнал можно не давать, а достаточно сказать объем закачиваемых данных — пусть он сам решает все пришло или нет.
Исправляется-то этот "недочёт" тривиально — посмотрите на любой сайт, где есть формочка с upload file. Обычно там получается генерация POST, а логика сервера переделывает это в выкладывание файла, и код, нужный на это — ничтожен по сравнению с остальной логикой. Зацикливаться на PUT я тут смысла не вижу.
А ещё бесконтрольное (а в случае "автоматической" поддержки протоколом) выкладывание файлов и их частей чревато DoS'ом.
N>Исправляется-то этот "недочёт" тривиально — посмотрите на любой сайт, где есть формочка с upload file. Обычно там получается генерация POST, а логика сервера переделывает это в выкладывание файла, и код, нужный на это — ничтожен по сравнению с остальной логикой. Зацикливаться на PUT я тут смысла не вижу.
Дело то не совсем в том как оно сейчас работает. А в том что нет докачки (upload). Закачивал 100 меговый файл, связь оборвалась. Ни в одном браузере докачки нет. Даже сделай я эту фичу, например загрузка с 50 байта по 900 — ниодин сервер ее поддерживать не будет. Почему?
Здравствуйте, PaulMinelly, Вы писали:
S>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET. PM>А что за сервер такой в котором POST нет?
Рукописный под раздачу чегонибудь необычного.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
N>>Ну кроме производительности и разнообразных race conditions типа "узел 1 запомнил состояние, но не успел передать на узел 2, а на узел 2 пришла следующая транзакция в диалоге".
G>1) Производительность сильно не просядет. SIP-сигнализация — не такая уж быстрая и требовательная к пропускной способности штука. G>2) Не будет такого race condition. Не пошлет UA следующую транзакцию в диалоге, не дождавшись завершения предыдущей, а ведь ты не будешь завершать предыдущую транзакцию не отреплицировав состояние? Ну, если не вредитель конечно?
Ну, в таком варианте — да, логично. Сразу почему-то не подумал.
G>Вообще, странные вы, парни, проблемы находите. Эти проблемы ровным счетом ничем не отличаются от кластеров веба. Просто та же фигня, один в один.
Я с вебом так плотно не работал.
N>>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты. G>Мы применяем virtual IP. Нам хватает.
С именами может быть проще (протокол требует, чтобы транзакция шла с одним IP, а вот диалог может связываться с любым).
N>>Ну и какой уровень надёжности тебе реально нужен? Да, сессия может жить сутками и неделями (как та в rsdn где я сейчас не ввожу пароль), а звонок — например, в среднем 5 минут. Но для реальной наджёности тебе всё равно надо рассчитывать, что звонок живёт час. А за час ой сколько всяого может произойти. G>Для реальной надежности я могу дать клиенту отказ в продвинутом сервисе. Мне главное, чтобы а) это остальных клиентов не затронуло, и б) для этого клиента работал базовый сервис. Откинулся сервер — порвались его сессии, однако фэловер телефонов прошел — люди перезвонят, и все будет в порядке. Это вполне адекватная отказоустойчивость — сервер не каждый день ломается. А при программном сбое — последствия этого сбоя затронут только того UA, кто вызвал сбой.
Ну такой уровень и у нас сейчас есть. Но хочется большего.
G>К тому же, я не понимаю что плохого в том, что умрут диалоги в случае аппаратного сбоя. Это полная херня, пусть умирают. Перезвонят, не обломятся, не так часто аппаратные сбои происходят.
;)))
N>>Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно. G>Что ты пишешь такое, что тебе принципиальна семантика B2BUA, и что тебе мешает воспользоваться virtual IP и реплицировать состояние на кластере — как это делают в веб? Медия у тебя как идет? Тоже через сервер? Короче, опиши приложение.
Софтсвич с B2BUA посредине. "Медия" может и напрямую идти, и через сервер — в зависимости от настроек. Virtual IP мне не нравится. С именем будет удобнее.
Здравствуйте, PaulMinelly, Вы писали:
S>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
PM>А что за сервер такой в котором POST нет?
Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.
На всякий случай напомню, что штатный HTTP сервер комплектуется исключительно отдавалкой статических файлов по GET. Всё остальное — это расширения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, PaulMinelly, Вы писали:
PM>Дело то не совсем в том как оно сейчас работает. А в том что нет докачки (upload). Закачивал 100 меговый файл, связь оборвалась. Ни в одном браузере докачки нет. Даже сделай я эту фичу, например загрузка с 50 байта по 900 — ниодин сервер ее поддерживать не будет. Почему?
Потому что это мало кого интересовало.
Вообще закачка файлов в браузерах реализована из рук вон плохо — даже до уровня требований HTML 3.2 ни один известный мне браузер не дошел.
Поэтому тебя это всё волновать особенно не будет — если ты захочешь решить эту проблему, то есть стандартный путь:
1. Пишешь серверный скрипт, который умеет принимать частичную закачку.
2. Пишешь клиентский контрол на Flash или Silverlight, который умеет пользоваться твоим расширением
3. Пользователи счастливы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PaulMinelly, Вы писали:
S>>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
PM>>А что за сервер такой в котором POST нет? S>Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.
Здравствуйте, PaulMinelly, Вы писали:
PM>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, PaulMinelly, Вы писали:
S>>>>На всякий случай напомню, что в "каждом сервере" вообще нет никакой поддержки глаголов, кроме GET.
PM>>>А что за сервер такой в котором POST нет? S>>Переформулируем вопрос — в каком есть? Из известных мне ни один не в состоянии самостоятельно обработать POST без обращения к пользовательским расширениям.
PM>В Апаче POST принимается расширением?
А что, обрабатывается он тоже апачем? Или таки перенаправляется пользовательскому расширению?
PaulMinelly wrote:
> В Апаче POST принимается расширением?
Ещё можно добавить, что глагол может быть любым, можешь свой глагол придумать (webdav использует кучу разных глаголов, скажем COPY, MOVE, LOCK, MKCOL), веб-сервер же понимает только GET, остальное тупо спихивает пользовательским скриптам/модулям. Типичный веб-браузер умеет только GET и POST. Но это не ограничения протокола HTTP.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PaulMinelly, Вы писали: PM>>В Апаче POST принимается расширением? S>RTFM: http://www.apacheweek.com/features/put. S>
There is some confusion about whether Apache supports the PUT method. In fact, Apache handles PUT exactly like it handles the POST method. That is, it supports it, but in order for it to do anything useful you need to supply a suitable CGI program. This is on contrast to the GET method, which Apache supports internally by sending back files or SSI documents.
S>На всякий случай перевожу главную фразу: S>
То есть, он [Апач] поддерживает их [GET и POST], но чтобы он мог сделать что-нибудь полезное, ты должен предоставить подходящую CGI-программу
S>А вообще, приличные веб сервера в таких случаях отдают не 200 ok, а 405 Method not allowed (кстати, первый попавшийся мне под руку Апач так и делает для PUT)
Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором), так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор? Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна? Точно так же нужна, так о каких тонких материях спор?
Здравствуйте, PaulMinelly, Вы писали:
PM>Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором),
Совершенно верно. PM> так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор? PM>Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна?
Нет, не нужна. GET апач обработает безо всякой проги. Записывать GET в базу не нужно. Читайте RTFM. PM>Точно так же нужна, так о каких тонких материях спор?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, PaulMinelly, Вы писали:
PM>>Что-то ничего не понял. Т.е. вот допустим мы послали POST. Он пришел на сервер и далее чтобы что-то сделать с этим POSTом надо писать php скрипт который допустим будет сохранять POST в базу данных. Ну это и так понятно что Апач без php-скрипта (который кстати может И НЕ БЫТЬ CGI, не одним же CGI-ем жив обмен между серваком и интерпреатором), S>Совершенно верно. PM>> так вот понятно что Апач без php-скрипта не сохранит этот POST в базу. Так о чем разговор? PM>>Конечно прога нужна. А чтобы сохранить запрос GET в базу — что прога не нужна? S>Нет, не нужна. GET апач обработает безо всякой проги. Записывать GET в базу не нужно. Читайте RTFM.
А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно. Теперь вы хотите сказать что гугл не должен записывать в базу данные GET запроса, а всегда оформлять его как POST? Причем не потому что это удобно, а потому это написано не понятно почему в RTMF? Кстати где этот rtfm интересно посмотреть как это сформулировано — как пожелание скромного ученого или как прямо запрет на сохранение GET запроса в базу.
Здравствуйте, PaulMinelly, Вы писали: PM>А что это не нужно? Вот например поисковый запрос в гугле — это урл со всякими параметрами оформленный методом GET с главной страницы. Я беру этот урл и отдаю другу. Друг просто открывает страницу и видит результаты поиска. Удобно.
Ну, такой поддержки GET конечно же в Апаче нет. Тем не менее, для статического файлового контента семантика GET хорошо определена и встроена в сервер. PM>Теперь вы хотите сказать что гугл не должен записывать в базу данные GET запроса, а всегда оформлять его как POST?
Это два не связанных между собой утверждения. PM> Причем не потому что это удобно, а потому это написано не понятно почему в RTMF? Кстати где этот rtfm интересно посмотреть как это сформулировано — как пожелание скромного ученого или как прямо запрет на сохранение GET запроса в базу.
Читайте RFC 2616. Особенно раздел 9.1.1. Из него, в принципе, понятно, почему умение обрабатывать GET и HEAD встроено в современные HTTP сервера, а PUT, POST и DELETE — не очень.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>Из Яваскрипта уже можно и PUT и DELETE, если мне память не изменяет
А почему только PUT и DELETE? Разве XMLHTTP компонент накладывает ограничения на глаголы? Глянул мельком в MSDN — вроде как ограничений нет...
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>>Я лично писал штук пять парсеров для HTTP. Вот недавно как раз ещё один закончил — меня не удовлетворило как стандартный работал с keep-alive'ом. ANS>>Стандартный кто? C>Стандартный java.io.URLConnection
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vb-develop, Вы писали: VD>>Какие, например? (так для общего развития) S>Например искать по слову REST.
И как REST соотносится с веб-сервисами? ИМХО, это понятия из разной области совершенно. Большинство фич HTTP веб-сервисы не используют, ибо эти фичи к задаче транспортировки сообщений не применимы по принципиальным соображениям.
Здравствуйте, Sinclair, Вы писали:
S>2. Ну, вот мне почему-то разбор бинарного ASN.1 не кажется намного проще парсинга хидеров HTTP реквеста.
Проще гораздо, т.к. ты компилятору ASN.1 скармливаешь описание формата, на выходе получаешь готовый парсер. Это что-то вроде регекспов для текста, только гораздо мощнее (значительно больший класс грамматик захватывает).
G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
Угу, SIP хорош для установления связи. Хорош потому, что допускает практически произвольное расширение. Собственно, как и XMMP. Но у того и другого очень слабая связанность с самой связью, т.е. с целью их существования, т.к. по TCP стороны могли запросто связаться о начале медиа-сеанса, а сам медиа-сеанс через NAT может и не пойти, не взирая на все STUN-ы в округе.
--------------
А вообще, затронули практически корень проблемы. Если зрить в этот самый корень, то TCP плохо подходит под транспорт инфраструктуры обмена сообщениями (вот такое богохульство). Мы в конечном итоге выбрали IAX2, который использует только UDP. Ведь что мы имеем и что требуется в системах типа запроc-ответ:
— асинхронность, произвольный порядок обработки сообщений.
— целостность нужна только на уровне пакета.
— подтверждать пакеты вовсе не требуется в том же порядке, в каком они к нам приходят.
— еще много мелочей, характерных для протоколов, которым НЕ ТРЕБУЕТСЯ установление связи (сеанса)
В общем, потоковый транспортный протокол в системах типа запрос-ответ смотрится малость неуклюже, сливая многократно аналогичной системе, построенной на близком по характеру транспортном протоколе без установления связи. (Сразу оговорюсь, что к HTTP это не может относиться хотя бы из-за произвольного объема передаваемых в обе стороны данных)
Относительно SIP вообще смешно получилось. Session Initiation Protocol, типа производит установление сессии. Для тех кто не в курсе, скажу, что там в 99.99% случаев происходит обмен парой сообщений длиной по сотне байт каждое с целью установления RTP-сессии (RTP живёт поверх UDP, опять же). Где здравый смысл? Зачем устанавливать TCP-сессию перед тем как начать процесс установки UDP-based сессии?
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>И как 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. (Всё остальное мне в нём решительно не нравится, но упомянутая фича своим приоритетом давит многие возражения)
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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 и еще тонна популярных стандартов.
Здравствуйте, 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, Вы писали:
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 лицензией.
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>Чем лучше удается определить эту гранулярность и обеспечить стабильность состояний, тем эффективнее работает кэширование.
Насчёт кеширования как раз и так понятно, непонятно про "обеспечение стабильности состояний". ИМХО, не очень большой класс задач радует нас некритичными к актуальности состояния требованиями.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>VoIP живёт в ней. ;) S>Ну, те кто внимательно читает посты, могли увидеть здесь
Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
Дело не только в стриминге (хотя в принципе сказав CONNECT проблем уже нет — я так ssh через прокси пускал много раз). Дело в том, что голосовая сигнализация по умолчанию двусторонняя: каждая сторона может дать запрос и получить ответ. А вот тут и начинаются хохмы с портами.
Кстати, для HTTP это тоже было бы полезно. Сейчас клиентские приложения вынуждены поллить сервер за новыми данными. А можно было бы сделать двустороннюю связь.
N>Ослабляет нагрузку чего? Просто на канал? Не вопрос. И с джиттером это мало связано — если пакет пропущен, но следующий приходит с адекватным timestamp, проблем нет — просто пропуск части данных.
На слух это ужасно, ведь пакеты не просто пропускаются, а иногда приходят не в том порядке.
N>А теперь рассказываю, что будет, если связь просто пропадёт (например, при перестройке глобального раутинга какое-то время пакеты шли в интерфейс Null0): первый раз TCP сделает перепосылку через последний известный RTT, а второй — уже через три секунды (во всех известных мне реализациях). "А вот вам меч!" И страдайте теперь при мечтаниях про 150 миллисекунд.
Ну дык пауза в 3 сек и делов-то. И бывает это раз в пятилетку.
Здравствуйте, vdimas, Вы писали:
N>>Ага, ага. Только вот в чём фигня — это он разве что для Python/Perl/Ruby/etc. будет так хорошо выглядеть, потому что там один тип "строки", один штатный "целого числа произвольного размера", "списка данных произвольного содержания" (для sequence of, в котором могут быть числа, строки и так далее, и совершенно не обязательно её состав и размер заранее определён)... N>>А в случае C или C++ его ещё надо связывать с той библиотекой, которая именно в данном проекте выбрана для таких представлений, и структурой классов (чтобы какой-нибудь TStreamedBigInteger происходил от общего TStreamedObject). И вот тут-то весь код парсера ASN.1 пойдёт нафиг, как только правила для данного проекта поменяются. V>Во-первых, не проекта, а протокола.
Нет, проекта. Вчера использовали CString из MFC, сегодня наконец смогли перейти на std::string, а на завтра рассматриваются строки из boost.
V>Во-вторых, только лишь в кусках кода, оперирующих изменёнными типами полей, т.е. тех частей, где ты используешь эти данные в прикладном коде (например, маппинга на int теперь недостаточно, и везде должен использовать long для интересующего поля). Ну а в-третьих, тоже самое тебя ожидает в случае аналогичного изменения типа даже при использовании XML-протоколов.
Да, ожидает. Но там я сам пишу код и определяю, с чем он работает. А тут у тебя получается навязывание свойств.
V>Но в любом случае замечание подобного рода применимо к системам на основе C# и Java, например для C++ прикладные типы данных всё-равно определяют через typedef, агрегатные структуры — как шаблонные т.е. изменений в коде клиента — ровно 0.
И адаптеры интерфейсов через всю систему.
N>>XML'ный парсер для SAX стиля, при том что соответствующий код надо писать руками — это сделает именно так, как нужно для данного проекта, с использованием именно тех средств, которые нужны именно в нём.
V>Открою маленький секрет. Если для C#/Java небходимо полностью подключать базовые (иногда монстрообразные) сборки некоего ASN.1-парсера от некоего производителя, то для C/C++ в случае статической линковки из библиотек возмется лишь самое необходимое, т.е. только те куски, которые реально вызываются в целевом коде
У парсера вообще-то неизвестно что заранее вызовется именно на десериализации. Так что это не работает — реализовывать надо весь протокол целиком.
V> (именно с этой целью выход ASN.1-парсера так же лучше оформлять в виде библиотечного модуля, а не вставлять в целевой, т.к. в реальном применении редко протокол используется целиком, приличная часть протокола для одной из сторон используется только как read-only, это очевидно).
Правильно — пишущий использует своё подмножество. А вот читающий — должен понимать всё.
> Я именно это имел вввиду, когда отвечал рядом, что футпринт для железячек в случае небольших протоколов получается очень маленьким.
N>Если Вы не заметили — в общем заголовке RTP по смещению 2 находится поле sequence number, а по смещению 4 — находится поле timestamp. Вот их достаточно, чтобы при приходе пакетов не в том порядке — упорядочить их как следует.
Дошло до смешного. Ну дык, а как называется объект, который упорядочивает, и который даёт некую фору по времени, необходимую для этого упорядочивания?
N>Главное, чтобы приёмная сторона не пыталась безумно увеличивать jitter buffer и соответствующую задержку только от того, что у передающей включился VAD.
Мдее... "И эти люди запрещают мне ковыряться в носу".
Есть в природе (и в протоколах) такая штука как comfort noise, неразрывно связанная с VAD вещь.
V>>Ну дык пауза в 3 сек и делов-то. И бывает это раз в пятилетку.
N>Увы, значительно чаще. Ваши условия слишком тепличны.
Здравствуйте, netch80, Вы писали:
N>>>Ну и мне всё-таки принципиальна специфика B2BUA. А там — ты тоже подтверждаешь, что состояние хранится длительное время и с ним надо обращаться адекватно. G>>Что ты пишешь такое, что тебе принципиальна семантика B2BUA, и что тебе мешает воспользоваться virtual IP и реплицировать состояние на кластере — как это делают в веб? Медия у тебя как идет? Тоже через сервер? Короче, опиши приложение.
N>Софтсвич с B2BUA посредине. "Медия" может и напрямую идти, и через сервер — в зависимости от настроек. Virtual IP мне не нравится. С именем будет удобнее.
К сожалению, дальше не могу комментировать, так как нарушу корпоративную тайну и NDA . Одно могу сказать — мы подошли вплотную к решению этой задачи, и у нас все вроде пока срастается.
Здравствуйте, netch80, Вы писали:
N>>>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты. G>>Мы применяем virtual IP. Нам хватает.
N>С именами может быть проще (протокол требует, чтобы транзакция шла с одним IP, а вот диалог может связываться с любым).
С именами. Посмотри, какие таймауты у нас в SIP. И какие правила трактовки DNS SRV. Получается, что в случае аппаратного сбоя у тебя часть телефонов будет тупить до 30 секунд, прежде чем поймут, что сервер умер. Вот что будет, если пользоваться только символикой. Это ИМХО недопустимо. В случае программного — телефоны быстро переключатся, это да.
Может быть я неправ — тогда прошу разъяснить, это очень интересный вопрос.
Я уж не говорю, на какие извраты тебе придется идти, чтобы перехватить сессию в случае фэйловера работая с символическими именами — ты ведь этого хочешь добится?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, netch80, Вы писали:
N>>>>"on the same host" — это что, для варианта, когда берутся 2-3 разных блока адресов, серверу даётся адрес из каждого из них и предполагается, что при обрыве раутинга на один из них другой поможет? Ну так для этого вообще-то традиционные раутинговые протоколы есть (типа OSPF или BGP). Реальный failover надо искать в тех случаях, когда это _разные_ хосты. G>>>Мы применяем virtual IP. Нам хватает. N>>С именами может быть проще (протокол требует, чтобы транзакция шла с одним IP, а вот диалог может связываться с любым). G>С именами. Посмотри, какие таймауты у нас в SIP. И какие правила трактовки DNS SRV. Получается, что в случае аппаратного сбоя у тебя часть телефонов будет тупить до 30 секунд, прежде чем поймут, что сервер умер. Вот что будет, если пользоваться только символикой. Это ИМХО недопустимо.
Короткий TTL и обновление DNS — и проблемы нет. Например, TTL=300 вполне адекватен (это примерно время загрузки одного брэндового сервера;))
G>В случае программного — телефоны быстро переключатся, это да. G>Может быть я неправ — тогда прошу разъяснить, это очень интересный вопрос. G>Я уж не говорю, на какие извраты тебе придется идти, чтобы перехватить сессию в случае фэйловера работая с символическими именами — ты ведь этого хочешь добится?
Я что-то не вижу никаких извратов. Если sip.pupkin.com резолвится в два IP, на каждом из которых есть знание сессии — неважно, на какой из них придёт следующий запрос в диалоге. Внутри себя они будут, конечно, знать IP и прочие детали реализации.
Здравствуйте, vdimas, Вы писали:
C>>А для XML — бесплатно. И с открытыми исходниками. V>Бесплатно что именно?
Всё.
V>Помимо самого парсера XML тебе нужен некий маппер на твои прикладные структуры + валидатор, вон для дотнета XML-сериализация бесплатна, но уж очень и очень ограничена, ввиду чего я постоянно вижу рукописный маппинг (да и сам неоднократно грешен).
Для Java: JAXB, jibx, xmlbeans, ... Для .NET не знаю. Для C++: xmlbeansxx, csoap, ...
И самое смешное, что это очень часто просто-напросто не нужно.
V>PER — это высший пилотаж, используется там, где никакими текстовыми стандартами (и даже многими самопальными бинарными) и близко пахнуть не должно. Ибо имеем оптимизированный поток бит, а не байт, и для оптимизации компилятору нужна практически вся информация о кодируемом протоколе. Конечно, на коленке за неделю фиг сделаешь, так что отсылаю туда же — в готовый опенсорс.
Самое смешное, что сжатый gzip'ом поток обычно даёт примерно такой же rate, как и PER.
C>>Это ерунда, нишевые применения. Ты же понимаешь, что список только применения того же XML растянется на мегабайты. Про HTTP я вообще молчу. V>Ну да, управление полётами и управляемой посадкой, автомобилестроение, безопасность, сервисы сотовой связи и т.д. и т.п. — это весьма нишевые применения.
Да. Это нишевые применения, во многом сложившиеся просто исторически (как SSL).
V>Однако, всё гораздо проще уже сегодня, есть мапперы со схем XML в ASN.1, так что в любом проекте можешь использовать свой любимый XML, но будь потребность многократного сжатия траффика, ты легко сможешь прыгнуть на бинарный протокол. В какой-то мере на сегодняшний день это всё практически прозрачно и не тема для холи варз.
А нафиг? Gzip решает проблемы с избыточностью.
Я помню как Sun года три назад начала шевелиться по поводу бинарного XML для ускорения веб-сервисов и экономии траффика. Только оказалось, что никакой особой экономии просто-напросто нет.
V>Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента.
Да, это непросто. Но смысл в том, что это можно было делать ПОСТЕПЕННО. То есть, сначала написать SAX-парсер, потом добавить DOM. А потом на досуге валидатор по схеме. На каждом этапе у нас была полностью рабочая система.
V>Немного не так, масштабируемость не подкосили. Сейчас IOR можно сравнить на клиенте, но все реализации при неудачном сравнении запрашивают сервак, т.е. они просто внесли некую оптимизацию в процесс сравнения. А вообще странный у тебя аргумент, зачём вообще сравнивать IOR-ы, не объяснишь? ИМХО, сценарий предположительного их использования не предусматривает сравнения в клиентском коде (может я чего-то упустид? ).
IORы должны быть полностью непрозрачной ссылкой для полностью идеологического соответствия. Сравнивать их нужно редко, это я просто как пример привёл.
C>>А ещё в CORBA совсем никак с работой в реальных условиях — в гетерогенных сетях с высокой латентностью и кучей файрволов. Дальше локалки CORBA живёт с большим трудом. V>Это проблема относится не конкретно к CORBA, а вообще к распределённым приложениям. Обратные асинхронные вызовы — зло, это относится к любой современной распределённой среде. Если же ты используешь сервис-ориентированный подход, то CORBA живёт там, например, где живёт собственно TCP (mapping GIOP onto TCP), т.е. далеко за пределами локалки.
Ага. Мне вот как-то потребовалось затуннелить CORBA через HTTP-прокси (с запрещённым CONNECTом) — получился полный упс. А веб-сервисы в таких условиях спокойно работают.
C>>Нет, Java/.NET — это просто языки с хорошими библиотеками. И самое главное — их не надо самому реализовывать. V>CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более.
Для Java в последних версиях JRE собираются выбросить CORBA. Так как никому не нужна, а места занимает 2 мегабайта.
C>>GSM — это уже к телекомщикам. 802.xx — к железячникам. V>И что? И там и там большинство штата — программисты, не хуже чем в "обычной" софтовой конторе.
В общей индустрии IT — это всё отдельные ниши.
Здравствуйте, netch80, Вы писали:
N>>>С именами может быть проще (протокол требует, чтобы транзакция шла с одним IP, а вот диалог может связываться с любым). G>>С именами. Посмотри, какие таймауты у нас в SIP. И какие правила трактовки DNS SRV. Получается, что в случае аппаратного сбоя у тебя часть телефонов будет тупить до 30 секунд, прежде чем поймут, что сервер умер. Вот что будет, если пользоваться только символикой. Это ИМХО недопустимо.
N>Короткий TTL и обновление DNS — и проблемы нет. Например, TTL=300 вполне адекватен (это примерно время загрузки одного брэндового сервера)
Допустим. Только, насколько я понимаю, у тебя в самом SIP 30-секундный таймаут заложен, и TTL тебе не поможет. То есть, конечно, заявки на мертвый сервер он разбрасывать прекратит довольно быстро, и трубы прочистит тоже, но те телефоны, которые успели получить от него мертвый IP, 30 сек потупят, прежде чем опять к DVN полезть. Правильно? Или не правильно?
К тому же, нагрузка на DNS возрастет, и количество сетевых раунтрипов вырастет — не знаю, правда, насколько это будет критично на самом деле.
G>>В случае программного — телефоны быстро переключатся, это да. G>>Может быть я неправ — тогда прошу разъяснить, это очень интересный вопрос. G>>Я уж не говорю, на какие извраты тебе придется идти, чтобы перехватить сессию в случае фэйловера работая с символическими именами — ты ведь этого хочешь добится?
N>Я что-то не вижу никаких извратов. Если sip.pupkin.com резолвится в два IP, на каждом из которых есть знание сессии — неважно, на какой из них придёт следующий запрос в диалоге. Внутри себя они будут, конечно, знать IP и прочие детали реализации.
Хм. Я в основном об RTP-сессии вообще-то говорил, которая у тебя как ты говоришь проксируется на сервере. Как с этим обходится?
Но пусть речь о сигнализации — ты уверен, что все клиенты каждый раз перезапрашивают IP в середине диалога?
V>>PER — это высший пилотаж, используется там, где никакими текстовыми стандартами (и даже многими самопальными бинарными) и близко пахнуть не должно. Ибо имеем оптимизированный поток бит, а не байт, и для оптимизации компилятору нужна практически вся информация о кодируемом протоколе. Конечно, на коленке за неделю фиг сделаешь, так что отсылаю туда же — в готовый опенсорс. C>Самое смешное, что сжатый gzip'ом поток обычно даёт примерно такой же rate, как и PER.
Это надо в каждом конкретном случае смотреть, не всегда основная масса данных — текстовая. И опять же, наложить твой gzip можно и поверх бинарного протокола, результат в каждом конкретном случае будет зависеть от характера самих данных. PER хорош тем, что добавляет к полезным данным минимально-возможный на сегодняшний день описательный оверхед (в случае жёстко описанных структур данных практически не добавляет). Ну и напомню, что кодировка-раскодировка gzip требует некоторых вычислительных ресурсов, в то время как кодировка/раскодировка PER их практически не требует. Требования к вычислительным ресурсам парсера бинарного протокола гораздо меньше даже чем к парсеру XML, особенно при передаче данных числового характера.
V>>Ну да, управление полётами и управляемой посадкой, автомобилестроение, безопасность, сервисы сотовой связи и т.д. и т.п. — это весьма нишевые применения. C>Да. Это нишевые применения, во многом сложившиеся просто исторически (как SSL).
Дальше будет больше исторического складывания, ибо нет никакого смысла для большинства перечисленного по ссылке использовать текстовое представление бинарных по своей сути данных.
V>>Однако, всё гораздо проще уже сегодня, есть мапперы со схем XML в ASN.1, так что в любом проекте можешь использовать свой любимый XML, но будь потребность многократного сжатия траффика, ты легко сможешь прыгнуть на бинарный протокол. В какой-то мере на сегодняшний день это всё практически прозрачно и не тема для холи варз. C>А нафиг? Gzip решает проблемы с избыточностью.
В сигнальных протоколах никак не решает (повторю, что всё зависит от характера данных).
C>Я помню как Sun года три назад начала шевелиться по поводу бинарного XML для ускорения веб-сервисов и экономии траффика. Только оказалось, что никакой особой экономии просто-напросто нет.
Разумеется, но сравнивать бинарный XML с ASN.1 даже смешно.
V>>Кстати, за сколько времени на коленке сделаешь XML-парсер с полноценной валидацией по схеме? Боюсь, что примерно за то же время, что и ASN.1 компилятор, т.е. задача сложная, и достойна внимания только при дальнейшем коммерческом распространении написанного инструмента. C>Да, это непросто. Но смысл в том, что это можно было делать ПОСТЕПЕННО. То есть, сначала написать SAX-парсер, потом добавить DOM. А потом на досуге валидатор по схеме. На каждом этапе у нас была полностью рабочая система.
Ну я как бы прилично лет посвятил разработке софта на "железки", для которых мало чего есть изначально, и мне с трудом представляется твой сценарий. А на системах общего назначения, как мы уже договорились ранее, полно бесплатного для обоих вариантов, и даже есть однозначный маппер со схем XML в ASN.1 (ибо оба стандарта полны в плане описания данных, а значит должно существовать однозначное соответствие).
V>>Немного не так, масштабируемость не подкосили. Сейчас IOR можно сравнить на клиенте, но все реализации при неудачном сравнении запрашивают сервак, т.е. они просто внесли некую оптимизацию в процесс сравнения. А вообще странный у тебя аргумент, зачём вообще сравнивать IOR-ы, не объяснишь? ИМХО, сценарий предположительного их использования не предусматривает сравнения в клиентском коде (может я чего-то упустид? ). C>IORы должны быть полностью непрозрачной ссылкой для полностью идеологического соответствия. Сравнивать их нужно редко, это я просто как пример привёл.
А они и есть непрозразные для клиента. Лишь очень немногие библиотеки предоставляют ср-ва парсинга IOR-ов.
C>Ага. Мне вот как-то потребовалось затуннелить CORBA через HTTP-прокси (с запрещённым CONNECTом) — получился полный упс.
Естественно. Тут уже в ветке упомянули, что сигналинг (обмен короткими сообщениями по-сути) — это как бы третья разновидность нагрузки (по сравнению с тем же TCP и UDP), и требует своих оптимизированных сценариев и инфраструктуры, ибо ни TCP ни UDP не являются оптимальным транспортом для этой нагрузки. Тут нужна гарантированная доставка сообщений без установления связи, такой транспорт есть в OSI, но его нет в IP, поэтому в существующих решениях тех же удалённых объектных вызовов всё не совсем гладко by design, т.е. это не проблема конкретно CORBA.
C>>>Нет, Java/.NET — это просто языки с хорошими библиотеками. И самое главное — их не надо самому реализовывать. V>>CORBA тоже не надо самому реализовывать, для Java и дотнета уже есть полно бесплатного. Опять же, CORBA — это гетерогенность для задач объектных вызовов, и ничего более. C>Для Java в последних версиях JRE собираются выбросить CORBA. Так как никому не нужна, а места занимает 2 мегабайта.
Громкое утверждение. "Никому не нужна" и "целесообразно вынести в отдельно поставляемые библиотеки" — это разные вещи. Разумеется, в базовой библиотеке ей не место.
Здравствуйте, ArtDenis, Вы писали: AD>У меня есть подозрение, что для клиентской части хватит обычного AD>java-скрипта. Хотя я могу и ошибаться.
Не хватит. У обычного джаваскрипта искусственно урезаны возможности по работе с файлами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, misha_irpen, Вы писали: S>>Попробуйте научить ваш сервер отдавать нормальные хидеры, и ваш входящий трафик уменьшится в разы. _>Спасибо, учтем.
Ну что, Миша, есть успехи? Я с замиранием сердца жду реализации... Что-то мешает прикрутить простой-простой заголовок в скрипте? Это ж дело получаса...
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали: HB>>А какой протокол позволяет послать одновременно несколько запросов через одно соединение? A>позволяют опущенные Антоном POP3 и SMTP
С каких это пор? POP3 и SMTP ничего подобного не позволяют. Там всё строго последовательно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
HB>>>А какой протокол позволяет послать одновременно несколько запросов через одно соединение? A>>позволяют опущенные Антоном POP3 и SMTP S>С каких это пор? POP3 и SMTP ничего подобного не позволяют. Там всё строго последовательно.
Преупорядочивать нельзя, а послать несколько запросов — можно.
Здравствуйте, adontz, Вы писали: A>Преупорядочивать нельзя, а послать несколько запросов — можно.
Поскольку процесситься они будут строго последовательно, никакой особенной "одновременности" в этом нет. Это всего лишь наполнение буфера TCP/IP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
.>Ещё элементарно добавляется s к концу... https то бишь.
Мне больше нравится шифрование уровня канала. Встроенное в WCF или вообще циской. Вроде как намного производительнее и меньше геморроя. Хотя страдает "универсальность" и просто уровень понтов — "|пп| у нас https |пп|".
Здравствуйте, Sinclair, Вы писали:
S>А вот нехрен делать подчерк в имени хоста — это нарушает стандарт.
При том, что как раз виндовый DNS уже давно держит юникод и позволяет всякие вольности в именах хостов. Надо уж последовательными быть...
VGn wrote:
> .>Ещё элементарно добавляется s к концу... https то бишь.
> Мне больше нравится шифрование уровня канала. Встроенное в WCF или > вообще циской. Вроде как намного производительнее и меньше геморроя.
Вообще-то WCF поверх https ходит. Ну или просто SSL. Или я что-то не знаю?
Насчёт циски не знаю, но вроде раньше специальные железки SSL-шифрования делали как раз для https, но сейчас CPU удобнее и дешевле.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
.>Вообще-то WCF поверх https ходит. Ну или просто SSL. Или я что-то не знаю? .>Насчёт циски не знаю, но вроде раньше специальные железки SSL-шифрования делали как раз для https, но сейчас CPU удобнее и дешевле.
WCF ходит поверх чего хочешь (точнее: поддерживает большое количество протоколов). Но имхо как раз WCF поверх https — это извращение, хотя вполне себе работает.
Я имел в виду вообще шифрование в канале (без ssl) для железок и шифрование только данных (без затрагивания заголовков, вроде) для wcf. И то и другое позволяет не прариться по поводу способов обеспечения безопасности в том смысле, что замечательно их инкапсулирует.
VGn wrote:
> WCF ходит поверх чего хочешь (точнее: поддерживает большое количество > протоколов). Но имхо как раз WCF поверх https — это извращение, хотя > вполне себе работает.
Может и извращение, но http много где работает.
> Я имел в виду вообще шифрование в канале (без ssl) для железок и > шифрование только данных
А какой протокол? И в чём принципиальное отличие от ssl?
> (без затрагивания заголовков, вроде)
А смысл?
> для wcf. И то и другое позволяет не прариться по поводу способов обеспечения > безопасности в том смысле, что замечательно их инкапсулирует.
Ээ... А что может позволить париться меньше, чем https?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> WCF ходит поверх чего хочешь (точнее: поддерживает большое количество >> протоколов). Но имхо как раз WCF поверх https — это извращение, хотя >> вполне себе работает. .>Может и извращение, но http много где работает.
от http я отказываться и не просил
>> Я имел в виду вообще шифрование в канале (без ssl) для железок и >> шифрование только данных .>А какой протокол? И в чём принципиальное отличие от ssl?
не важно какой протокол
>> (без затрагивания заголовков, вроде) .>А смысл?
Протокол http ни на что не меняем. Никаких тебе ..s (изменения урлов), никаких принудительных сертификатов.
VGn wrote:
>> > WCF ходит поверх чего хочешь (точнее: поддерживает большое количество >> > протоколов). Но имхо как раз WCF поверх https — это извращение, хотя >> > вполне себе работает. > .>Может и извращение, но http много где работает. > от http я отказываться и не просил
А как обеспечить секьюрность?
>> > (без затрагивания заголовков, вроде) > .>А смысл? > Протокол http ни на что не меняем. Никаких тебе ..s (изменения урлов), > никаких принудительных сертификатов.
Без сертификатов/паролей секьюрность теоретически сделать невозможно.
https самый простой способ (при этом не страдает надёжность) — хотя бы благодаря его популярности и широкой распространённости.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, VGn, Вы писали: VGn>Протокол http ни на что не меняем. Никаких тебе ..s (изменения урлов), никаких принудительных сертификатов.
Хм. А можно для тупых рассказать, каким образом твое безсертификатное шифрование поможет защититься от атак типа man-in-the-middle? https не идиоты придумывали.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
>> http://www.devx.com/codemag/Article/33342/1763/page/2 .>Как "никаких принудительных сертификатов" соотносится с "<certificate encodedValue=...>"???
Тем что, как я понимаю, это только один из способов, альтернативный https.
Я не призываю отказываться от SSL. Мне просто не нравится, что URL может зависеть от способа шифрования.
При этом HTTPS кое-где тоже имеет место быть. Например в широковещательных сервисах.
Всем место найдётся
Здравствуйте, VGn, Вы писали: VGn>Тем что, как я понимаю, это только один из способов, альтернативный https.
Способов много, но надо учитывать, что шифрование без удостоверения личности второй стороны — фикция. Потому что глупо надеяться на то, что злоумышленник сможет подслушать линию, и не сможет в неё вклиниться.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Способов много, но надо учитывать, что шифрование без удостоверения личности второй стороны — фикция. Потому что глупо надеяться на то, что злоумышленник сможет подслушать линию, и не сможет в неё вклиниться.
При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может.
Здравствуйте, VGn, Вы писали: VGn>При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может.
Ну конечно же сможет. Ведь настоящий сервер может всё расшифровать? Вот и подменный тоже сможет. Сертификаты, которые тебе так не нравятся, придумали не зря.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
VGn>>При несимметричном шифровании злоумышленник может только подменить сообщение. Расшифровать не может. S>Ну конечно же сможет. Ведь настоящий сервер может всё расшифровать? Вот и подменный тоже сможет. Сертификаты, которые тебе так не нравятся, придумали не зря.
Только если он до этого послал пользователю свой открытый ключ, выдав его за ключ сервера. А это уже простой прослушкой трудно назвать. Собственно для проверки ключей и создана сертификация.
Это вы, думаю, знаете.
Здравствуйте, VGn, Вы писали: VGn>Только если он до этого послал пользователю свой открытый ключ, выдав его за ключ сервера. А это уже простой прослушкой трудно назвать.
Еще раз: глупо надеяться, что злоумышленник получит read-only доступ к каналу. Как правило, если есть доступ к каналу, то есть и возможность вклиниться.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
