Здравствуйте, Curufinwe, Вы писали:

C>А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше?
Честно признаюсь — XMPP не смотрел. На первый взгляд, удержание соединения обходится неприлично дорого. С другой стороны, для messaging, которое не сохраняет history на серверной стороне, такая схема может оказаться эффективнее. Надо изучать точнее.
Асинхронное двустороннее общение (ака Email) совершенно точно прекрасно ложится в HTTP.

Здравствуйте, 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 работает быстро, даже для коротких запросов с небольшим количеством возвращаемых данных.

Здравствуйте, Sinclair, Вы писали:


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 выполняется долше всего...

...я ж говорю...HTTP ОТСТОЙ

Здравствуйте, Shabi, Вы писали:
S>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос
S>q1 выполняется долше всего...
Открывай несколько параллельных коннектов.
S>...я ж говорю...HTTP ОТСТОЙ
А какой протокол умеет автоматически переупорядочивать запросы?

Здравствуйте, 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 простыми средставми малодостижимо.

Здравствуйте, Sinclair, Вы писали:

S>>...я ж говорю...HTTP ОТСТОЙ
S>А какой протокол умеет автоматически переупорядочивать запросы?

эти три

Автор: Трурль
Дата: 04.04.08

(по крайней мере SMPP и EMI/UCP -- точно, посколько они как раз и создавались для асинхронного взаимодействия, поэтому в самом протоколе оговаривается, что ответы могут приходить совсем не в том порядке, в котором инициировались запросы).

> S>Т.е., непосредственно к оптимизации передачи относится, насколько я
> понимаю,
> S>"Caching of responses in kernel mode". Причем сделано это, очевидно, в
> S>первую голову для кэширования динамического контента — статический и так
> FS
> S>закэширует.
> Нет. На всякий случай напомню, что FS кэширует дисковые страницы. А
> в httpResponse уезжают вовсе не они. Например, response может быть пожат
> gzip-ом.

Что мешает положить на диск готовые ответы?

> Фишка в том, что статический контент отдается без перехода в user mode.
> Три драйвера договариваются между собой в режиме ядра.

Это да. Хотя в случае статического контента на мой взгляд это совсем уж
копейки.

Здравствуйте, Sinclair, Вы писали:

Было бы все так красиво — жил бы себе не тужил. Лучше не воспевать достоинства, а учитывать недостатки.
Про асинхронку уже было сказано. А вот про то, что это текстовой формат — нет. Проблема в том, что он не просто текстовой(я говорю не о боди). Он 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 в виндах выключена в целях безопасности).

Здравствуйте, Sinclair, Вы писали:

C>>А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше?
S>Честно признаюсь — XMPP не смотрел. На первый взгляд, удержание соединения обходится неприлично дорого. С другой стороны, для messaging, которое не сохраняет history на серверной стороне, такая схема может оказаться эффективнее. Надо изучать точнее.
S>Асинхронное двустороннее общение (ака Email) совершенно точно прекрасно ложится в HTTP.

В случае с email согласен, но для instant messaging HTTP может хоть как-то подойти только в виде COMET — т.е. опять постоянное удержание соединения.

Здравствуйте, Sinclair, Вы писали:

S>

Миф номер 3: Ага! Клиент-то может и маленький, а сервер? Он же тормозит!

S>Ну, вообще-то, смотря какой сервер, и что понимается под "тормозит". Обычно, stateless HTTP сервер рвет аналогичный по функционалу сервер с удержанием соединения как тузик грелку. Потому, что HTTP клиент работает в "импульсном" режиме: сбегал к серверу (за 40 миллисекунд), и тупит локально, до следующего запроса. Редкий пользователь кликает ссылку ежесекундно.
S>(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален)
S>Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.

Случай с веб-сервисами. Запросов через веб-сервисы легко может быть до сотен и тысяч в секунду.

Здравствуйте, vb-develop, Вы писали:

S>>(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален)
S>>Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.

VD>Случай с веб-сервисами. Запросов через веб-сервисы легко может быть до сотен и тысяч в секунду.
От одного клиента?

Здравствуйте, 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 клиенте.

Здравствуйте, 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 существенный по сравнению со временами обработки сервера/простоя на клиенте.

Здравствуйте, Curufinwe, Вы писали:

A>>HTTP для IM не предназначался изначально, потому и использовать его для этих целей не стоит. HTTP разрабатывался для гипертекстовых систем, где работа осуществляется по принципу "запрос-ответ".
C>Замечательно
C>А то тут пытаются нас убедить, что HTTP подходит для всего кроме двухстороннего media streaming

Сейчас есть множество расширений протокола, но от заложенного изначально "ограничения" полностью избавиться нельзя, т. е. полноценного дуплекса мы не получим.

Здравствуйте, Sinclair, Вы писали:

>Непонятно, зачем тебе бинарные данные в заголовке. Стандарт на представление non-ASCII characters в Header устоялся уже очень давно. Стандарт на переносы длинных строк — тоже.
Устоялся. Только это называется — ноги от Arpanet'а(RFC 822)
Ну примерно:

<a href="<%# String.Format("~/MyFile.aspx?name={0}&name1={1}&name2={2}", Eval("Name1"),Eval("Name2"),Eval("Name3")) %>">Ошибки</a>

Попробуй напиши это правильно. Так чтобы работало.

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

(я использую самописный протокол. открываеца только один сокет... клиенту ненужно думать о том в какой последовательности кидать вопросы и в какой последовательности придут ответы)

полагаешь мне обеспечена медалька за прорыв в коммуникациях?