На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2002-2-27 на главную / новости от 2002-2-27
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 27 февраля 2002 г.

Гуру Microsoft: «Нужно избавляться от HTTP-зависимости»

Теперь, когда с целью расширения адресного пространства интернета протокол IPv4 постепенно заменяется на версию 6, обнаруживается еще один подводный камень интернета: похоже, HTTP также приближается к своему пределу.

Во вторник архитектор команды разработчиков платформы Microsoft .Net Дон Бокс (Don Box), выступив с докладом на конференции European DevWeek в Лондоне, сказал, что протокол HTTP представляет большую проблему для веб-сервисов, приложений peer-to-peer и даже безопасности. Со временем ему придется искать замену, но пока не ясно, кто должен этим заниматься.

HTTP (HyperText Transport Protocol) используется практически каждой веб-страницей в интернете. Это механизм, посредством которого браузер посылает запросы к серверу через интернет, а затем получает ответы.

«Одна из крупных проблем, стоящих на пути внедрения веб-сервисов, в нашей зависимости от HTTP», — сказал Бокс. В самом HTTP ничего плохого нет: повсеместное распространение и высокая надежность этого протокола сделали его единственным средством безотказного взаимодействия через интернет. «Если кто-то не может войти в веб, они звонят в отдел технической поддержки, который всегда заставит HTTP работать. Мы изучили его до мельчайших деталей». Бокс даже назвал HTTP «тараканом интернета», так как «это единственный протокол, который уцелеет после катастрофы».

Однако вечно жить с HTTP мы не сможем, несмотря на все вложенные в него деньги и идеи. Одна из проблем — то, что это протокол дистанционного вызова процедур (Remote Procedure Call, RPC); то есть одна программа (например, браузер) обращается за обслуживанием к другой, расположенной на отдельном компьютере (сервере) в сети, причем ей нет необходимости разбираться в деталях устройства этой сети. Данная модель подходит для мелких операций, запрашиваемых веб-страницами, но, когда веб-сервисы начнут выполнять тысячи транзакций, обработка которых требует времени, она не справится. «Если ответа придется ждать три минуты, для HTTP это уже нереально», — утверждает Бокс. Проблема, по его словам, в том, что посредники — то есть компании, владеющие маршрутизаторами и кабелями, соединяющими клиентов с серверами, — не допустят столь продолжительных транзакций. «Необходимо придумать что-то, чтобы уменьшить зависимость от HTTP, — сказал Бокс. — Опираясь только на этот протокол, мы просто раздавим интернет. Как минимум, мы должны повысить уровень абстракции и найти общепризнанный способ выполнять запросы с большим временем ожидания — так, чтобы, отправив запрос на сервер, можно было рассчитывать на получение результата через пять дней».

Адаптация к P2P
Другая проблема HTTP, по словам Бокса, заключается в том, что это асимметричный протокол. «Инициировать диалог по HTTP может лишь один участник, другой пассивен и только отвечает. Для систем peer-to-peer это не годится», — сказал он. Сегодня peer-to-peer приложения работают только потому, что программисты ухитряются при помощи всевозможных уловок обходить это ограничение протокола, но в этом нет ничего хорошего. «Все это хакерство, искусственные методы, несовместимые друг с другом» — такой вывод делает Бокс.

Бокс сообщил, что ведется работа по преодолению недостатков HTTP. Несколько рабочих групп решают эту проблему в организации W3C, отвечающей за веб-стандарты. Занимаются этим и в Microsoft, хотя корпорации вряд ли удастся добиться успеха в одиночку. «В Microsoft есть некоторые идеи (по поводу преодоления зависимости от HTTP), некоторые идеи есть у IBM и других. Посмотрим... Но, если один производитель сделает что-то самостоятельно, результат не будет стоить вложенного труда», — заключил Бокс. 

 Предыдущие публикации:
2002-02-19   Подпольщики медленно обживают сетевые катакомбы
2002-02-24   В интернете становится тесно
 В продолжение темы:
2002-04-16   Почему веб-сервисы изведут — со временем — HTTP?
Обсуждение и комментарии
Иофор
27 Feb 2002 5:16 PM
Ну, если "в Microsoft есть некоторые идеи ..." жди беды :-))
 

Слопер
27 Feb 2002 6:38 PM
Иофору

Я бы сказал "не жди беды", а жди много работы для программистов и дизайнеров
 

AM
27 Feb 2002 7:58 PM
И скажу я - это есть хорошо!
Будет и завтра что намазать на булку.
И прикрыть намазаное тоже получиться.
 

Artem - fhntvrocketmail.com
27 Feb 2002 8:52 PM
Точнее MS раздражает, что это не их стандарт. Естественно, что им понятно, кто должен заниматься разработкой нового протокола - монополист.
 

Deather
27 Feb 2002 9:34 PM
2 Artem: А какая рзница кто имплементировал стандарт? Например в случае CLI - более общая имплементация известная как .Net Framework а сам CLI - стандарт в ECMA. Прав AM что от этого только у программистов работы прибавится что есть good :-)
 

Humanoid
27 Feb 2002 11:03 PM
Эти удлюдки из M$ даже DOM выработанный по их рекомендациям не поддерживают, так что намазывать на бутербробы будешь
фекальное масло
 

dogada
27 Feb 2002 11:24 PM
[cite]
Если ответа придется ждать три минуты, для HTTP это уже нереально», — утверждает Бокс. Проблема, по его словам, в том, что посредники — то есть компании, владеющие маршрутизаторами и кабелями, соединяющими клиентов с серверами, — не допустят столь продолжительных транзакций.
[/cite]
Это ли не бред? Как "компании, владеющие маршрутизаторами и кабелями" могут влиять на сокеты открытые у клиента и на сервере. Надо тебе пять дней ждать - жди, не закрывай сокеты, хотя это и будет идиотское решение в стиле Microsoft. А если транзакции по 5 дней, то с адресным пространством IPv6, какие проблемы через 5 дней обратиться к клиенту по его IP и передать результаты?
 

Иофор
28 Feb 2002 9:52 AM
2 dogada: Проблемы таки есть -- например если используется IP masquerading, то у нескольких клиентов может быть один IP.
Кстати, .NET не привязан к конкретному протоколу, он с таким же у спехом может использовать и FTP и SMTP. Да, и еще есть MSMQ как раз и ориентированная на асинхронный обмен сообщениями. Но это уже технология Microsoft.
Конечно, P2P требует нового протокола -- посмотрим что будет делать Microsoft -- возьмет за основу уже существующие реализации P2P или опять пойдет по своему особому пути :-)
 

Skull - sibskullmail.ru
28 Feb 2002 11:06 AM
Ой, блин! Это что за транзакции по три минуты и по пять дней? Типа, кластер 486-ых машин под Windows? В таком случае предлагаю MS решение - посылать результат по e-mail!

P.S. И денег надо взять с MS за идею не забыть!
 

dogada
28 Feb 2002 12:35 PM
2 Иофор: IP masquerading это, наверное, проблема, но к самому HTTP имеющая весьма призрачное отношение. К тому же я писал об IPv6, где с адресным пространством проблем нет.
А по поводу ассинхронной обработки сообщений, MQ ведь не только у Microsoft есть. На Java их с десяток реализовано, в том числе и open-source. Но, как я понял из статьи, MS не надо ассинхронная обработка, ей надо синхронная с timeout >= 5 дней :)
 

Se
28 Feb 2002 12:54 PM
Кстати, этот Бокс будет представлять vs.net в Москве 4 марта. Сходить бы послушать...
 

-
28 Feb 2002 1:03 PM
2Skull:

Olap запросы большого объема
 

PTO - kruchkovkgb.ru
28 Feb 2002 1:03 PM
2 Se: дык сходи... я вон даже на вечерний круглый стол с ним записался...
 

Egres
28 Feb 2002 1:38 PM
2 dogada,Иофор: Используйте ПО или устройства тех производителей которые поодерживают "нормальный" нат. masquerading впринципе урезанный нат, позволяющий транслировать несколько адресов внутренней сети в единый реальный. Данный вариант как правило подходит для небольших компаний которые не держат собственных www, smtp и пр. серверов для внешнего мира, или содержат данные службы на одной машине с реальным ip.
А вот по поводу долгих транзакций, то извените.... Если извините большое кол-во коннектов будет длится долгое время любая более менее нормальная система обнаружения вторжения прореагирует на на это.
 

Shadow
28 Feb 2002 4:36 PM
Е...на мать! ОНИ ХОТЯТ ВМЕСТО Internet стародавний MSN сунуть!
Вы соображаете, работа блин для программистов?
Как будто работы нет...
 

vIv
28 Feb 2002 4:36 PM
абсолютно согласен с гуру кроме одной неточности: у него не та аббревиатура в высказывании.
Вместо "HTTP-" читать "MS-"
 

vIv
28 Feb 2002 4:41 PM
а, кстати, нефиг пускать "долгие" сокеты по транзитам, на которых заявлено, что они рубятся. надо прокинуть "долгое" - прокинь и не жужжи... Тоже мне, нашли проблему... гуру, блин... rtfm не умеют, постановки не умеют, а жужжать умеют

на самом деле всё они умеют, только им надо срочно что-то впаривать, причём так, чтобы нагружать кабеля. и тут нормальные решения категорически не подходят, - они ж работают, собаки, уже сегодня, и не впаришь ничего за денюжку.
 

vIv
28 Feb 2002 4:44 PM
а вообще-то весьма занятно наблюдать за профессиональным охмурёжем леммингов.
десятилетия есть сокеты, десятилетия все, кому надо, делают свои решения на них, и только МС ради нового протокола брызжет слюной на сбоку стоящий http...
 

CHOP
28 Feb 2002 6:24 PM
про "ответа придется ждать три минуты" я что-то не понял. а push-каналы как работают? нет ведь никаких траблов?
 

PTO - kruchkovkgb.ru
28 Feb 2002 6:45 PM
ну на самом деле самая большая проблема тут в однонаправленности протокола - запрос-ответ идет только от одной стороны и пушить только через жопу получается... а для веб-сервисов идеально иметь двунаправленный контакт (к примеру изменилась стоимость акций и обновление пушится всем клиентам подключенным)... в случае с классическим ХТТП открывается засада...
 

qwerty
28 Feb 2002 7:24 PM
2РТО: Если делать двунаправленный контакт - резко возрастёт количество данных в сети. Прикинь, ты закрыл у себя программу, а веб-сервис ещё 3 дня будет пытаться тебе сообщить курс акций.
 

vIv
28 Feb 2002 9:40 PM
2CHOP: это ты... а "гуру из МикроСофт" этого "не знает" ;-)
 

vIv
28 Feb 2002 9:42 PM
2PTO: это ежели HTTP, но как-бы никто не мешает прочесть введение в тот же rfc1945 и узнать о существовании сокетов. Это, конечно, большой сюрприз, но "сюрприз прошлого века". НИКТО НЕ ОБЯЗЫВАЕТ иметь ОДНОНАПРАВЛЕННЫЙ протокол. Т.е. типа ВААЩЕ НИКТО!

Желающие уже пару десятков лет юзают просто сокеты и не знают, что в них есть какие-то проблемы.
Просто нужно открыть для себя протокол TCP - и волосы станут шелковистыми ;-)
 

vIv
28 Feb 2002 9:43 PM
2qwerty: не! и, прикинь, да? - ни одного байта между двумя хостами не пробегут! Просто ДВА ОТДЕЛЬНО ВЗЯТЫХ ХОСТА БУДУТ ДЕРЖАТЬ В ПАМЯТИ СООТВЕТСТВИЕ
 

vIv
28 Feb 2002 9:46 PM
2qwerty: не! и, прикинь, да? - ни одного байта между двумя хостами не пробегут! Просто ДВА ОТДЕЛЬНО ВЗЯТЫХ ХОСТА БУДУТ ДЕРЖАТЬ В ПАМЯТИ СООТВЕТСТВИЕ в параметрах сокета. И не более. И любой из них сможет в любой момент продолжить сессию. ВНИМАНИЕ: _ЕСЛИ_ оба могут TCP.

Чудеса, не правда ли? Да парни, писавшие в 80-х TCP-стэк для BSD, просто не были в курсе, что в 2002 облажают Великих Гуру! 8-)))
 

RoN - rodionlenta.ru
28 Feb 2002 10:46 PM
2 vlv: Да речь ведь идёт не о сокетах вообще, а о HTTP.
Сокеты, это вааще не есть сетевой протокол. Сокеты - это API к протоколу TCP/IP, поверх которого может работать и HTTP, и RPC и SMB и т.д., желающие могут продолжить. Более того, в виндах сокеты даже не обязаны работать с TCP/IP, а могут служить API и к другим протоколам. Сокеты действительно могут и в ту и в другую сторону работать. А вот HTTP - никак. Он чиста клиент-сервер: -- получил-запрос -> ответил -> обязан-о-запросе-забыть --.
Любой, кто писал когда-нибудь приложения для интерактивной работы с серваком через веб знает, какой геммор с этим связан.
 

eXOR
1 Mar 2002 2:23 AM
http://search.microsoft.com/default.asp?qu=tcp&boolean=ALL&n q=NEW&so=RECCNT&p=1&ig=01&ig=02&ig=03&ig=04&ig=05&ig=06&i=00 &i=01&i=02&i=03&i=04&i=05&i=06&i=07&i=08&i=09&i=10&i=11&i=12 &i=13&i=14&i=15&i=16&i=17&i=18&i=19&i=20&i=21&i=22&i=23&i=24 &i=25&i=26&i=27&i=28&i=29&i=30&i=31&i=32&i=33&i=34&i=35&i=36 &i=37&i=38&i=39&i=40&i=41&i=42&i=43&i=44&i=45&i=46&i=47&i=48 &i=49&i=50&i=51&siteid=us/dev
говорят что это - таки протокол... а в остольном согласен. А не нравится http - вперез за telnet... или rsh... черех http tunneling.. и все... и будет вам щазтье.
 

rGlory
1 Mar 2002 7:52 AM
2 RoN
> Более того, в виндах сокеты даже не обязаны работать с TCP/IP, а могут служить API и к другим протоколам.

Ухтыыыыыж, а давно это придумали в Микрософте?
 

RoN - rodionlenta.ru
1 Mar 2002 9:28 AM
2 rGlory: Прежде чем зубоскалить, разберись с OSI...
 

RoN - rodionlenta.ru
1 Mar 2002 9:33 AM
"Winsock is an interface, not a protocol. As an interface, it is used to discover and utilize the communications capabilities of any number of underlying transport protocols." (с)
 

vIv
1 Mar 2002 12:13 PM
2RoN:
и кто дурилке, забивающему винчестером гвозди, злобный буратина? http "для активной двунаправленной работы приложений", _явно_ не предназначен.
 

PTO - kruchkovkgb.ru
1 Mar 2002 12:24 PM
2 qwerty: ну и что... зато просто, дешево и очень здорово для b2b-приложений... за одно еще и мимо файрволлов ходить просто...

2 vlv: ну и? базар идет за HTTP, а не за tcp/ip... не за сокеты, а за совершенно конкретное ограничение протокола, вернее за плохое его соответсвие тем задачам, которые сегодня жисть ставит перед народом... и не Беркли виноват, а те мужики, которые на этих сокетах и tcp/ip придумали ХТТП не зная для чего его в 2002 году захотят применять любители веб-сервисов... типа спорим-то о чем? я о том что помидоры красные... не грит vlv - апельсины оранжевые...

 

RoN - rodionlenta.ru
1 Mar 2002 12:27 PM
2 vlv: Полносьтью согласен. Но HTTP стандартизован, а выдумай свой бинарный протокол - и будешь с ним сидеть в песочнице из собственных приложений. Статья-то о том и есть, что HTTP для "активной двунаправленной работы приложений" не подходит, и для таких приложений нужно принимать какой-то другой стандарт.
 

vIv
1 Mar 2002 12:29 PM
ну и делали б, как все... все ж делают - и не тяфкают на http

и только Великие Гуру при рождении ребёнка считают категорически необходимым убить свёкра соседа
 

vIv
1 Mar 2002 12:34 PM
2PTO:
А при чём тут бедолага http-то?
"Вот я картриджами для струйников пытаюсь забивать гвозди. Картриджи ломаются. Они плохие, негодные картриджи! Картриджи для струйников надо доработать - снабдить стальными ударялками"

ну не шиза ль?!
 

RoN - rodionlenta.ru
1 Mar 2002 12:44 PM
2 vlv: > "ну и делали б, как все..."
А как делают все ?
 

Olaf
1 Mar 2002 1:03 PM
У нас это делается так:
запрос инициирует на сервере начало рабаты с задачей и присваивает ей ID. После этого клиенту тут-же отправляется ссылка с этим ID на место где этот результат появится (сгенерируется).
Клиент (если хочет) сидит и смотрит на экран с обновляющимся через какое то время запросом (пока нет результата расчета).
Не хочешь сидеть добавь эту ссылку на ID будующего ответа себе в "Избранное" и уходи домой.
Как вспомнишь запустишь HTTP броузер и по ссылке выйдешь на результат. Как только результат нормально отослался программа следящая за логом удаляет результат из того местя где он был сгенерирован. Ну и конечно есть сборщик мусора который проверяя
логи удаляет невостребованные результаты после (к примеру) 5 дней.
 

vIv
1 Mar 2002 1:22 PM
2RoN:
1) формулируются требования к подсистеме передачи
2) разрабатывается протокол
3) реализуется
4) сопровождается и при необходимости развивается

собссна, как и всегда в разработке ПО.

 

vIv
1 Mar 2002 1:24 PM
кстати, хороший пример "протокола" именно "долгих транзакций с неизвестным сроком отработки", с применением http и smtp для фронтэнда, и, похоже, их же для бэкэнда:
http://bugzilla.org/

хорошо подобрали нужное при минимуме инноваций
 

PTO - kruchkovkgb.ru
1 Mar 2002 1:31 PM
2 vlv: почему шиза?! Народ честно говорит, что сегодняшние задачи плохо решаются с существующим сегодня и самым любимым всеми и вся протоколом ХТТП... и настает время придумать ему замену, с помощью которого можно и гвозди забивать... а ХТТП это протокол поверх которого чего только не делают и что только в него не туннелируют и сегодня, когда работают кучи приложений на разных платформах при закрытых файрволлах единственным более-менее универсальным протоколом остается ХТТП - его понимают все, сделать сервер/клиент легко и понятно, но запросы, которые предъявляют вебсервисы (на которых все помешались) он обеспечить не может. люди ставят проблему и предлагают ее совместно решать - а вы "шиза"...
 

vIv
1 Mar 2002 2:22 PM
не _всеми_
большинство здравомыслящих всё-таки используют то, что нужно, а не то, что не нужно
 

RoN - rodionlenta.ru
1 Mar 2002 2:37 PM
2 Olaf: Всё это понятно, я отлично знаю, как делается сеансная работа в веб-приложениях. Но это всё неэффективно. У нас крутится тут подобное приложение, которое именно из-за ассиметричности HTTP вынуждено каждые несколько секунд генерить запрос к серверу, для проверки на изменение данных. Это кривизна, это оверхед, это - ацтой.
 

RoN - rodionlenta.ru
1 Mar 2002 2:43 PM
2 vlv: Некоторые клиенты у нас иногда сталкивались с файрвольно-провайдерными проблемами даже тогда, когда юзался HTTP, просто потому что в запросах/ответах использовался MIME-type не text/*.

Ещё на моих глазах прошло три или четыре попытки юзанья DCOM-сервера через инет - все заканчивались полным отсосом, по тем же причинам.

А ты говоришь бинарные протоколы использовать...
 

glassy
2 Mar 2002 3:44 AM
А ирка на чем работает?
 

rGlory
2 Mar 2002 8:45 AM
2 RoN
>> Прежде чем зубоскалить, разберись с OSI...
Попробую
Теперь для особо умных:
>> в виндах сокеты даже не обязаны работать с TCP/IP
А мы бедные юниксоиды маемся, к одному протоколу привязанные. Вот в виндах даже сокеты не обязаны с TCP/IP работать. Лепотааа
 

rGlory
2 Mar 2002 8:50 AM
Дааа, вообще интересные доводы за эту статью: на файрволлах открыт только HTTP, но нам по нему телнетом не удобно, поэтому он ацтой, вот если другой протокол придумать, но его никто на файрволле наверное не откроет, но все равно хорошо. Блин а как базы умудряются по клиент/сервер работать и ничего? Или они тоже остой уже, в свете последних постановлений? Ндааа
 

Злая
2 Mar 2002 11:12 AM
Давайте давайте, заменим старого проверенного дедушку http на какое-нить тяжёлое нефункциональное угрёбище от мелкософта!

Начнётся тут: поставьте этот патч, поставьте тот, блиин, а мы тут опять переполнение оставили... Чтобы кушать было что нам... А потом и деньги брать будем за пользование
 

Злая
2 Mar 2002 11:17 AM
У меня такое ощущение что все виндузятники здесь просто никогда даже не пробовали ничего писать под nix :)
 

PTO - kruchkovkgb.ru
2 Mar 2002 11:44 AM
2 rGlory: ну давай расскажи нам как базы данных с клиентами через файрволлы работают... причем базы данных в одной конторе, клиенты в другой и между ними куча файрволлов стоит.

2 Злая: я хоть и не причисляю себя к виндузятникам, но мне интересно откуда такое ощущение?
 

Skull - sibskullmail.ru
2 Mar 2002 12:54 PM
Блин, я снова настоятельно предлагаю светлым головам из MS использовать e-mail: для их безосновательно долгих транзакций он как раз подходит! Вот ведь фигня - все думают, как убыстрить ответ от сервера, а MS - как работать с изначально тормозными вариантами.

P.S. Ишшо куки можно посоветовать использовать в браузере. Заходишь через месяц - а тебе на первой странице рисуется результат.
 

PTO - kruchkovkgb.ru
2 Mar 2002 1:27 PM
2 Skull: только честно... вы статью-то прочитали? или только обсуждение? ну и как куки и емейл помогут в решении задач, которые ставятся в статье?
 

Qrot
2 Mar 2002 2:07 PM
2glassy: через IRC и работает, дурилка картонная :)
2PTO: а через VPN - легко
2rGlory: ты придумай, как peer-2-peer сделать на основе http, я тебе пиво вышлю
2Злая: ну, давайте заменим на кульное и функциональное решение от САН, например, - а такое есть?
 

vIv
2 Mar 2002 4:21 PM
"куча файрволлов" бывает только в двух местах:
1) со стороны центрального сервиса, и
2) со стороны клиента

в первом случае решается один раз на всю систему, а во втором - по случаю решения, пользоваться ли данным сервисом из данного места.

PS файрволят-то локалки... какой придурок будет "рыть" транзитный трафик? разве что, если просто чем-то хочется железку нагрузить, что бы не скучала. но это уже в раздел хобби и извращений, а не в техническом трёпе.
 

RoN - rodionlenta.ru
2 Mar 2002 5:12 PM
2 vlv: "Какой придурок будет рыть транзитный трафик"

Приходит к нам клиент - "хочу работать с вашей системой". Отлично, сделайте себе доступ к инету. Находит он себе провайдера, подключается, сам, ессно нихера сделать не может. К нему приходит спец от провайдера и за $5-$10 за час всё делает. При этом настраивает ему доступ через прокси самого провайдера, т.к. им по какой-то причине это выгодно. Через день-два клиент начинает заё...ть меня звонками "у меня то не ходит, это не работает", начинается аборт по телефону. В конце-концов выясняется, что грёбанные спецы провайдера открыли ему доступ только через 80 порт, да ещё кешируют трафик на своём прокси, все ведь думали что он только порнуху будет смотреть через инет.

Подобные заморочки я могу рассказывать неделями.
 

vIv
3 Mar 2002 6:52 PM
и кто тут "злобный Буратина", не написавший на бумажке дяде лоху комплект требований к коннективити?
 

vIv
3 Mar 2002 6:54 PM
не могу сказать, что готов начитывать формальную логику семестрами, но могу сказать, где её начитывание можно заказать: в ближайшем ВУЗе. Возможно за отдельную денюжку, но это уже другой вопрос.

ИТОГО: Нехер, братцы, в случае конкретных требований щёлкать клювами, - работать надо нормально: чтобы согласно выкаченным требованиям херня робила!
 

RoN - rodionlenta.ru
3 Mar 2002 9:11 PM
2 vlv: "Комплект требований к коннективити". Я валяюсь под столом от смеха. Одному "дяде лоху" сказали пинг сделать по нашему серверу, так он открыл експлорер и в адресной строке набрал www.ping.ru. А ты говоришь - писать ему требования. Когда дохера пользователей, которые раскиданы по территории что за неделю не объедешь, чтоб к каждому заехать, самые приемлимые требования к системе - отсутствие оных.
 

rGlory
3 Mar 2002 9:23 PM
2 RoN
А может к той системе и компьютер не нужен? И сама система? Самие приемлимые требования по Вашему, остуствие требований к самой системе, но присутствие требований к протоколам? Причем таких, к которым они изначально не были предназначены? По ftp наверное неудобно будет письма отправлять, хотя можно извратиться, по SMTP неудобно по телнету работать и так далее. Давайте их всех переделаем, шоб какой бы порт на файрволле ни открыли, мы тут же и файлы туда, и через прокси и p2p. Вот тогда все будут счастливы. Прадва работать не будет, или будет, но плохо. Но это уже мелочи.
 

Qrot
3 Mar 2002 11:05 PM
ну мля, ну что за люди... писано же русским языком - http не подходит для некоторых задач, нужен новый протокол. через фтп тоже можно общаться, но неудобно - умные люди придумали почту. теперь ситуация такая же - неужели трудно аналогии провести?
 

Qrot
3 Mar 2002 11:06 PM
если бы было написано - гуру ИБМ "Нужно избавляться от ХТТП-зависимости" - интересно, тоже самое было бы?
 

glassy
4 Mar 2002 12:37 AM
2Qrot: абсолютно :)
А с SMTP вподне можно договориться ;)
 

Skull - sibskullmail.ru
4 Mar 2002 4:45 AM
2PTO: естественно, статью читал. Только не понятно, при чем тут старичок HTTP, если нужен другой протокол? Или "гуру Microsoft" до сих пор ассоциирует Internet и WWW? Тогда это уже клиника. Да и не будет юзер ждать у браузера окончания 3-х дневной транзакции. Это как в конфах - задал вопрос - через несколько часов/дней получил ответ.

2Qrot: гуру IBM такую чушь не морозят! Но даже если бы и сморозили, их бы также лажали...
 

Qrot
4 Mar 2002 9:44 AM
а ты делай поправку на ЗДНЕТ и на перевод :)
 

PTO - kruchkovkgb.ru
4 Mar 2002 11:21 AM
2 Skull: морозят-морозят... вот тут на полном серьезе проводили тесты в каких ОС быстрее пайпы работают, а потом вообще дошли - в каких ОС быстрее треды создаются... я плякал...

Вот смотри куча народа была счастлива с приходом b-2-c электронной коммерции... клиенту не нужно было ничего окромя веб-браузера чтобы делать покупки... потом появились торговые площадки b-2-b, но опять же с человеком в виде одной из составляющих... для 90% людей на земле Интернет и есть ВВВ и поверх ВВВ понаделано куча приложений протоколу как таковому не посильные. Теперь идет следующий этап - b2b когда компы общаются друг-с-другом (им хоть год можно конец транзакции ждать - они же не юзеры у браузера)... компы на туевой хуче платформ, приложения писаны черти кем и черти как, на разных языках, БД с разной бизнес-логикой, разными файрволлами и политиками безопасности... посему ищется что-то, что могло их объединить с минимальной стоимостью переделок и доделок... Вот содятся крутые дядьки из ИБМ, МС, КоммерцОне и еще кучи контор и придумывают как пользовать XML в виде SOAP/WSDL/UDDI - поверх какого протокола это как правило работает? А почему?
Но появляются новые задачи при которых такой общеупотребительный и весьма популярный протокол становится неудобным и не применимым... посему дядьки содятся и думают что делать, как выработать спецификации нового протокола, который бы сочетал в себе лучшие черты существующих при отстутствии проблем так же существующих.
 

eXOR
5 Mar 2002 12:20 AM
2 PTO:
Так я не понял. Сейчас нет _никакого_ протокола удовлетворяющего этим нуждам или именно http не удовлетворяет. В конце - концов можно ведь в браузере не тольео http:// писать, можно еще и telnet: тот же? Ы?
 

Skull - sibskullmail.ru
5 Mar 2002 4:44 AM
2PTO: eXOR прав! Есть же http://www.w3.org/Protocols/, nntp, smtp. Чем они-то не удовлетворили? Или от незнания rfc кое-кто любит придумывать велосипед?
 

RoN - rodionlenta.ru
5 Mar 2002 10:17 AM
Наша песня хороша - начинай сначала... :-))
 

Null - kurantvologda.edu.ru
5 Mar 2002 4:23 PM
Бля, мужики, ну не надоело демагогию разводить, корча из себя "гуру андеграунд"?

Проблему мужик поставил правильно -- на данный момент серьезно не хватает нормального симметричного АСИНХРОННОГО протокола.
Итак, если вы внимательно прочитали, проблема в следующем: транзакция пользователя обрабатывается 5 дней, после чего посылается контент данных обратно.

1. Почему не чистый TCP/IP? Очень просто: держать пустой коннекшн 5 дней как-то не круто, особенно если я делаю несколько транзакций. А уж прикиньте сколько коннекшнов будет держать сервер! А если я тачку перезагрузил? Все? Обойти-то технические особенности роутеров можно -- посылать короткий ping, как это делается в ирке, но резко возрастет бесполезная нагрузка на сеть.

2. Почему не HTTP? Думаю, понятно. Несимметричность...

3. Неужели ничего нет? Есть! Единственный асинхронный симметричный протокол уже может быть организован на базе smtp. Однако у нынешнего smtp основные недостатки в privacy, откуда появляется спэм, и прочее дерьмо... Хотя как вариант использовать можно с определенными доработками (более того, он уже используется :)

4. А что тогда? Другая модель может быть реализована посредством сервиса обмена сообщениями наподобие ICQ или MS Messenger. Для этого нужен сервер сообщений, пользователю нужен логин на этом сервере... Оповещение о выполненной транзакции пользователя идет через этот сервер, после чего контент забирается с сервера транзакций обычным сопособом, хоть через http.

Я думаю, понятно, куда клонит MS, разрабатывая собственный стандарт протоколов, вебсервисов, и аутентификации (.нет паспорт). С одной стороны правильная концепция, с другой -- закрытость стандартов сыграет свою роль. Имхо в нете не должно быть вообще закрытых стандартов.
 

RSM
5 Mar 2002 5:32 PM
2Null:

круто сказал, но вот что непонятно:

1. если говорим о необходимости разработки нового протокола, то на кой это (Д/Г)ура упоминает при этом HTTP? Не нравится - не ешь, но обсирать-то зачем...

2. да... smtp - асинхронный симметричный и всякое такое прочее... а HTTP как же? тот кто инициирует обращение - тот клиент, тот кто обрабатывает - тот сервер... вот и все решение проблем. Реализуйте HTTP сервер и клиент с обоих сторон и не морочьте людям голову. (при реализации всего этого с использованием SMTP придется ровно так же реализовывать SMTP сервер на обох сторонах)

3. ну и на последок... жил да был Гуру. Придумал крутую фигню - звать ее .Net с ее всякими прибамбасами в виде web services... и должны были они передавать данные между собой... интересно - какой же это Гуру, если он изначально не подумал о среде передачи данных? не понял сразу, что HTTP не подойдет ему... дошло до него это только года через 2 громких криков о великолепии платформы. Это не Гуру - это Идиот какой-то... =)
 

RSM
5 Mar 2002 5:36 PM
по поводу 2, для тех кто совсем в танке и туп от рождения =)

если севису A нужно послать запрос сервису B - то в этот момент A - клиент, B - сервер (HTTP). Когда B подготовит ответ, то B становится клиентом, а A - сервером... и никаких гвоздей.
 

RoN - rodionlenta.ru
5 Mar 2002 6:29 PM
2 RSM: Совсем не катит опять таки по причинам секьюрности и наличия файрволов. Кайф просто. Так перед глазами и встала картина: внутренняя сетка на несколько сотен машин и все машины - уши наружу, порты слушают.
 

RSM
5 Mar 2002 6:35 PM
2RoN:

так в любом случае у всех будут уши наружу для того или иного протокола... вариант же с постоянным соединением получаемым до получения результата здесь всех не удовлетворил (в прямом и переносном смысле =)
 

RSM
5 Mar 2002 6:36 PM
изменения в предыдущий:

"соединением получаемым до" читать как "соединением поддерживаемым до"
 

Qrot
5 Mar 2002 7:35 PM
2RSM: ты решил перегнать RMS в количестве гона, что-ли? ты хоть по 100 серверов н клиенте сделай, асинхронным от этого http не станет... либо это уже не http будет, а новый протокол.
 

Skull - sibskullmail.ru
6 Mar 2002 4:24 AM
2RSM: блин, пургу гонишь. Если уж и использовать HTTP, то юзер должен через неопределенное время инициировать запрос на получение результатов, если ему сразу их не отдали. Классика жанра. А то, что ты предлагаешь - это дурдом какой-то (извини за резкость...). Где ты видел, чтобы сервера "толкали" данные на клиента. Это клиент их должен "вытянуть".
 

RSM
6 Mar 2002 12:55 PM
тааак... ну началось... давайте обсудим какие вообще есть варианты передачи запросов/получения результатов:

1. держим соединение постоянно (просто HTTP без всяких заморочек - нукроме долгого ожидания ответа) - это некоторых не удовлетворило - так как firewall'ы и прочая лабуда рубанет такое соединения (далее рассматриваем исходя из этого - соединение не постоянное);

2. клиент отправляет запрос, потом приходит и забирает ответ (ну это совсем HTTP - только немного поддержка сессий на стороне сервера) - опять есть недовольные - сколько же нам хранить данные - вообщем ужаз какой-то =);

3. клиент отправляет данные - сервер отправляет результат (вообщем вариант с SMTP или HTTP на обоих концах) - ну вы что... какие же могут быть сервера на стороне клиента (хотя этот клиент во многих случаях все тот же сервер - он же тоже web service - и так же сервер для кого-нибудь);

вопрос - какие еще у вас есть предложения по реализации протокола - кто кому чито передает и когда получает?

PS:

2Qrot: SMTP тоже не асинхронный... просто его так используют =) клиент соединяется - сервер принимает. Для получения ответа от сервера клиент ничего не инициирует - это сервер пошлет ответ самостоятельно на узел клиента сам являясь клиентом SMTP =)...

2Skull: но это же ужасно! да как же так, сервер хранит данные!!! =) это естественно шЮтка, но кто запрещает использовать именно так? слова великой Дуры? =)
 

Null - kurantvologda.edu.ru
6 Mar 2002 6:15 PM
2RSM:

Вообще тогда вместо симметричного http лучше использовать RPC на обоих концах...

Вариант 3 можно доработать до вполне жизнеспособной системы. В принципе, тот же SMTP можно повесить на другой порт и стандартизировать обработку меседжей. Достоинство -- независимость от структуры сетей. Мэйл успешно может проходить гейты, и вообщем случае даже не требует TCP/IP. Более того, для доставки почты не нужно прямого соединения с клиентом, как это требуется при симметричном HTTP.

Вариант 2 может быть реализован с помощью протокола оповещения о выполненной задаче. Связь на подобие ICQ или MSN Messengerа. Пользователь регистрируется на сервере и оставляет свой ID по которому можно будет направить ответ (.Net Passport или ICQ Num). После выполненной задачи пользователю направляется сообщение и далее он забирает контент напрямую с сервера по http. Но это все требует централизованного учета юзеров.

Еще почему чуваку не понравился хттп -- это потому, что он статичный. Простой пример -- сраница, где бы _тикало_ время сервера. Несложно сделать при помощи Java, но для этих часиков придется разрабатывать собственный протокол передачи, назначать порт, файрволлы и все такое! Речь здесь идет скорей о стандартизации протокола обмена информацией между вебсервисами. Однако действительно странно, почему это было затронуто только сейчас...
 

eXOR
6 Mar 2002 10:04 PM
Да ладно вы.. че разругались тут. Вы лучше это посмотрите. Все равно - этим все и закончится
http://users.i.com.ua/~dybkov/M/HUMTEXT/vosp-bud.htm
 

Mauhuur - warlockskeptik.net
6 Mar 2002 11:02 PM
Вот уж чьих идей нам даром не надо, так это мелкософтовских... Они любую хорошую идею в говно превратить способны.
 

RoN - rodionlenta.ru
6 Mar 2002 11:24 PM
2 Skull: Сервер толкает данные на клиента - вполне стандартная штука. Архитектура "издатель-подписчик", называется.
 

Skull - sibskullmail.ru
7 Mar 2002 5:02 AM
2RoN: жаль, не видел таких решений. Обычно подписчики забирают сами через определенный интервал. :)
 

RSM
7 Mar 2002 11:11 AM
2Skull:

ну это вписывается в вариант 2 - просто в качестве ответа на запрос сервер говорит когда зайти за результатами работы... прогнозирование, мать его =) в принципе - если к этому времени результата нет - то сервер говорит когда попробывать зайти за результатом в следующий раз ну и так далее. Кстати, заодно сервер может сказать сколько времени результат будет хранится - и если клиент не успеет - то делаем все заново...

PS: впрочем с прогнозированием времени работы у МС всегда было не очень (личное мнение при установке всяких Win'9x & etc.)... хотя проблема это не только МС, у Adobe в свое время тоже смешно получалось - Photoshop при установке бысто добегал до 75%, где-то минуты за 3, а потом минут 10 добивал остальные 25%. Вообщем очень уж сложная это штука...

2Null:

все конечно замечательно (RPC) - вот только как быть со всякими firewall'ами... не думаю что бы они так легко RPC пропускали...
 

miroh - plasmonmail.ru
7 Mar 2002 12:17 PM
апочему никтоне вспомнил про дейтаграммы? Просто бросаешь кусок данных неустанавливая постоянного соединения - вот правда он может не дойти... Но ведь можно както обрабатывать потерю данных. Главное - нет постоянных соединений просто толпа пакетов, шныряющих туда-сюда..
 

eXOR
12 Mar 2002 8:02 PM
2 miroh:
А нафига это надобно? Потеря данных должна еще на уровне tcp/ip исчезать.
 

 

← январь 2002 20  21  22  23  24  25  26  27  28 март 2002 →
Реклама!
 

 

Место для Вашей рекламы!