Частые опросы (polling)
Первое решение, которое приходит в голову для получения событий с сервера - это "поллинг" (polling), т.е периодический опрос сервера стандартными пакетами: "я тут, изменилось ли что-нибудь?"
В ответ сервер во-первых помечает у себя, что клиент онлайн, а во-вторых посылает датаграмму, в которой в специальном формате содержится весь пакет событий, накопившихся к данному моменту.
У этого способа есть одна большая проблема, а именно - большие задержки между созданием и получением данных. Сервер отсылает их не тогда, когда они появились, а когда настанет время очередного запроса.
Задержка = время между опросами + установление соединения + передача данных.
Другой минус - лишний входящий трафик на сервер. При каждом запросе браузер передает множество заголовков, причем заголовки
всегда идут в несжатом виде. Для некоторых приложений входящий трафик заголовков может в 10 и более раз превосходить исходящий трафик реальных данных.
- Задержки между событием и уведомлением
- Входящий трафик на сервер
- Простота реализации
В качестве транспорта можно использовать что угодно - от XMLHTTPRequest до тегов script. Пример не рассматриваем, и так все понятно 
|
Что же делать? Как сделать так чтобы при возникновения какого-либо события на сервере (например обновление данных) клиент узнал об этом и получил эти данные, не «пиная» постоянно сервер?
Никак, нужно спрашивать, обновились ли данные или нет.
В этом способе скрипт узнает именно через периодический запрос к серверу. Другие способы описаны в этом разделе
спасибо за статьи по push, сейчас разрабатываю тему
тока нагрузка всё равно неслабая на каналы.
так что используем HTML5 sockets
Да сложного в принципе особо ничего нет.
Вижу аж три решения.
1 - старт скрипта по крону
2 - при любом "движении" любого пользователя по сайту (получаем работу PHP-скрипта) заставляем этот скрипт выполнять нужную проверку и флагами по времени последнего обновления отсеиваем лишнее срабатывание скрипта. Если пользователей достаточное количество, то этого способа вполне достаточно и нагрузка на сервер не очень боьшая, потому как все равно обслуживается какой-то пользователь.
3 - а что мешает событию, которое произвело какие-то изменения уведомлять об этом?
да все просто, но нужен хттп сервер который бы очень долго держал открытое соединение. если соединение открыто то клиент жив. На стороне клиента открывается постоянный запрос какого нибудь хтмл документа, сервер отправляет хидеры но конект не закрывает, если возникает какое-то событие то отправляется кусок джаваскрипта с командой клиенту. для того чтоб отправить данные серверу то клиент закрывает текущее соединение и открывает новое в котором постом или гетом передается необходимая команда и ожидается ответ от сервера до след события. есть конечно свои тонкости)))
Посмотрите в сторону socket.io, тут как раз открывается "туннель" на все время сессии клиента.
Обычно, когда функция возвращает Deferred, т.е "обещание результата в некоторый момент", программист затем цепляет к нему обработчики результата, которые будут вызваны в той же последовательности, через addCallback/addErrback/granny 2.0