-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Возможно ли написать скрипт "досылающий" данные в браузер без закрытия соединения?
- Автор темы alekciy
- Дата начала
alekciy
Новичок
AJAX я хорошо знаю ( http://www.ixbt.com/soft/ajax.shtml 
). И он безусловно будет использоваться. Но. Мне нужен поток со стороны сервера. Вот и интерисуюсь, возможно ли такое на PHP.
). И он безусловно будет использоваться. Но. Мне нужен поток со стороны сервера. Вот и интерисуюсь, возможно ли такое на PHP.
Страшный Злодей
Бывший член клуба (достало хамство).
alekciy
Теоритически можно http://aboutweb2.spb.ru/ajax-shablonyi-proektirovaniya/web-remoting/http-streaming/, но тогда нужно либо не останавливать скрипт на сервере, либо мудрить с настройками самого сервера, чтобы он по окончании работы скрипта не закрывал соединение, и тогда запускать скрипт по расписанию или событию, чтобы тот в свою очередь "досылал" нужную инфу.
Теоритически можно http://aboutweb2.spb.ru/ajax-shablonyi-proektirovaniya/web-remoting/http-streaming/, но тогда нужно либо не останавливать скрипт на сервере, либо мудрить с настройками самого сервера, чтобы он по окончании работы скрипта не закрывал соединение, и тогда запускать скрипт по расписанию или событию, чтобы тот в свою очередь "досылал" нужную инфу.
alekciy
Новичок
Страшный Злодей
Это я уже читал. Самое смашное, что именно эта статья послужила причиной создания темы. Точнее исходя из ней я узнал, что то, что мне было нужно назвается HTTP Streaming-ом и возник вопрос возможно ли это реализовать на PHP.
dimagolov
Ну самый напрашивающий ответ - для чата. Хотя планируются более широкие задачи.
Я конечно понимаю, что с помощью флеша можно очень неплохо реализовать потоковое соединение. В этом отношении мне очень нравяться идеи заложенные во флексе, хотя поюзал я его пока еще мало. Но есть ведь куча пользователей у которых флеша нет (как например я). Поэтому хочется при приблизительно том же функционале реализовать задачу на связке HTML+JS+PHP. Понятное дело, что можно на сервере для того же чата замутиться с Java. Но хотется ограничется возможностями предоставляемыми стандартными хостингами. Ибо ява это уже совсем другие деньги.
На данным момент наиболее рельный вариант мне видиться в скрытом iframe с последующим анализом полученных данных JS движком или тоже самое через AJAX. Но тут минус в том, что обновление страницы идет в четко заданные промежутки вне зависимости от того, нужно это реально или нет. При слишком мало интервале опроса сервера клиентами сервер просто не отвечает на запросы считая это атакой, а при слишком большем получается очень тормозная система. Пользователь производить некое действие раз в 2 сек, опрос сервера идет раз в 5 сек. Получаем 3 сек "холостого хода". Если действия пользователя ждут другие пользователи, то общие тормоза от кадого пользователя получаются приличными.
Wicked
Спасибо. Английский... на чтение уйдет некоторое время, но на вскидку не очень улавливаю как это может помочь мне в данной задаче.
Это я уже читал. Самое смашное, что именно эта статья послужила причиной создания темы. Точнее исходя из ней я узнал, что то, что мне было нужно назвается HTTP Streaming-ом и возник вопрос возможно ли это реализовать на PHP.
dimagolov
Ну самый напрашивающий ответ - для чата. Хотя планируются более широкие задачи.
Я конечно понимаю, что с помощью флеша можно очень неплохо реализовать потоковое соединение. В этом отношении мне очень нравяться идеи заложенные во флексе, хотя поюзал я его пока еще мало. Но есть ведь куча пользователей у которых флеша нет (как например я). Поэтому хочется при приблизительно том же функционале реализовать задачу на связке HTML+JS+PHP. Понятное дело, что можно на сервере для того же чата замутиться с Java. Но хотется ограничется возможностями предоставляемыми стандартными хостингами. Ибо ява это уже совсем другие деньги.
На данным момент наиболее рельный вариант мне видиться в скрытом iframe с последующим анализом полученных данных JS движком или тоже самое через AJAX. Но тут минус в том, что обновление страницы идет в четко заданные промежутки вне зависимости от того, нужно это реально или нет. При слишком мало интервале опроса сервера клиентами сервер просто не отвечает на запросы считая это атакой, а при слишком большем получается очень тормозная система. Пользователь производить некое действие раз в 2 сек, опрос сервера идет раз в 5 сек. Получаем 3 сек "холостого хода". Если действия пользователя ждут другие пользователи, то общие тормоза от кадого пользователя получаются приличными.
Wicked
Спасибо. Английский... на чтение уйдет некоторое время, но на вскидку не очень улавливаю как это может помочь мне в данной задаче.
Апокалипсис
тех дир matras.ru
alekciy
ммм какова предположительная посещаемость проекта? Всмысле какое кол-во народу может быть "онлайн" в чате ?
ммм какова предположительная посещаемость проекта? Всмысле какое кол-во народу может быть "онлайн" в чате ?
MiksIr
miksir@home:~$
Стриминг возможен. Самый простой вариант - на каждого юзера вешать процесс. Минусы понятны, плюсы - простота. Самый правильный вариант - мультиплексирующий сервер на С с приемом команд от логики через внутренние сокеты. В качестве понимания принципов работы можно написать мультиплексор на PHP - примеры можно найти в коментах на php.net и тут поднималась эта тема - поищите.
Но надо понимать, что подобная технология сильно зависит от качества связи клиент-сервер, и выводить стриминг прямо клиенту не очень удобно - кнопочка "стоп" браузера или проблемы со связью прервут поток. Есть еще один косяк для чата, на который я натыкался - так как порции данных там идут маленькие, то любой промежуточный кеш портит гладкость сообщений, а такими кешами становятся анвирирусы, проверяющие веб на вредоносные скрипты. Наверно, как-то можно бороться - не изучал.
А вообще такие чаты - не новость, что-то подобное было писано на перле ээ... лет 11 назад.
Но надо понимать, что подобная технология сильно зависит от качества связи клиент-сервер, и выводить стриминг прямо клиенту не очень удобно - кнопочка "стоп" браузера или проблемы со связью прервут поток. Есть еще один косяк для чата, на который я натыкался - так как порции данных там идут маленькие, то любой промежуточный кеш портит гладкость сообщений, а такими кешами становятся анвирирусы, проверяющие веб на вредоносные скрипты. Наверно, как-то можно бороться - не изучал.
А вообще такие чаты - не новость, что-то подобное было писано на перле ээ... лет 11 назад.
alekciy
Новичок
Krishna
А тут поподробнее не получиться к сожалению (( . Я пересекался раз с одним человеком, он делал для одной конторы связку: на клиентах AJAX, на сервере Java программа работающая с клиетами. Клиент через AJAX по таймеру пинает сервер, тот отвечает ему данными, но соединение не отбрывает. Если появляются новые данные то он их досылает клинету. И так до тех пор пока на клиенте не наступает таймаут и браузер не прибевает AJAX. Соединени разрывается. Но таймер на клиенте создает новое соединение по AJAX и схема повторяется.
Проект был закрытый и платный. О получении исходников и речи быть не могло. Попросить хотя бы приватно с обещанием неразглашения ни как было нельзя ибо человека я знал не на столько близко, что бы он пошел на такое. Но основание не верить ему у меня нет. Вполне компетентный прогер.
Соственно с тех пор и не успокоюсь. Да и за примера ходить далеко не нужно. chat.chat.ru яркий образчик такого неразрывного соединения. Хоть и на фреймах.
Апокалипсис
Сколько возможно больше. Хотя первых несколько месяцев их количество врятли будет больше 20-30 человек одновременно. На крайний случай можно просто отказывать во входе пользователям при некоем лимите одновременных подключений.
AmdY
Да, о сотнях пользователей даже мысли нет думат да и врятли столько будет.
-~{}~ 16.09.07 02:23:
А тут поподробнее не получиться к сожалению (( . Я пересекался раз с одним человеком, он делал для одной конторы связку: на клиентах AJAX, на сервере Java программа работающая с клиетами. Клиент через AJAX по таймеру пинает сервер, тот отвечает ему данными, но соединение не отбрывает. Если появляются новые данные то он их досылает клинету. И так до тех пор пока на клиенте не наступает таймаут и браузер не прибевает AJAX. Соединени разрывается. Но таймер на клиенте создает новое соединение по AJAX и схема повторяется.
Проект был закрытый и платный. О получении исходников и речи быть не могло. Попросить хотя бы приватно с обещанием неразглашения ни как было нельзя ибо человека я знал не на столько близко, что бы он пошел на такое. Но основание не верить ему у меня нет. Вполне компетентный прогер.
Соственно с тех пор и не успокоюсь. Да и за примера ходить далеко не нужно. chat.chat.ru яркий образчик такого неразрывного соединения. Хоть и на фреймах.
Апокалипсис
Сколько возможно больше. Хотя первых несколько месяцев их количество врятли будет больше 20-30 человек одновременно. На крайний случай можно просто отказывать во входе пользователям при некоем лимите одновременных подключений.
AmdY
Да, о сотнях пользователей даже мысли нет думат да и врятли столько будет.
-~{}~ 16.09.07 02:23:
Перл то перл, но возник вопрос возможности подобной реализации именно на PHP.
alekciy
Новичок
HraKK
>То есть, идет тот же простой.
Да, на период перезапуска таймера да. Но до наступления таймаута на клиенте проходит обычно около 2 минут. Потом можно секунд 5 и подождать. А потом снова пересылка данных в реальном практически времени. Поэтому по сравнению с чисто таймерным вариантом плюсы есть.
>Я не вижу плюсов кроме выделения памяти на каждое
>соединение + сложности.
Плюсы есть. Одно дело таймер пинающий сервер каждый 5 сек и другое дело соединение данный по которому гоняться в момент наступления события. Если пользователь совершает некое действие за 1-2 сек, то ему не приходится ждать еще 4-3 сек пока таймер не пинет сервер.
Когда таких действий не много, то в принципе можно и подождать. Но если их уже больше десятка, то то, что при стрименге заняло бы ~20 сек, и при 5-ом пинании минуту и больше.
>Если интересно могу закинуть чат что я делал за 2 дня.
Чисто связка HTML+JS+PHP? Собственно код я и сам могу написать, но меня больше интерисует практическая сторона. Т.е. связка прошедшая опробацию в реальным условиях. И интерисует: время реакции системы (интервал таймера фактически), количество онлайн пользователей, не возникают ли проблемы с записью в БД (СУБД? текстовые файлы?), ведь операцию записи могут инициировать несколько пользователей с очень малой разницей во времени. Не возникают ли при этом рассогласования того, что видят пользователи (т.е. не теряются ли сообщения для части пользователей?
>То есть, идет тот же простой.
Да, на период перезапуска таймера да. Но до наступления таймаута на клиенте проходит обычно около 2 минут. Потом можно секунд 5 и подождать. А потом снова пересылка данных в реальном практически времени. Поэтому по сравнению с чисто таймерным вариантом плюсы есть.
>Я не вижу плюсов кроме выделения памяти на каждое
>соединение + сложности.
Плюсы есть. Одно дело таймер пинающий сервер каждый 5 сек и другое дело соединение данный по которому гоняться в момент наступления события. Если пользователь совершает некое действие за 1-2 сек, то ему не приходится ждать еще 4-3 сек пока таймер не пинет сервер.
Когда таких действий не много, то в принципе можно и подождать. Но если их уже больше десятка, то то, что при стрименге заняло бы ~20 сек, и при 5-ом пинании минуту и больше.
>Если интересно могу закинуть чат что я делал за 2 дня.
Чисто связка HTML+JS+PHP? Собственно код я и сам могу написать, но меня больше интерисует практическая сторона. Т.е. связка прошедшая опробацию в реальным условиях. И интерисует: время реакции системы (интервал таймера фактически), количество онлайн пользователей, не возникают ли проблемы с записью в БД (СУБД? текстовые файлы?), ведь операцию записи могут инициировать несколько пользователей с очень малой разницей во времени. Не возникают ли при этом рассогласования того, что видят пользователи (т.е. не теряются ли сообщения для части пользователей?
alekciy
Новичок
HraKK
На клиенте ни в чем. Как серверную часть заставить послать порцию данных, но соединение на закрыть? При появлении новых данных тут же заслать в отрытое соединение еще данные. Как это сделать скриптом на PHP? Вообще возможно ли это? Игрался к буферизацией вывода, но все не то ((
На клиенте ни в чем. Как серверную часть заставить послать порцию данных, но соединение на закрыть? При появлении новых данных тут же заслать в отрытое соединение еще данные. Как это сделать скриптом на PHP? Вообще возможно ли это? Игрался к буферизацией вывода, но все не то ((
alekciy
Новичок
HraKK
flush это который описан в CXII. Output Control Functions вмане? Может я плохо понимаю принцип работы буфера, но получить желаемого я не смог. Я думал по ob_flush PHP пошел в браузер данные, браузер их отобразит, а скрипт пока будет отрабатывать логику дальше. Например коннектиться к БД и запрошивать данные.
Но не желает либо браузер, либо скрипт работать по какой схеме.
flush это который описан в CXII. Output Control Functions вмане? Может я плохо понимаю принцип работы буфера, но получить желаемого я не смог. Я думал по ob_flush PHP пошел в браузер данные, браузер их отобразит, а скрипт пока будет отрабатывать логику дальше. Например коннектиться к БД и запрошивать данные.
Но не желает либо браузер, либо скрипт работать по какой схеме.
alekciy
Новичок
HraKK
flush это который описан в CXII. Output Control Functions вмане? Может я плохо понимаю принцип работы буфера, но получить желаемого я не смог. Я думал по ob_flush PHP пошел в браузер данные, браузер их отобразит, а скрипт пока будет отрабатывать логику дальше. Например коннектиться к БД и запрошивать данные.
Но не желает либо браузер, либо скрипт работать по какой схеме.
flush это который описан в CXII. Output Control Functions вмане? Может я плохо понимаю принцип работы буфера, но получить желаемого я не смог. Я думал по ob_flush PHP пошел в браузер данные, браузер их отобразит, а скрипт пока будет отрабатывать логику дальше. Например коннектиться к БД и запрошивать данные.
Но не желает либо браузер, либо скрипт работать по какой схеме.