А чем состояния (то бишь) сессии не угодили.
Прав 
enoff, если конечно подходить с этой стороны, сделать демона и не морочить ... 
Smorodin, голову  почему, да потому что если на каждого юзера делать демон или хостер даст по башке или у самого сервер гыкнет, так как скрипт отбирает памяти в 15 мб ЛЮБОГО размера кода (хоть один вывод Привет мир).
Отсюда прав enoff, если запускать то один единственный демон обработчик, который принимает (ожидает) запросы от клиента или сессиями. Кстати идентификация пользователя может быть тем же идентификатором сессии.


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

Это сообщение отредактировал(а) Sentox - 5.9.2011, 18:28

Sentox, откуда Вы взяли про демонов? =) Или для Вас любой работающий скрипт PHP = демон?










Абсолютно ничего неправильного. XHR long-polling.

Имхо, ужос. Т.е. вы используете протокол http и хотите организовать игру с обратной связью. Т.е. при событии на сервере отправлять некое сообщение клиенту?

Имхо, это как то не правильно.


Опрашивайте сервер с определенной периодичностью на редмет событий с момента предыдущего запроса.
Или речь идет о серверном сценарии на php?

А вообще имхо. Правильное решение для таких игр. Сервер на сях. Флеш клиент устанавливает постоянное соединение с этим сервером. В серверной части один поток - собственно обработка игровой ситуации на сервере, другой/другие работают с клиентами.

Хотя может я собственно задачу не совсем понял.

Насколько я понял, ТС хочет отправить в бесконечный цикл сценарий на ПХП, к которому (к одному и тому же) подключаются 2 игрока (то есть 1 выполняемый сценарий обсуживает двух клиентов). 

Мнения разделились:
1) На сокет и сервер не на ПХП (то есть клиента без флеша не сделать)
2) Мое, но, возможно, неправильно понятое другими: XHR long-polling (периодично опрашивать, но при каждом опросе, если действия никакого не свершилось, "зависать" на Н секунд для более быстрой реакции клиента на событие, и предотвращения большого количества запросов)

Все согласились только с тем, что ТС надо пересмотреть подход к реализации..

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

... выгоднее, если это умеет клиент... некоторым использовать тот же самый флеш не позволяет религия.

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

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

Да согласен. Не тот подход к созданию игры.

А как два игрока к одному скрипту (точнее к одному процессу) напрямую? Т.е. если "мутить" на php то-что то типа такого:
1 скрипт. Обработка ситуации на сервере. Т.е анализирует шаги полученные от игроков. Обрабатывает математику ситуации засовывает в БД информацию. (В принципе, может быть все и без него)
2. скрипт работы с игроком. Получает от игрока информацию о сделаном ходе. И, должен получить информацию о ходе другого игрока (толи напрямую вставленную таким же скриптом от другого игрока толи обработанную серверным скриптом). Да можно поставить задержку, но во первых это некрасиво, имхо,  будет смотреться в глазах игрока - фигли у нас тут страница "зависла". А во вторых, это соединение совершенно не надежное - 100500 причин по которой оно может разорваться и ни кто кроме игрока жалеть не будет.





Да только. Единственный "механизм" восстановления соединения в случае обрыва этого "постоянного" соединения F5 нажатая игроком.

В общем я сторонник написания таковых игр (где требуется обратная связь в реальном времени) не на php. А с технологиями позволяющими держать реально постоянное соединение.


Это плохо когда в такие вещи вмешивается религия. Прикиньте какого монстра придется создать если религия позволит использовать исключительно php+ js + html если целью будет создать аналог каунтерстрайк  

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

Добавлено через 6 минут и 59 секунд

В случае написания сервера на С. И наличия реальных постоянных соединений. Ждать вообще не придётся. В случае со скриптами, придётся прогонять через базу. Т.е. пришел ход от игрока 1 - записали в базу - скрипт игрока 2 опросил базу - ввернул игроку 2.
Т.е. у нас кроме времени работы двух скриптов есть еще работа с сервером БД. В случае написания на сях - просто передаем сообщение в другой процесс (возможно и в базу запишем - но считывать точно не обязательно)

1) Делая на динамике страница вообще не перезагружается. Как и во всех играх, надпись: ожидание хода игрока: осталось 48 секунд, и работает чат (к примеру).
2) На клиенте - обработка ошибок. По таймауту ответ не пришел - отправляем снова запрос. Никаких проблем для пользователя. 


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



Опять же - зависит от программиста клиента.


Ну не будем тут говорить о таких больших играх =) С ними все понятно =) Но есть 100500 примеров использования того же флеша в браузерных "рюшечках", когда можно (+проще, +лучше) обходиться без него.


При прямых руках (ну и от ситуации зависит, конечно) производительность веб-сервера с long-xhr может в разы превосходить сокетный. У сокетов тоже есть ограничения, и память кушать они тоже любят...


Еще раз повторюсь: зависит от платформы клиента. Если клиент на html+js, то без разницы, на чем Вы пишите сервер. Браузеры еще не научились адекватно работать с web-socket. Года через два - скорее всего. Но не сегодня.

Добавлено через 45 секунд

то, что я описывал на 1 странице.

Не не не, !!!
Память у хостера забирается, и смотрится от него. Сама машина php резервирует память а то что Вы предоставили это уже машина PHP Вам предоставляет реальное использование. Фактическое резервирование , вот что хостеру нужно.

ВПС: 1Г оперативы, 1Г проц держит 200 активных подобных соединений без изменений показателей загрузки впски. Максимум спрогнозировать сложно, сейчас на ней вертится несколько приложений общей нагрузкой 1000-1500 в пик, показатели свыше 30% не поднимаются.

Добавлено через 1 минуту и 53 секунды
И не думаю, что ВПС жила бы все еще, если б потребляла 15 метров на каждого. Что-то Вы слишком страшное рассказываете.

Добавлено через 4 минуты и 37 секунд
В соседней теме тоже треш