Комментарии 38
Как человек, который копал тему (лет 10 назад), сравнивал реализации т.д., могу сказать, что:
самое важное, в данном случае, сколько блокировок порождает код на низком уровне. Ибо когда вы заставляете ОС оперировать более чем парой тысяч блокировок, то получается следующая фигня: мощность CPU вы масштабировать можете только линейно, а затраты на обслуживание блокировок на уровне ядра с какого-то момента начинают идти по экспоненте. Потому что любая блокировка - это существенные затраты.
Блокировок чего ?
скорее всего речь идет о блокировках на операциях ввода/вывода
На низком уровне, для того что бы конкурирующие процессы обслуживали сетевой стек, и ваши конкурирующие потоки могли "одновременно" читать/писать на одном сокете, задействуются примитивы синхронизации - обслуживание которых в какой-то момент начинает сжирать CPU. Рост количества примитивов, вполне линейно поглощается, до какого-то момента (последний раз тестил на 4-х ядерном процессоре). Как только на каждое ядро CPU количество примитивов начинает превышать разумное значение, происходит замедление работы системы. Причем в windows, например, это CPU-время засчитывается в idle - т.е. в какой-то момент роста блокировок таскменеджер показывает, что 90% CPU свободно, а по факту у вас свободное время CPU чуть ли не в 0.
Как-то так... Совсем уж если просто.
Как я понимаю вы говорите о семафорах и работы с одним дескриптором подключения к сокету в контексте сервера. Однако можно создать его с параметром SO_REUSEPORT и паралельный процесс(поток) сможет создать отделтный сокет прослушивая тот же адрес (локалхост) и порт
Допустим, да, ситуацию улучшит. Но у вас конкурирующие читатели, вам же необходимо как-то упорядочить поступаемую информацию. Так ведь? А это опять синхронизация чего-либо.
P.S. Это не спор, просто если вы строите сервер на PHP и о латентности сетевых карт заговорили...
В веб серверах количество воркеров или потоков именно для работы с CPU, а не чтобы максимально быстро данные с сетевой карты считать. Обработка http-запросов занимает от миллисекунд до секунд, и оптимизация микросекундныхзадержек тут на самом последнем уровне. А вот сколько запросов параллельно обсужит от пользователей - как раз на первом, но это количество тоже до тысячи обычно, а то и 64 стандартно.
Я про веб сервера не пишу , но и одно другому не мешает: знаю тесты веб серверов способных до 2млн RPS обработать
Http протокол для игр не рассматриваю
Да вполне нормальный протокол для RPC. Клацаешь по кнопочке, с сервера по хттп грузанулись настройки персонажа, например и отобразилось окошко с ним Причем всё готовое уже есть: Сервер, лоадбалансер, дебаггеры, клиенты. Ну и логи потом дебажить приятнее, нежели какой-нибудь grpc
Http протокол , а с ним и его сервера слишком медленные
Медленный для чего? Ну вот, например, дефолтный ответ "самого медленного фреймворка в мире" (ака Laravel) внутри докера на винде - 8-10мс в режиме дебага. Этих 10мс не хватит чтоб получить информацию о профиле игрока? Получить список предметов? Получить информацию о точках спауна? Где именно эти 10мс сыграют значительную роль в нагрузке, когда один селект из базы может и в два, и в десять раз дольше работать?
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Возможно вы не поняли. Предметная область любой игры не ограничивается персистентным состоянием позиции игрока. Это всего лишь одна ~десятая всех задач.
Я вот по должности своей как раз разрабатываю один известный MMO шутер-лутер. И http (и grpc) для идемпотентных и стейтлесс запросов вполне себе занимает бОльшую часть всей предметной области, а то о чём вы говорите - лишь сессионная составляющая самого режима игры, которая частично может быть рассчитана и на клиенте в т.ч. в отличие от какой-нибудь операции "покупки" товара у "торговца".
Так что списывать технологию со счетов просто "потому что" не вижу смысла.
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Уменьшение размера пакетов - необходимая часть разработки, но ни как не на этапе проектирования.
Эм... Т.е. мы архитектурим систему, в которой даже модель передачи данных не определена и оставлена "на будущее" сразу в бэклог? Ой вей) Так в ТЗ и напишем: "а интерфейс для передачи данных делайте любой, мы потом перепишем с нуля заново". А потом выясниться, что наиболее оптимальный вариант не согласуется с принятой моделью или типы не подходят, тогда придется перелопачивать вообще всё.
(взамен использования текстовых понятных человеку команд, например в том же json) Использование сжатие (которое тратит время перед отправкой пакетов и тормозит процесс)
А сериализация и десериализация (жсона) происходит мгновенно и ничего не тормозит?
Одним из самых первых и важных решений при разработке сервера - это обеспечение его работы в многопоточном режиме
На пыхе тысячу лет не писал, но в шарпах параллелить подключения - это мастхэв. Накрутили даже из коробки возможность асинхронной работы на ThreadPool, так что можно даже руками не писать.
А про аппаратные ограничения на скорость принятия пакетов даже не задумывался, было любопытно.
Но судя по этой картинке, если я правильно понял и при размере пакета в 64 байта - задержка 50нс, то в секунду будет 1,21 МБ?
А тут 9,52 МБ?
Мне вот интересно, причём тут всё же php, если никакой конкретики по реализации нет, а лишь теория по верхам, язык вообще не затрагивается
Интересна техническая часть по реализации, что использовалось, как в главный процесс пишется из других? Что вынесено по разным процессам и почему для чего
в целом по больше части вода... =\
Эта статья 14-ая по счету. Я рассказываю только об архитектуре. Сам проект имеет прототип на моем сайте (http://my-fantasy.ru/) и написан на PHP
если я привожу в пример в своих статьях библиотеки - они так же для PHP
исходный код первых версий (старых) я jпубликовал в git https://github.com/webrobot1
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте.
Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
Надеюсь вы понимаете, что в приведенной вами табличке речь идет о кадрах уровня ethernet. Если вы из приложения шлете полезную нагрузку, то к ней прибавляются еще заголовки tcp / udp, заголовки ip, заголовки ethernet. Плюс эти latency вам вообще ничего не говорят, т.к. tcp добавляет механизмы повторной посылки сегментов, а ip добавляет маршрутизацию по кучей сетей между сервером и клиентом.
на физической "машине" (железе) должно быть достаточное количество нитей (thread) у ядер CPU что бы ваши потоки (процессы) находились на разных нитях и действительно работали параллельно (в ОС есть встроенный балансировщик на который как я полагаю можно положиться как минимум на первых порах разработки)
Все смешалось, люди, кони. Для обеспечения многозадачности ОС использует планировщик задач, которые выделяет кванты процессорного времени потокам процессов. Поток исполнения - минимальная абстракция для выполнения кода, процесс - это более высокая абстракция, группа потоков. На железе есть процессоры, ядра, гипер-треды (полу-ядра). Можно в идеале привязать поток исполнения на какое-либо ядро, но монопольно ядро вы не захватите, да оно и не надо.
Когда комменты интереснее самой статьи ?
Прежде чем публиковать статью, отправьте ее другу на редактирование, который дружит с грамматикой. Впечатление будто школьник прогуливает уроки и решил заняться играми. Статьи ни о чем. Думал будет полноценный туториал по созданию сервера (передо мной сейчас такая задача), а тут только теория, да еще и далекая от темы, да еще и вставки видео каких-то. Продолжайте свое видео-творчество на своем канале, а не тут, а то испанский стыд появляется
Есть выражение : не указывайте человеку что ему делать, а он не будет говорить куда идти.
Мои статьи содержать отметку не "туториал", а "роадмап" и читать Вас их никто не заставлят.
Вот без теории у человека - только код на C#. Но через 3 года оказалось все еле работает.
Персонаж в принципе не понимает куда он попал. Хамство, завышенное ЧСВ, непонимание критики, а ещё "14я статья и 3 года исследований". Такое ощущение, что ему нужен только сам факт публикации для галочки в ВУЗе. Он ещё и на сайт это опубликовал несмотря на то, что ему насовали полную панамку
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
Создание сервера для онлайн ММО игр на PHP ч.14 — Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)