Форум PHP

Здравствуйте

интересует технология создания чатов

все решения которые нашел в интернете сводятся к тому что клиент посылает постоянные запросы на сервер и если есть новые сообщения то они ему подгружаются в ДОМ

если ли такие решения чтобы клиент постоянно не делал запросы а как только есть новое сообщение то сервер сам отправлял клиенту информацию?

нету(
по крайней мере не HTTP

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

sleep()
___
только чем Вам не нравиться запрос каждую секунду? это гораздо выгоднее с точки зрения экономии ресурсов сервера

Отнюдь. Это тормоза и огромное количество запросов. Если использовать Comet запрос будет один и держаться он будет довольно долго. Все это время он будет работать. Скорость будет поразительная, так как нет накладных расходов на установку соединения, обработку запроса сервером. Если серверный скрипт выполняется как CGI, а не как модуль сервера, то сам запуск этого скрипта уже будет жрать тучу ресурсов и времени. Скажем, если у меня картинка отдается с сервера CGI-скриптом на Perl, то каждый раз при запросе этой картинки у меня будет запускаться интерпретатор Perl.

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

Можно спросить об этом самого хостера. Имхо, применение комет на простом хостинге вообще не очень правильная затея. Но, кстати, есть подозрение, что хостер лучше пожертвует 1% оперативки на перманентную загрузку, чем будет обрабатывать 2000 запросов в секунду (клиент-то не один), причем в холостую. ну и опять же, если это CGI - на запуск интерпретатора потребуется больше оперативки, чем на поддержание его работы. Получится всплескообразная нагрузка с эффектом DDOS. А при лонг-полинг будет просто перманентная низкая нагрузка.

что Вы к этому это CGI докопались? еще остались такие хостеры?
1% оперативки это Вы каким это фигом прикинули? 2000 копий скрипта = 1%? где Вы видели чат в котором сидят 2000 человек??? пусть даже с вашим Кометом а ну как 2000 человек отправят сообщение одномоментно? катаклизм?
еще раз повторяю, я НЕ ПРОТИВ постоянных соединений и в частности Комета, но это уже далеко не обычный http
цитата из вики..
Благодаря comet-приложениям клиент в режиме реального времени может взаимодействовать с сервером, опираясь на постоянное (или там, где не представляется возможным, длительное (long polling)) соединение HTTP. Поскольку браузеры и веб-серверы работают по протоколу HTTP, который на подобные соединения не рассчитан, разработчики используют различные реализации. Каждая из них имеет свои достоинства и недостатки.
___
кстати идея Dklab Realplexor - это практически то же самое как я описал чуть выше
дклаб:
Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени
я:
а вторая отвечает на запрос конкретного клиента и сводиться исключительно к выводу заранее подготовленной информации

А почему вы решили что висит 2000 копий серверного скрипта? 0_о

потому что каждый запрос создает копию скрипта обработчика

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

Вы походу совсем меня не слышите....
читайте внимательнее Дмитрия
__
складывается впечатление что Ваш аккаунт выкрал sim5, только с ним можно было спорить говоря об одном и том же

Есть технологии. Long polling, Comet.

Вот можно почитать. Там же увидите и пример и вообще все.

Суть в том, что открывается соединение и не закрывается, а периодические проверки происходят на сервере. Если на сервере что-то происходит - он отсылает данные в открытое соединение с клиентом. Клиенту нужно только следить чтобы соединение всегда было установлено.

Есть еще перспективная технология NodeJS. Это серверный JavaScript. Как и клиентский, он событийно-ориентирован и асинхронен. Тоже позволяет делать системы реального времени.

http://softtime.ru/forum/read.php?id_forum=4&id_theme=81198&page=1
Вот эта тема вас заинтересует.

upd: упс, меня опередили)