drdim Jun 27 2011 at 05:23

Реализация HTTP server push с помощью Server-Sent Events

4 min

17K

JavaScript*

From sandbox

+45

Comments 26

KhanTengri Jun 27 2011 at 06:56

Нет, ну насчет лучшей поддержки чем WebSockets, это вы конечно загнули…
WebSockets + gimite и будет работать практически везде, здесь и сейчас…
Ну это ладно, у меня вот такой вопрос к Вам, пользуясь случаем, так сказать…
Вот основное достоинство что WebSockets, что SSE — это то, что по сети не гоняются безудержно запросы проверяющие есть ли новые данные на серваке или нет, как ранее было с ajax, например… Но есть такая проблема: у меня приложение написано с использованием WebSockets и если пользователь просто закрывает ноутбук и ось засыпает, то сервак по-прежнему думает, что пользователь online. js-событие onlose в данном случае не срабатывает. Вот никак не могу решить эту проблему, без возвращения к методологии ajax с постоянным «пингом». Решается ли эта проблема как-то в SSE?

ЗЫЖ Вопрос может быть и глупый, но без решения этой проблемы что WebSockets, что SSE в реальных проектах мало чем будут отличаться от того же самого чата на ajax

chEbba Jun 27 2011 at 07:08

Если ноут засыпает, разве соединения не рвутся?

KhanTengri Jun 27 2011 at 07:12

нет, не рвутся…

glib Jun 27 2011 at 07:42

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

KhanTengri для такого решения, следует поискать реализацию (или самому написать), которая будет посылать пинг во время «слушанья» канала. всё будет так же как раньше с аякс пингом, только тут будет пинг всего один байт, потому что не надо передавать кучу заголовков что приблизительно от 200байт каждый раз.

Zaharov Jun 27 2011 at 08:25

А зачем пинг делать аякосвым? Почему бы не сделать что бы клиент периодически слал сигналы «Я на связи!» через тот же самый сокет?

glib Jun 27 2011 at 09:06

Ну а я что про 1 байт говорил? :)

Zaharov Jun 27 2011 at 10:48

Последствия беглого прочтения, я почему-то подумал что вы хотите посылать пинги средствами аякса. :)

shinyweb Jun 27 2011 at 08:17

Возможно проблема в вашей сетевой карте и/или настройках BIOS для нее (тот же Wake-On-LAN например).

lega Jun 27 2011 at 08:47

Я сделал таймаут на стороне сервера — если данных нет, сервер через какое-то время отдает пустой ответ, после чего если клиент ещё на связи, он подключается заново. Для маленьких нагрузок нормально.

+ можно ещё сделать, если клиент уходит со страницы (что чаще всего бывает) — послать параллельно запрос о закрытии «висячего» соединения.

glib Jun 27 2011 at 09:07

при таймауте — почти тот же самый аякс-пинг

Zaharov Jun 27 2011 at 07:29

Всё-таки WebSocket, на мой взгляд, более перспективный и интересный механизм чем SSE.
Случаем никто не знает продвигается ли исправление уязвимости с прокси-серверами? Т.е. иначе говоря когда примерно стоит ждать возвращения WebSocket в Оперу и ФФ?

KhanTengri Jun 27 2011 at 07:31

В FF6 будет уже. Опера — хз
proof

Fesor Jun 27 2011 at 09:05

Опера поддерживает их уже сейчас. Просто по умолчанию они отключены. В настройках легко включается.

KhanTengri Jun 27 2011 at 09:10

Вы попробуйте это пользователю обьясните…
И в FF они вроде бы тоже включаются таким же макаром, как и в Opera… да только юзер всего этого делать не будет.

SailorMax Jun 27 2011 at 08:02

http://dev.w3.org/html5/websockets/ — Editor's Draft 21 June 2011
когда определятся с реализацией, тогда и ждите. А ежели охото работать на сыром под Opera хоть сейчас: opera:config#UserPrefs|EnableWebSockets

NikoB Jun 27 2011 at 10:59

А при какой нагрузке сайт ляжет? Сколько онлайн посетителей?

azproduction Jun 27 2011 at 20:47

В лучшем случае перестанет отвечать когда закончатся порты, более вероятно что упремся в процессор, маловероятно, что упремся в канал. При такой реализации: «вычислять 1 раз, использовать Node.js Buffer и слать мультикастом» шанс лучшего случая многократно возрастает.
Для сферической в вакууме задачи конкретные цифры сказать невозможно :)

grigoryvp Jun 27 2011 at 11:22

Подскажите человеку, не очень хорошо разбирающемуся в ajax-тренде. Если асинхронные сообщения от сервера получать через Server Side Events, то как по феншую отправлять асинхронные сообщения на сервер? XMLHttpRequest()? Или есть какие-то более корректные способы, чтобы не плодить TCP подключений и не ждать ответов, так как они приходят асинхронно по SSE?

azproduction Jun 27 2011 at 20:52

К клиенту — SSE, от клиента — XHR (всреднем 2 подключения). Более экономный способ — WebSockets (1 подключение)

el777 Jun 27 2011 at 13:31

На мой личный взгляд Server-Sent Events — это попытка отполировать и узаконить хак под названием Comet. Но это не лучшее решение — потому что оно принципиально не приспособлено для создания интерактивных приложений. Полноценную интерактивность может дать только полностью симметричный асинхронный канал. Поэтому надо менять сам принцип работы. Это реализовано в WebSockets.
Все проблемы которые решает SSE полностью решены WebSockets`ами, причем более элегантно и эффективно.

el777 Jun 27 2011 at 13:32

Я про этом писал полтора года назад — habrahabr.ru/blogs/webdev/79038/

MarcusAurelius Jun 27 2011 at 15:29

Полностью согласен, сам использую LongPolling и SSE только от отсутствия нормальной альтернативы, ждем WebSockets. Десктопные приложения на всех серьезных языках имели возможности делать полноценные интерактивные приложения в режиме полной двунаправленной асинхронности в два направления еще 15 лет назад. Конечно все готовые RPC типа DCOM и CORBA, были не оправдано сложными и глючными. Но всегда можно было спуститься к TCP/IP и сделать все просто и лаконично. Сейчас, в век веб-интерфейсов все уже как-то подзабыли про это, мы очень долго уже ждем появления нормальной связи. Главная проблема — это безопасность. Если сайты смогут пользоваться сокетами без дополнительных пермишенов, то сразу появятся ботнеты, превращающие компы большого кол-ва людей в сканировщики сетей, плацдармы для дос-атак, прокси-анонимайзеры для хакеров и кравлеры для сливания контента с порталов с диверсификацией IP-адресов. Без решения проблем безопасности нормальная связь не появится. Кто-то в курсе, есть ли уже подходы к решению этой проблемы?

el777 Jun 27 2011 at 19:31

Подходы есть.
Последния изменения в Websockets во многом направлены на улучшение безопасности. Но даже в самых первых ревизиях уже было заложено, что коннектиться можно не абы куда, только туда, куда разрешит сервер. Поначалу кажется, что это ухудшает безопасность по сравнению в моделью «same origin», использованной в XHR. Но реально, это не добавляет новых дыр, но дает новые возможности. Хотите сделать DDoS-aтаку, пожалуйста — вставьте в html страницы картинку с нужного хоста. Хотите просканировать порты — укажите их и сканируйте, кто мешает. В частности, один ~~гомо~~ресурс уже использовал это для ддос-аттаки.

AlexTikhonov Jun 27 2011 at 14:33

(немного оффтоп, но тем кому интересен субж может пригодится)
Недавно мне скинули ссылку на очень интересную либу — Now.JS

Выглядит очень симпотяшно. Использует socket.io на сервере.

azproduction Jun 27 2011 at 20:31

Похожий принцип был у XAJAX (PHP-JavaScript мост), но библиотека как-то не прижилась. Создание прозрачной границы между клиентом и сервером это интересное решение. PHP-JavaScript — не очень оправдано, а вот JavaScript-JavaScript интересный вариант, тем более, что Now.JS выглядит привлекательнее чем XAJAX ;)

drdim Jun 29 2011 at 06:46

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

Show the best of all time