Хорошо, поэтому ваш вопрос заключается в том, как эффективно обмениваться данными между СЕРВЕРОМ и несколькими КЛИЕНТАМИ практически в режиме реального времени.У вас две проблемы, эффективное общение с клиентом.Эффективная связь между «сеансами» на сервере.
HTTP-КЛИЕНТ К СЕРВЕРУ
Протокол HTTP не является состоянием.Это значит, что вы отправляете запрос, сервер отвечает, а затем соединение закрывается.Это затрудняет общение в двух направлениях или в зависимости от событий, как того требует игра.Вот почему большинство сетевых игр используют UDP, который имеет гораздо меньше накладных расходов на отправку информации.Мы должны использовать TCP / IP, и мы должны использовать протокол HTTP в этом сценарии, так как мы можем сделать это эффективно?
Комета - это ответ.Сервер Comet - это просто термин, означающий сервер, который длительное время поддерживает соединение открытым для непрерывной отправки данных клиенту.Серверы Comet используют асинхронные потоковые (ajax) соединения, которые позволяют клиенту «знать», когда поступила новая информация, без необходимости читать весь ответ.См. Также: Длинный опрос Сервер PHP Comet
СЕССИЯ К СЕССИИ
Когда сервер получает запрос, ему нужно задать вопрос «Где все остальные» и ему это нужнозадавать этот вопрос часто и качественно.Mysql не будет лучшим технологическим решением для чего-то подобного.Вы хотите ОЧЕНЬ ОЧЕНЬ быстро ОЧЕНЬ быстро читать из нескольких процессов (каждый http-клиент)
Зачем отправлять данные по сетевому соединению, декодировать их из строки (sql) и ждать, пока сервердекодируйте вставку или ответ и т. д. - все это звучит как лишние накладные расходы.
Вам нужен настоящий IPC (межпроцессное взаимодействие).Это трудно достичь в PHP, но это может быть сделано.Использование общей памяти или даже запись в отображенный в память файл будет лучшим решением для обеспечения максимальной скорости чтения и записи обновлений GPS-координат. PHP IPC
Связывание его:
Клиент отправляет запрос на сервер и начинает опросить его.Сервер читает общую память, чтобы увидеть координаты других.Сервер записывает в открытое соединение строку, содержащую строку JSON, описывающую расположение всех игроков.В то же время, когда клиент опрашивает сервер, он также должен отправить серверу запрос, описывающий его местоположение, и сервер должен записать это значение в общую память.Программа остается в непрерывном цикле, пока клиент не закроет http-соединение.
См. Эти:
Если совместно используемая память не является вариантом, я бы предложил использовать другую базу данных или что-то более простое, например хранилище значений ключей (memcache) или даже mongodb.Они оба будут иметь меньше транзакционных издержек и смогут вставлять и опрашивать намного быстрее, чем MySQL
. Третий вариант - использование PostgreSQL в качестве механизма IPC.Для этого вы можете использовать события LISTEN, но это немного надумано.
Примечания:
Это решение не очень хорошо масштабируется с PHP.Допустим, вы используете apache и в вашем рабочем пуле 20 работников.Когда вы достигнете 20 соединений, все php-процессы сервера будут использованы другими запросами, поэтому 21-й запрос будет бесконечно ждать, когда рабочий станет доступным.
Лучшее решение - внедрить сервер Comet / long-опрос в чем-то вроде Twisted или в любой другой асинхронной структуре.