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

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

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

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

http://en.wikipedia.org/wiki/Comet_(programming)

например witty такое умеет

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

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

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

http://en.wikipedia.org/wiki/Comet_(programming)

По описанию именно это я и искал, но не знал как называется. Спасибо.

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

Поувивав бы.

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

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

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

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

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

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

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

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

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

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

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

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

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

http://pushmodule.slact.net

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

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

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

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

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

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

facepalm.svg

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

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

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

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

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

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

омг, ну и костыли в теме. вот раз и два. всё.

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

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

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

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

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

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

вам шашечки или ехать?

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

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

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

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

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