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

Это сообщение отредактировал(а) Smorodin - 2.9.2011, 12:37

а что делает ваш цикл 30 секунд? и зачем его держать так долго? (тонна инфы?)

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


не вариант так проверять?

Evghenusi, Вы не поняли сути. Автору топика надо реализовать _ожидание_. Для этого надо сделать цикл, который прервется только тогда, когда произойдет какое-то событие (как я понял, проверка на наличие события находится в цикле). Конечно, отправлять пхп в долгое выполнение - не совсем хорошая идея, но и я так частенько делаю... Это раз.

Во-вторых, 
supervladislav, http-запросы крайне не рекомендуется держать дольше 30 секунд (если вообще проходят...). Посмотрите в такой вариант: клиент отправляет на пхп запрос, в цикле проверяется время выполнения скрипта, если 25 секунд - возвращаем на клиент, что событий нет, и прекращаем работу скрипта. Клиент, получив такой ответ, тут же отправляет такой же запрос... И так далее по 25-30 секунд, пока все-таки событие не произойдет.
Если же реализовано на сокетах - то такой вариант, конечно, не подойдет...

интересная логика. почему?

Вы как это собираетесь сделать?
Бразуер посылает запрос, на сервере запускается скрипт, дальше по-вашему браузер должен послать, с пометкой "туда же", а сервер увидя особые отметки, не скрипт запустит по новому, а магическим образом передаст данные уже работающему экземпляру (который в цикле ждет непонятно чего)?
т.е. вы хотите сделать строго один запущенный скрипт на пользователя?
в цикле можно проверять в базе последние записи активности, но они должны быть сделаны другим скриптом, зачем тогда висеть этому?

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

Все-так почитайте про HTTP, спустя нескольких лет программирования на php можно и посмотреть, что это такое   

Браузеры могут оборвать через 30 секунд соединение (если речь о браузерах вообще). Могут и прокси. В общем, это рекомендательного характера - 25 секунд (+5 секунд на возможные задержки). У контакта, кстати, так и реализовано получение новых событий.
XHR long-polling решает эту проблему.

Добавлено @ 13:56

Советую перечитать мой пост. Я об А, Вы о Б.

Клиент посылает: дай_новые_события. Сервер ожидает 25 секунд появление события (если появило сразу - замечательно, выполнение заканчивается, если нет - ждем 25 секунд). Если событий не произошло - отправлем клиенту "новых_событий_нет" и заканчиваем работу скрипта. Клиент, получив команду "новых_событий_нет" - отправляет снова "дай_новые_события".

Это сообщение отредактировал(а) Smorodin - 2.9.2011, 13:59

Smorodin, в том и дело, что ТС изначально хочет не "клиент: дай мне новые события", а "сервер: пользователь походил?"

Smorodin, спасибо за понимание , а вот на счёт того рвут ли броузеры соединение или нет ,зы где бы почитать достоверной инфы.

Добавлено через 5 минут и 17 секунд
enoff, т.е. вы хотите сделать строго один запущенный скрипт на пользователя?
да именно так ,на каждого пользователя ,я не очень понял что вы выше имели ввиду выше этого)))
Скрипт в цикле ждёт запроса с flash клиента.

enoff, что мешает в моих сообщениях "дай_новые_события" заменить на "дай_ответ_сходил_ли_юзер_и_если_да_то_как_и_что_мне_делать_дальше_и_вообще_какой_смысл_жизни" ?   


supervladislav, факторов много: прокси, фаерволы, ограничение JSONP стоит 30 секунд. Поэтому "висяки" на 25 секунд - проверенная и одобренная мировая практика.

Добавлено через 1 минуту и 43 секунды
enoff, только сейчас заметил, что Ваша фраза - 

подразумевает, что сервер будет разговаривать сам с собой?   Зачем серверу где-то что-то спрашивать такое, которое он и сам знает? Я упорно не понимаю логики ни в одном Вашем сообщении.

Добавлено через 2 минуты и 9 секунд

http://yandex.ru/yandsearch?text=XHR+long-...;lr=50&fs=1

Smorodin, поняли? Нужно не создавая новые соединения, крутясь в цикле реагировать на действия клиента. Тут только остается самим с собой поговорить, чуда-то не произойдет   

А вот это неправильно. Флеш отправляет на пхп информацию о ходе. Сервер принимает. И второму игроку (который в это время висит на лонг-пулинге) отправляет. Теперь первый повисает, а второй при действии пользователя отправляет информацию о ходе...

И вообще со флешем тогда уж лучше перенести на сокеты.

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

Ну все же понимают, что это бред?   

Smorodin, что ж вы такой серьезный-то...   
ТС занимается программированием несколько лет. и с завидным постоянством от него поступают подобные идеи   
на советы читать книги и маны не реагирует. Предлагая бредовые идеи таки можно раскрыть суть вопроса, как показывает практика:


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



я просто сказал то, чего хочет ТС, понятным вам языком. Я же не говорил, что это возможно   

эх, раньше было в подобных топиках жарче   

а по теме:

вот и весь ответ на вопрос топика 

  

enoff,   понял... надо чаще сюда заходить =)

Конечно, так лучше не делать, ибо быдлокод (//К. О.)

Ну если все-таки очень хочется, то по понятным причинам такой bdsm лучше творить с пользовательскими ресурсами (я на JS намекаю).

Это сообщение отредактировал(а) moscwich - 4.9.2011, 20:32

А чем состояния (то бишь) сессии не угодили.
Прав 
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 секунд
В соседней теме тоже треш