Создание сервера для Российских онлайн ММО игр на PHP ч. 1 — Импортозамещение
Мой первый пост и я хочу поделиться с вами своей идеей создание сервиса предоставляющего разработчикам игр и студиям платформу для создания онлайн игр! Поехали!
Мой первый пост и я хочу поделиться с вами своей идеей создание сервиса предоставляющего разработчикам игр и студиям платформу для создания онлайн игр! Поехали!
Пока остальные статьи не читал, но сервер на пхп планируется делать как long life приложение с подключенным экстеншеном реактом для асинхронщины? Потому что я не могу представить нормальный сервер, где на каждый коннект будет создаваться отдельный процесс без возможности синкать потоки, потому что они изолированы.
У пхп специфика такая, что кто-то когда-то решил, что поднимать приложение с нуля на каждый запрос это круто, теперь от этой концепции никуда не уйдешь. Даже если у тебя родраннер под капотом. Для веб-приложений ещё куда ни шло, где настолько не важна задержка, что у тебя картинка из CDN дольше будет запрашиваться, чем ответ на HTTP-запрос от веб-приложений. Но прям для онлайн-игр... Ну не знаю.
Те же мьютексы. как ты будешь ставить блокировки, чтобы исключить race condition и корректно авторизовать игрока один раз, даже если он захотел создать 3-4 одновременных коннекта? Вроде как за это должен отвечать прям отдельный модуль, который все коннекты потоках обрабатывает в отдельной очереди и потом футболит коннект в отдельный поток игровой логики, где есть лютейшая синхронизация потоков между собой с гарантией консистентности данных в хранилище, компенсациями, ACID и все такое. Кажется, на пхп это не сделать, и никакой опкеш с джит-компиляцией тебе никак не поможет. Можешь рассказать, как ты планируешь разделять потоки и синхронизировать их?
Не то что бы я критиковал, ты молодец и действительно, дело не в языке, а в архитектуре. Но, также не следует забывать про платформу, на которой твоя архитектура будет крутиться, ее возможности и ограничения. Исходя из этого кажется, что изначальная технология была выбрана неверно. Для веб-приложений или простых проектов да, другу там показать, перед женой похвастаться, но для чего-то более существенного оно не подходит и очень быстро деградирует, даже железом масштабировать не получится, так как упрешься в одно ядро цпу или накладные расходы на обвязку вокруг на совершенно других технологиях, чтобы хоть как-то засинкать происходящее хотя бы у двух игроков между собой.
Сервер будет один раз запущенный (а значит и скомпелированный в машинный код в оперативной памяти процесс)
Мьютексы и семаформы я не использую однако да - паралельные потоки у меня есть и они синхронизируются по шини типа Channel в Go (это позволяет сделать библиотека Parallel в php написанная как модуль на С++, да и вообще из под php можно вызывать код Си для сложных вычислений из коробки). Пока у меня 3 потока - websocket сервер что обрабатывает пакеты, сервер обсчета физики и команд ироков, поток записи логов в фаил (тк это осень долго). В будущем планирую добавить к серверу обсчета физики вычисления на gpu
Что касательно попытки авторизации - у одного игрока может быть лишь 1 websocket соединение. При попытке подключит второе программа просто закроет предыдущие и передаст контроль новому (игрок даже из изры не выйдет) . Сама авторизауия по http (на который проверяется логин и пароль и выдается уникальный ключ для подключения по websocket, а аот при пожключении к последнему он смотрит есть ли уже у игрока соединение в массиве игроки-соединения)