Читается, как детектив. Правда, дешевый. Один товарисч боится jQuery, другой дрожит над лишним пуком в базу, третий вообще в пхп не очень, зато С++ знает Padaboo дал нормальный правильный ответ. Возможно даже найдете хостинг, который даст прибиндица к какому-нибудь порту. Или VPS. В принципе можно взять за основу и С/С++, только, конечно, не самому писать... брать готовые решения на базе nginx или lighttpd например. Много информации можно получить в гугле по запросу comet serever.
фаллометрию не приветствую. Я дал объяснение, как можно взаимодействовать на любом сервере, независимо от того, дают вам порт или нет. Я уже давал ссылку на хабр, где упоминается работа с Comet
И независимо от того, какие установлены лимиты на CPU time? =) А скажите, какое принципиальное различие между вашим демоном и, к примеру, MYSQL?
Когда подрастешь профессионально, тады и пообщаемся. Не боись, это не позорно, в 95-м, когда я только начинал программить, я тоже на файлах все делал
Если вы затрудняетесь написать приложение, работающее с сокетами на С++, которое даёт почти нулевую нагрузку на проц, то мне нечего вам ответить. Кроме того, если стоит лимит на время выполнения cgi, то большой проблемы я тоже не вижу, поскольку я предложил каскадную модель. Демон запускается по запросу Initor'а, если он еже не был запущен. Если и закрылся демон, то при следующем запросе он поднимется снова. Настоящий демон отвязан от каналов ввода/вывода
Внимательнее почитал этого чувака. Слишком у него альтернативное мышление, это не совсем comet. Хотя его способ и позволяет решить некоторые проблемы реального потока, в частности застревание сообщений в буферах всяких антивирусов. Только рождать по процессу на каждого клиента - это убийство. Так что опять отправдяю к ответам Padaboo.
Он поддерживает в рабочем состоянии канал от браузера пользователя до сервера. Получает от пользователя сообщения и форсит со своей стороны новые сообщения пользователю. имхо, ничего необычного.
Самое обидное, что я не могу сказать "В интернете всё есть", потому как уже убеждался в спорах с вами, MiksIr, что вы скажете, что у меня не достаточно аргументов, до тех пор, пока я все их вам не выложу (включая всё самое очевидное). http://dev.w3.org/html5/websockets/ - Здесь описано, в каком формате должно быть произведено подключение от сервера к браузеру. http://www.perlfect.com/articles/cgi_env.shtml - Взаимодействие между импровизированным демоном и Initor CGI
Приходит запрос на вебсервер, онный стартует CGI скрипт. Опишите процедуру передачи соединения в этот демон - он ведь должен держать это соединение открытым, а CGI скрипт умереть - я правильно понял?
да, initor cgi отмирает вместе с php скриптом, а демон остается. способ передачи параметров в демон по аналогии с передачей параметров через php к стандартному websocket-серверу: http://habrahabr.ru/blogs/webdev/82140/ по большому счёту я не предлагал писать новый websocket-сервер. я просто объяснил, как сделать так, чтобы каналы не разрушались после выработки php-скрипта. не нужно пытаться уличить меня в недостатке квалификации, потому как это, во-первых, неприятно. а во-вторых, это можно сделать с каждым. с вами в том числе.
По вашей ссылке обычный мультиплексирующий демон, который сидит на своем порту и принимает запросы. Я о том и спрашивал, как вы представляете без дополнительных портов это делать. Более того, я даже представляю, как эту вашу схему реализовать... и в принципе даже этот самый "Initor CGI" можно оставить живущим и работающим как прокси между веб-сервером и демоном, только вот демон в этом случае и не особо нужен - этому CGI достаточно открыть unix socket и принимать сообщения от кого угодно, от любого скрипта, который будет рассылать сообщения. В общем, приблизительно по этому принципу был написан чат в 96-м году. На перле, правда. Правда, построив такую "красивую" (костыль на костыле) схему на хостинге (а все это ради хостинга, ага), выяснится, что веб сервер по таймауту будет рвать соединение. Ну это самая первая проблема "в лоб". А таких проблем еще вылезет куча. Так что не для хостинга это все.
с другой стороны, если запускать cgi напрямую через php, то скрипт будет ожидать отклик о выполнении от cgi. это первое. т.е. в любом случае такой подход неправильный. второе, при запуске из php создается новый cgi-процесс, т.е. нельзя получить доступ к старым сокетам без hook'ов, поскольку сокет уже разрушился или принадлежит другому экземпляру cgi. потому я предложил каскадный вызов. initor погиб, демон живёт, php корректно отработал своё. все счастливы. к вопросу о портах. сокет вообще не может быть открыт, если для него нет порта
> initor погиб, демон живёт, php корректно отработал своё Все-равно них не понял. У нас есть веб-сервер, который устанавливает соединение с клиентом. После этого он запускает cgi и форвардит ответы клиенту. Да, cgi может связаться с демоном, но как только cgi помрет - вся цепочка рухнет. Демон то жить будет, только никакого "соединения" у него не будет. В чем смысл этих странных схем я так и не понял. С таким же успехом можно из php коннектица к демону. > к вопросу о портах. сокет вообще не может быть открыт, если для него нет порта ну, если уж "к вопросу", то есть unix-socket, ну и разговор вообще не об этом, а о том, как не использовать дополнительные порты, а обойтись 80-м, который слушает веб-сервер хостера.
> ну, если уж "к вопросу", то есть unix-socket, не было разговора о том, какой именно порт. говорилось о том, что нужен порт. если он есть, то его можно юзать. > Все-равно них не понял. > У нас есть веб-сервер, который устанавливает соединение с клиентом. После этого он запускает cgi и форвардит ответы клиенту. Да, cgi > может связаться с демоном, но как только cgi помрет - вся цепочка рухнет. Демон то жить будет, только никакого "соединения" у него не > будет. В чем смысл этих странных схем я так и не понял. С таким же успехом можно из php коннектица к демону. так ведь ответы клиенту форвардит не инитор, а демон посредством вебсокет-сервера. они в паре могу существовать сколь угодно долго (может варьироваться в зависимости от хостинга). initor нужен только для того, чтобы подцепить демон. а сам php есть смысл использовать для управления демоном. зы: я так сейчас с большего на всё это посмотрел... оно всё будет работать. но это такой геморрой получается. нет смысла такое юзать - уж лучше ajax-запросы соптимизировать
Это, видимо, про меня. Мне и ответ держать. Да, боюсь. И форум, который я успел за день просмотреть, меня убеждает, что боюсь правильно. Тут ведь из трёх призывов о помощи два в стиле: "Я поднял что-то с земли и съел, и теперь меня тошнит, помогите!". Я бы не хотел так работать. Я хотел бы чувствовать себя хозяином положения. Для этого написал весь JS-код своего приложения на основе DOM level 2 и расширений браузеров. И теперь могу не хвататься за сердце при какой-то js-ошибке - всё написано мной и отлажено мной. P.S. Меня учили на инженера, но из-за краха промышленности пришлось стать программистом. Но некоторые полезные вещи помню. Например, какое устройство абсолютно безотказно. Разумеется, это устройство, которого нет. То есть без которого удалось обойтись.
Villan, не очень понятна ваша огромная задержка при использовании аякса. клиент отправляет запрос на обновление раз в секунду, к примеру. время отклика на такой запрос со стороны сервера должно быть микроскопическим. нагрузка по пересылке данных не изменится от того, что вы станете использовать сокеты. поищите место, которое всё тормозит
Villan я на свой сайт забубенил ежесекундный аякс =) чтобы статистику считать по времени посещения страницы. нагрузка на сервер никакая - посещаемость у меня не ахти. Но даже если посещаемость возрастет в сто раз - сильно не нагрузит сервак все равно.
Соединение инициируется с клиента Куда будет посылать сообщение демон, если веб-сервер форкнул cgi-ник, тот отработал и умер, вебсервер завершил соединение. Хотя бы в случае реализации comet, ибо если мы говорим о хостинге, то вебсервер должен как-то отрабатывать websokets, а этого ни один хостинг не умеет.
Вас хреново учили. Любая разработка базируется на созданных кем-то теориях, экспериментах, доказательствах и т.д. И приборы используют готовые. А если вы и правда не хотите хвататься за сердце, начните с теории полупроводников и пройдите сами весь путь от куска кремния к современному компьютеру. Да, и софт тоже придется написать самому. И вообще, шли бы вы на форум asm ибо php не для вас - он чего там делает и какие-то неизвестные команды процессору выдает. Изучить как устроен дом, несомненно, полезно. А вот работать с ним нынче напрямую... люди изобрели колесо.
Да. Но это вовсе не отменяет разборчивости. Неправильно хватать и юзать "созданное кем-то" - и только потому, что, как представляется вначале, немного сэкономятся усилия на разработку. В итоге, как я уже написал, на этом форуме из трёх призывов о помощи два в стиле: "Я поднял что-то с земли и съел, и теперь меня тошнит, помогите!". Вы - человек крайностей. Или всё с земли тянуть в рот -- или "от куска кремния к современному компьютеру". А меня учили выбирать технологии, на которых строить разработку. Оценивать их надёжность. И если разница по трудозатратам с работой через DOM и через jQuery (которая рабоатет через тот же DOM!) меньше 20% -- я уверенно выбираю работу с DOM. Считая в данном случае jQuery лишним звеном. В какой-то степени глюкавым, как всё в нашем мире. ...подчас рациональней, чем через jQuery.