Здравствуйте, 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, это очевидно).
Правильно — пишущий использует своё подмножество. А вот читающий — должен понимать всё.
> Я именно это имел вввиду, когда отвечал рядом, что футпринт для железячек в случае небольших протоколов получается очень маленьким.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, netch80, Вы писали:
N>>Ослабляет нагрузку чего? Просто на канал? Не вопрос. И с джиттером это мало связано — если пакет пропущен, но следующий приходит с адекватным timestamp, проблем нет — просто пропуск части данных.
V>На слух это ужасно, ведь пакеты не просто пропускаются, а иногда приходят не в том порядке.
Если Вы не заметили — в общем заголовке RTP по смещению 2 находится поле sequence number, а по смещению 4 — находится поле timestamp. Вот их достаточно, чтобы при приходе пакетов не в том порядке — упорядочить их как следует. А задержки вопроизведения согласно ожидаемому jitter'у — чтобы выходящий с ЦАП звук не рвался.
Главное, чтобы приёмная сторона не пыталась безумно увеличивать jitter buffer и соответствующую задержку только от того, что у передающей включился VAD.
N>>А теперь рассказываю, что будет, если связь просто пропадёт (например, при перестройке глобального раутинга какое-то время пакеты шли в интерфейс Null0): первый раз TCP сделает перепосылку через последний известный RTT, а второй — уже через три секунды (во всех известных мне реализациях). "А вот вам меч!" И страдайте теперь при мечтаниях про 150 миллисекунд.
V>Ну дык пауза в 3 сек и делов-то. И бывает это раз в пятилетку.
Увы, значительно чаще. Ваши условия слишком тепличны.
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 в середине диалога?
Здравствуйте, netch80, Вы писали: N>Кстати, для HTTP это тоже было бы полезно. Сейчас клиентские приложения вынуждены поллить сервер за новыми данными. А можно было бы сделать двустороннюю связь.
Не уверен, что это было бы полезно. Поллинг масштабируется гораздо лучше, чем двусторонняя связь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
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>>Попробуйте научить ваш сервер отдавать нормальные хидеры, и ваш входящий трафик уменьшится в разы. _>Спасибо, учтем.
Ну что, Миша, есть успехи? Я с замиранием сердца жду реализации... Что-то мешает прикрутить простой-простой заголовок в скрипте? Это ж дело получаса...
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Одно могу сказать — мы подошли вплотную к решению этой задачи, и у нас все вроде пока срастается. 
).
)
