Так это 14-ая по счету статья. В предыдущей обсуждалась как раз очередь. Если в двух словах все воркеры передают данные в игровой сервер на скорости 1 600 000 в секунду , в нем уже очередь реализована
Как я понимаю вы говорите о семафорах и работы с одним дескриптором подключения к сокету в контексте сервера. Однако можно создать его с параметром SO_REUSEPORT и паралельный процесс(поток) сможет создать отделтный сокет прослушивая тот же адрес (локалхост) и порт
Она примерно равна 0.02мс. времени на запись (в самом быстром случае) , но я не использую ее в игровом сервере. Redis используется в приложении авторизации по http на одной машине записывая временный ключ в кеш и websocket сервере когда человек устанавливает соединение читая кеш redis в асинхронном режиме что бы на это время не блокировать worker этого websocket сервера (их много , как с веб сервером). В игровом я использую очередь в оперативной памяти о которой писал в статье
а по поводу что было 15 лет назад свечку не держал мне было тогда столько же (не верится что тогда были такие онлайн). А вот Fallout Online: Requiem того же года движок держит не более 500 человек т.к. работает в одном потоке
для сравнения передача из потока (условно процесса) A в процесс B делается при скорости 1 600 000 пакетов в секунду и тут это важно тк нужно быстро освобождать процесс что бы он выполнял другую работу (тк пока он передает он ждет и не принимает новые соединения, не отправляет пакеты которые надо отправлять)
Но работа на запись в фаил это 80 000 запросов в секунду (если процесс держит поток открытый и не делает fclose и fopen постоянно - то больше).
Минус этого подхода - эта очередь работает лишь на том сервере (железе) где у вас фаил. Redis и RabbitMQ полезные тем что они масштабируются (например есть приложение на одном сервере что пишет в очередь, а другое приложение в микро сервисной архитектуре его читает)
это 11-ая по счету статья. В другой статье про открытый мир я указал , что можно разбить всю игру на локации. Каждая локация может быть на отдельной физической машине - это уже реализовано. Таким образом игроков может быть и 50.000 и 500.000 - лишь бы железа хватило
По моим исследованием VPN с 2мя ядрами CPU и 4GB RAM за который я плачу 8$ в месяц могут уместиться +-4000 игроков и npc суммарно (т.к. последние тоже отправляют команды которые шлют пакеты игрокам об изменении мира)
В языке на котором я работаю есть функции по сериализации и десериализации 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 протоколом я не готов
в моей реализации видимость не ограничивается
Вы с дисскуссии переходите в оскорбление - мне с вами неочем более говорить
а вот что я делю на потоки и выполняю параллельно - вы можете увидеть в следующей статье
для сравнения передача из потока (условно процесса) A в процесс B делается при скорости 1 600 000 пакетов в секунду и тут это важно тк нужно быстро освобождать процесс что бы он выполнял другую работу (тк пока он передает он ждет и не принимает новые соединения, не отправляет пакеты которые надо отправлять)
Решение просто - тут спору нет.
Но работа на запись в фаил это 80 000 запросов в секунду (если процесс держит поток открытый и не делает fclose и fopen постоянно - то больше).
Минус этого подхода - эта очередь работает лишь на том сервере (железе) где у вас фаил. Redis и RabbitMQ полезные тем что они масштабируются (например есть приложение на одном сервере что пишет в очередь, а другое приложение в микро сервисной архитектуре его читает)
это 11-ая по счету статья. В другой статье про открытый мир я указал , что можно разбить всю игру на локации. Каждая локация может быть на отдельной физической машине - это уже реализовано. Таким образом игроков может быть и 50.000 и 500.000 - лишь бы железа хватило
По моим исследованием VPN с 2мя ядрами CPU и 4GB RAM за который я плачу 8$ в месяц могут уместиться +-4000 игроков и npc суммарно (т.к. последние тоже отправляют команды которые шлют пакеты игрокам об изменении мира)
согласен. но в udp такую систему надо писать а это усложняет и сам код и порог вхождения в проект и как следствие вызовет кучу ошибок