Стрельцов Михаил @webrobot
IT архитектор, PHP developer, разработчик игр
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Game Developer
Senior
PHP
MySQL
Git
High-loaded systems
C#
Unity3d
Game Development
Redis
OOP
SQL
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Http протокол , а с ним и его сервера слишком медленные
исходный код первых версий (старых) я jпубликовал в git https://github.com/webrobot1
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте.
Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
если я привожу в пример в своих статьях библиотеки - они так же для PHP
Эта статья 14-ая по счету. Я рассказываю только об архитектуре. Сам проект имеет прототип на моем сайте (http://my-fantasy.ru/) и написан на PHP
В языке на котором я работаю есть функции по сериализации и десериализации JSON .
json_encode (сериализация) выполняется на скорости 1 800 000 вызовов в секунду на небольших пакетов (около 60 байт)
json_decode (десериализация) - на скорости 600 000 вызовов в секунду (тот же пакет)
Я провожу замеры отдельных функций языка для нахождения "узких мест" (записываю их на своем сайте красным цветом что бы не забыть http://my-fantasy.ru/articles/frontend/index/eyJpZCI6MjN9 )
Эта скорость примерно 600.000 небольших пакетов в секунду
Http протокол для игр не рассматриваю
Я про веб сервера не пишу , но и одно другому не мешает: знаю тесты веб серверов способных до 2млн RPS обработать
Спасибо. То о чем пишу можно реализовать на любом языке тк пишу я про архитектуру
https://habr.com/ru/articles/741734/
Так это 14-ая по счету статья. В предыдущей обсуждалась как раз очередь. Если в двух словах все воркеры передают данные в игровой сервер на скорости 1 600 000 в секунду , в нем уже очередь реализована
Как я понимаю вы говорите о семафорах и работы с одним дескриптором подключения к сокету в контексте сервера. Однако можно создать его с параметром SO_REUSEPORT и паралельный процесс(поток) сможет создать отделтный сокет прослушивая тот же адрес (локалхост) и порт
Блокировок чего ?
Согласен. Но это это не стоит в приоритете , а json более нагляден
Она примерно равна 0.02мс. времени на запись (в самом быстром случае) , но я не использую ее в игровом сервере. Redis используется в приложении авторизации по http на одной машине записывая временный ключ в кеш и websocket сервере когда человек устанавливает соединение читая кеш redis в асинхронном режиме что бы на это время не блокировать worker этого websocket сервера (их много , как с веб сервером). В игровом я использую очередь в оперативной памяти о которой писал в статье
а по поводу что было 15 лет назад свечку не держал мне было тогда столько же (не верится что тогда были такие онлайн). А вот Fallout Online: Requiem того же года движок держит не более 500 человек т.к. работает в одном потоке
и у меня нет и 5000 игроков. и бросать все ради оптимизации наносекунд с udp протоколом я не готов