LINUX.ORG.RU

Web асинхронное уведомление клиента


0

1

Доброго времени суток!

Хотелось бы реализовать механизм событий с использованием протокола Http. Механизм событий подразумевает асинхронное уведомление клиента о возникновении каких-либо событий и пересылка связанных с событием данных.

В промышленных протоколах обычно реализуется так: клиент держит с сервером постоянное соединение. В нужный момент сервер посылает клиенту пакет с событием.

При использовании Http соединение устанавливается, а когда страница отдана разрывается.

Есть вариант послать асинхронно запрос Ajax, а ответ с сервера «придержать» до наступления события. Но тут вопрос не порвет ли браузер соединение, если ответа не будет долго? Можно сделать timeout и еще раз посылать запрос конечно.

Есть новомодный Web сокет, но он плохо поддерживается браузерами, поэтому не подходит.

Все это нужно для быстрого отображения изменения информации в Web интерфейсе без использования всяких плагинов (Java, Flash) и др.


★★

Можно спрашивать сервер время от времени: «а нет ли события?» Но это костыль.

adepto ()

> Можно сделать timeout и еще раз посылать запрос конечно.

Я бы сделал так.

Terrens ()
Ответ на: комментарий от Terrens

Можно сделать timeout и еще раз посылать запрос конечно.


Я бы сделал так.


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

olegk ★★ ()

В промышленных протоколах обычно реализуется так: клиент держит с сервером постоянное соединение

Поувивав бы.

К счастью я такую ерунду вырезаю с корнем.

r_asian ★☆☆ ()
Ответ на: комментарий от r_asian

В чём минусы такого подхода? (Я нуб, мне правда не всё понятно даже после листания вики)

Ну, кроме того, что, может быть, траффик набегает.

Terrens ()
Ответ на: комментарий от r_asian

а если у приложения требующая таких ухищрений бизнес-логика? неужели сохранять состояние сессии (объекты из оперативы в бд например) и потом обратно ее восстанавливать?

anonymous ()
Ответ на: комментарий от Terrens

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

Terrens ()
Ответ на: комментарий от Terrens

там скорее всего будет проблема с одновременный доступом к общим ресурсам. есть мнение что ее можно эффективно решить erlang'ом

anonymous ()
Ответ на: комментарий от anonymous

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

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

r_asian ★☆☆ ()

Открываем http соединение через яваскрипт, вешаем на завершение (все равно, удачно или нет) обработчик, в нем повторяем это. Если получили ошибку, можно увеличивать время повтора экспоненциально до какого-то предела.
В обработчике входящих данных от запроса парсим пакеты с событиями. Если события важные - отправляем на сервер каким-либо образом подтверждение доставки.

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

Для управления всем этим на сервере есть разные инструменты (в Nodejs, в яве - servlet 3.0, grizzly, для c++ наверняка тоже есть)

note173 ★★★★★ ()
Ответ на: комментарий от r_asian

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

Ну и что вы можете предложить взамен? Только чтобы хватало только браузера, и было кроссплатформенно.

anonymous ()

Кроме comet есть еще WebSocket. Если браузер не поддерживает, то вроде как есть эмулятор на Flash

dizza ★★★★★ ()
Ответ на: комментарий от r_asian

>Когда для успешной работы приложения требуется ущественно расширить используемую технологию, то, скорее всего, вам нужна другая технология.

И я тоже так думаю!
Но все сидим на HTML+CSS+Javascript.

proud_anon ★★★★★ ()

Пока до полноценной поддержки веб-сокетов доживем - состаримся :)))

Можно еще погуглить на предмет ajax long polling, на сервере я вешал phpDaemon, всяко лучше, чем node.js =)))

boombick ★★★★★ ()

facepalm.svg

то что ты хочешь противоречит идее http и реализуется костылем

нужное ключевое слово: паттерн comet и reverse ajax

хорошее проверенное решение - использовать в качестве сервера Jetty и писать код использованием Jetty Continuations

(а также обратить внимание на спецификацию Servlet-3.0 где это проходит стандартным методом под названием Suspendable Requests)

stevejobs ★★★★☆ ()
Ответ на: комментарий от boombick

> А, про comet уже сказали)) Пропустил

я тоже тред не читал )))

stevejobs ★★★★☆ ()
Ответ на: комментарий от iSlava

Это же на флеше! А по-человечески: либо вебсокеты, либо постоянное «дергание» сервера.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

вы в Supported transports заглядывали хоть?

либо постоянное «дергание» сервера.

я посмотрю на ваш сервер, которого вот так будут опрашивать, к примеру, по 5к клиентов каждые n секунд (подсказка: мягко говоря это будет не эффективно)

iSlava ()
Ответ на: комментарий от iSlava

я посмотрю на ваш сервер, которого вот так будут опрашивать, к примеру, по 5к клиентов каждые n секунд

Гугл с этим отлично справляется (вся эта «интерактивность» у гугла обеспечивается как раз периодическими http-опросами клиентом сервера).

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от iSlava

Мне - для самообразования :)

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от iSlava

я посмотрю на ваш сервер, которого вот так будут опрашивать, к примеру, по 5к клиентов каждые n секунд (подсказка: мягко говоря это будет не эффективно)

А в чем проблема? Делаете на non-blocking либе, 5к влегкую выдержит. Для питона, например Tornado, для java - Netty ну и т.д.

Потом на nginx нужно будет урл для поллинга проксировать на неблокирующий бекенд. Между неболокирующим бекендом и основным приложением еще нужно IPC организовать. Можно взять RabbitMQ как вариант.

dizza ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.