WebSockets - почто стояли на майдане?

[metaclass]

ссылка

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

Только вот представьте себе, что счас вся серверная и прочая инфраструктура заточена под, условно говоря, "короткий запрос-короткий ответ". Я уже несколько раз сталкивался с кривонастроенными сетями у клиентов, где долговисящие запросы просто обрывались где-то в середине сети. При этом обычные всякие почты, вебы и говноторенты в таких условиях работают более менее нормально. А вот если запросу в целях работы нужно висеть установленному - жопа и смерть, 5-10 минут неактивности и гамон.

Там по ссылке где нибудь упоминается обработка ошибок? Или keep-alive пакеты на уровне протокола? Ах, да, я забыл, в гугле не бывает зависающего сетевого оборудования, сдохших свитчей и неправильно настроенных прокси, натов и файрволлов, поэтому обработкой ошибок никто не заморачивается. "У нас на столе все работает".

Надеюсь, гугол это протолкнет в мейнстрим и начнется еще лет десять ебосрани для всех ИТшников, сисадминов, к которым будет приходит руководство и требовать чтобы "у меня веб-приложение должно работать" и веб-разработчиков, которым придется выламывать себе мозг, делая нормальную обработку ошибок с помощью костылей и хаков.

Comments

[yurri.livejournal.com]

0x00, <строка в кодировке UTF-8>, 0xFF

Какой ужас и 1970-ый год.

[blacklion.livejournal.com]

Обработка ошибок — это onclose() Что-то посдказывает мне что у объекта при этом поменяется какой-нибудь .status и можно будет узнать причину.

[dizel-by.livejournal.com]

Угу, вот и я о том же писал: http://lionet.livejournal.com/44098.html?thread=888130#t888130
Был практически послан нах

[lionet.livejournal.com]

И ещё пошлю. Потому что такая у нас современная веб-инженерия — попытка среди кучи граблей отобрать себе модель под себя. В вебе всё так через жопу, никто даже не начинает ныть. И COMET вообще, и WebSockets — они ничего в эту кашу плохого не добавляют: она изначально такая, что нужно program defensively.

[blacklion.livejournal.com]

Вот чего эта радость не учитывает — так это того, что современные серверы плохо приспособелны (кроме, пожалуй, энджиникса) к мультепликсированию такого количества сокетов, как породит эта технология.

[blacklion.livejournal.com]

т.е. это такой гвоздь в гроб ещё и апача, как минимум.

[metaclass.livejournal.com]

Да, тут вообще ВСЕ не рассчитано на постоянно висящие соединения. Полезут такие черви, что веб-разработчики рыдать будут. И это хорошо, а то они со своими stateless короткоживущими запросами малость разленились :)

[max-posedon.livejournal.com]

Главная беда: раньше http был stateless, теперь statefull, со всеми вытекающими.

[metaclass.livejournal.com]

Ай, в сложных приложениях там жеж все равно состояния были. Просто что их в сессиях/состояниях юзера приходилось держать. И сейчас то же самое будет, и наверно еще хуже, потому что поверх сессии коннекта еще будет сессия приложения, и все это как-то надо будет взаимодействовать разработчику.

[w00dy.livejournal.com]

хехе, спасёт человечество как всегда Microsoft - она это говно в IE реализовывать не будет ;)

[wizzard]

микрософт зачем-то продвигает лонг поллинг в связке silverlight+iis, мне очень интересно как оно масштабируется (работает - да, скейлится ли - не пробовал)

но рекомендует юзать отдельные сокеты, факт)

[j-sheridan.livejournal.com]

Я давно уже говорил что http не предназначен для приложений. Он разрабатывался совершенно не для этого. но надо мной все только смеются и лепят монстров типа "отсылаю запрос на дополнительный сервис, сервис цепляется к БД, делает выборку и возвращает мне эту выборку в xml", прикрываясь отговорками о какойто там повышенной безопасности этой связки. На rsdn.ru такое было в компутерных священных войнах. Лень ссылку искать...

[veter-r-r.livejournal.com]

Как-то мало промежуточных сервисов :)

[metaclass.livejournal.com]

Ну блин, ну веб-хтмл-хттп был документами, ну оставался бы ими. А то все накручивают и накручивают. Постоянный коннект - это финиш, можно даже протокол переименовывать, от хттп там только название осталось :)

[volodymir-k.livejournal.com]

> Я давно уже говорил что http не предназначен для приложений.

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

[zhacka (from livejournal.com)]

От того, что будут разрабатывать приложения поверх HTTP мы уже никуда не денемся. По этому лучше уж WebSocket, нежели те костыли, с помощью которых реализовуют ту же функциональность сейчас. Или я где-то не прав?

И таки да, я уже давно думаю/говорю, что HTTP(ну, вместе с тем, как он используется) утратил свою роль и превратился в монстра.

[vp.livejournal.com]

Тут самая печаль - это то, что народ не осознает, что это должен быть ДРУГОЙ протокол. Не HTTP. А какой-нибудь там JJJ14, который будет работать по 79 порту, и все. КАК можно надеяться на совместимость совершенно с идеологически чуждым поведением запросов, что это все сможет раюботать на старом транспорте???? Народ воистину мозгом тронулся и не понимает что творит. Тут надо все проектировать с нуля, вообще.

[metaclass.livejournal.com]

Гагага, это ж какая будет срака всяким разработчикам систем контроля трафика, им придется это все поддерживаеть.

Эта музыка будет вечной...

[a-sure.livejournal.com]

Кто-то когда пернул, что для всех нужд хватит HTTP, что вместо туевой хучи портов\протоколов говноадминам придется настраивать только один. И понеслось говно по трубам:
- XML, ой, надо бы валидатор на входе
- ой, несекурно - SSL,
- ой - теперь хрен проверишь, валиадатор научим подглядывать
... ad libitum

Ну, а про построение stateful приложений на stateless HTTP даже вспоминать неохота.

Это очень проверенный подход - гнать новую модную волну, лучше несколько. "Дядя Вова Бутенко" из Communigate про это фиг знает когда написал: "бабки делаются на волне".

[plumqqz.livejournal.com]

Забейте, никому это нах не надо. Во-первых, есть HTTP/1.1 с keep-alive, во-вторых, в середине 90-х носились со всяким push-технологиями. И чо, где те технологии? Изобретаются заново.

[avr-forever.livejournal.com]

Понравилась цитата оттуда:

> Как известно в HTTP предусмотрено ограничение на число одновременных октрытых сессий к одному серверу.

Это песня просто!

[sergiej.livejournal.com]

Нормальное развитие, жизнь.
А для тех кто что-то в этом понимает (для нас с вами) это деньги-деньги-деньги.
Радоваться надо. Чем больше технологий и шаманства, тем ценнее шаманы.

[metaclass.livejournal.com]

Да, гугл реально спасает индустрию. Еще лет десять получать деньги за то, что знаешь с какой стороны к netstat и снифферу подойти.

[smalgin.livejournal.com]

Ссылка вообще малоинформативна. Целый абзац восхищения variable-length integer encoding, lol

[beliashou.livejournal.com]

Ребю belnetmon закрыл ссылки у себя в посте, поэтому отвечу тут: выше http только гипертекстовый фидонет!

[metaclass.livejournal.com]

Если повторное подключение будет делаться автоматически - это еще куда ни шло. А вот если его нужно будет явно обрабатывать разработчику - это будет ад.
В общем, если вся инфраструктура заточена под запрос-ответ и текстовое содержимое, а ее собираются переколбасить под постоянные соединения и непонятную бинарщину - там однозначно проблемы будут.