Comments 36
FPS может как взлетать до 300 так и опускаться до 30 (ниже тоже может , но уже видны торможения игры)
Торможения видны будут и на 60/120 FPS, если он вечно прыгать будет. Поэтому лучше плавные 30, чем вечные прыжки между 30 и 60.
Не понял, в чем разница между http и "socket сервером", по поводу пинга. По ту сторону веб сервера - такой же сервер, который также само может выполнять какие-то внутренние расчеты, перед тем как вернуть ответ, и также само может выполнять несколько асинхронных запросов параллельно, не дожидаясь ответа на первый.
Если копнуть еще глубже, то сокет сервер может отправить запросы, не дожидаясь ответа, если это UDP, но это не ваш случай.
И игровой пинг, наверное, может включать в себя обработку ответа перед его отправкой, но отдельно созданный для этого icmp как раз показывает именно пинг, то есть скорость доставки пакетов. И уже на базе этой информации можно работать с архитектурой, например если канал данных узкий, а пинг нужен высокий, то размер пакета может быть критичным, и его надо уменьшать вплоть до размера одного фрейма.
Если же вы считаете скорость обработки команда, то дело выходит уже не в сети, а возможно в ресурсах на стороне сервера (cpu/gpu/mem/io)
Постараюсь ответить (хотя могу не совсем понять вопроса). Что касательно отличия Http от websocket в плане подсчета пинга это как минимум скорость их работы:
При http запросе у вас запускается Apache/Nginx и каждый раз совершает рукопожатие (а это время) с websocket вы 1 раз соединились и держите постоянное соединение
Если речь про PHP (а в моем примере именно он) то Apache/Nginx подымит (или возьмет из существующих) worker процесс php-fpm (или запустить модуль php если php стоит как модуль Apache например) - а это тоже время на передачу управления процессу. Websocket сервер в данном проекте написан на PHP (т.е. он в нашем случае выступает нашим слушателем порта как Apache/Nginx) ну и вдобавок не отдает ничего (ну кроме системных заголовков что TCP пакет получен, а их меньше чем у HTTP - это тоже экономит время )
Если при работе с http как результат того что пакет дошел мы можем просто прочитать заголовок ответа то с websocket мы ведь не обязаны отдавать ответ (ни пустое с кодом ответа как в HTTP 200 - OK) и получение сообщений сервером от клиента обусловлено лишь обменом системных заголовков TCP что пакет доставлен, однако я не встречал ни в C# ни в JavaScript при работе с websocket методов обработчиков на клиентской стороне успешно доставленных сообщений что бы хотя бы оценить за какое время пакет был доставлен ,а PING это двухсторонний обмен (запрос - ответ), а раз websocket может не отдавать никакого ответа клиенту и анализировать ping у подобного websocket соединения из коробки затруднительно
Есть keepalive соединения.
У вас php-сервис прям наружу торчит?
Так вы и по сырому сокету можете ACK-сообщение отправить 🤔
Websocket сервер слушает соединения из вне и если временный ключ пользователя (который дан ему после ввода логина и пароля по http) валиден - установит соединение.
Есть прототип разрабатываемой игры где работает все о чем пишу в статьях
http://my-fantasy.ru/articles/frontend/index/eyJpZCI6Mn0=
1.Keepalive держится примерно 10 секунд в стандарных настройках сервера
И зачем эти танцы с бубнами ?) Я предлагаю свою реализацию проверки ping основанную не на технических больше решениях , а на логическом приеме
если постоянное TCP (на базе него работает и WebSocket) соединение установлено (которое после рукопожатия создается) то сервер может слать запросы не дожидаясь никаких данных от клиента - UDP в этом случае не нужно, но UDP может слать запросы без рукопожатия и установки соединения постоянного если знает куда (там и заголовков меньше но гарантированности доставки пакетов и очередности нет - я отказался от нее тк экономия трафика пока не стоит в приоритетах, а выигрыш в скорости как капля в море на фоне времени затраченного на расчета игровых механик и физики, хотя они составляют сотые доли миллисекунды)
Если ещё не читали, то рекомендую ознакомиться с https://gafferongames.com/post/udp_vs_tcp/, как и со всей серией Networking for Game Programmers.
Я заметил что в статьях где пишут : используй udp взамен tcp для игр тк он быстрый - нигде не приводят сравнение скорости.
Это как знаете сказать - покупайте мазеррати , а не ладу калину т.к. она быстрее
Я не спорю с этими высказываниями. В моих экспераментах выхлоп от использования udp был настолько ничтожен (около 0.01мс выйгрыш скорости который меркнул из за потери пакетов, а проблемм целая куча)
Возможно я буду использовать его когда начну делать 3D игры.
Да, статьи в англоязычном интернете есть и проекты на ютубе есть и сервисы с api. Но в рф почему-то в публичном поле никто своих сервисов с api не создает, а проекты собственных серверов онлайн игр на ютубе (которые сосредотачиваются на статьях вроде udp при этом имея просадки в сотни мс. из за неграмотной архитектуры) часто оказываются провальными (есть видео I hate this game в моей первой статье https://habr.com/ru/articles/669996/ )
Что ж, если вы так зациклились на скорости, то тем более советую почитать статьи о разнице между UDP и TCP. У UDP преимущество не в скорости, а в том, что можно сделать нормальную отзывчивую онлайн игру.
Поиграйте в Ragnarok Online. Если не ошибаюсь, то игра использует как раз TCP и сетевой слой там не очень.
Возможно я буду использовать его когда начну делать 3D игры
2D/3D вообще не имеет отношение к сетевой части.
Мне известна разница между ними которую я изложил в другой статье. Скорость это главный показатель (и в вашей статье именно о ней) . Вы не можете быть уверены что чьято игра медленная только потому , что она использует tcp, а не udp
А с tcp нельзя сделать нормальную "отзывчатую" игру по вашему? :)
в tcp для каждого игрока нужно устанавливать сессию, в udp это не обязательно.
Для каждой сессии видимо нужно выделить поток...
В общем архитектуру можно по-разному сделать, но для ММО видимо UDP логичный выбор
про какие потоки выделенные для tcp соединения вы говорите ?
если вы уверены что я не прав - вы можете как я в цифрах написать какой выигрыш будет при использовании UDP ?
Например у вас играет 50 тысяч человек одновременно.
Каждый должен отправлять отчет о своих действиях и получать реакцию сервера.
В случае tcp мы вынуждены что делать? На каждое соединение открывать сессию tcp. Как мы будем ее поддерживать, ведь отправка пакета должна быть подтверждена, то есть у нас будет некий таймаут, если пользователь залагает. Как избежать лага самого сервера в этом случае? открывать эту сессию в отдельном параллельном потоке. Для каждого.
В случае udp это не требуется, отправили и забыли. Но в пакет должна входить нумерация, и если на стороне клиента обнаружена пропажа, активируется синхронизация статуса. Либо некоторые пакеты от клиента могут игнорироваться.
Если у меня будет 50.000 у меня будут другие ппоблеммы и другие деньги
Плюс проект масштабируемый и каждая локация это отдельный сервер в тч физический может быть.
Боюсь вы плаваете в понятии потоков , процессов и сессий tcp тк то что вы пишите - чепуха
Пакеты tcp могут отправляться асинхронно и сервер не блокируется в случае если пользователь "залагает"
Как бы термин ММО и предполагает, что игроков будет не условных 5-10, как в контерстрайке. Это Massive Multiplayer Online проект.
И 50000 я взял не с потолка, а на всяк случай взял что-то сопоставимое с 65535, чисто чтобы указать, что количество исходящих портов может закончиться.
это 11-ая по счету статья. В другой статье про открытый мир я указал , что можно разбить всю игру на локации. Каждая локация может быть на отдельной физической машине - это уже реализовано. Таким образом игроков может быть и 50.000 и 500.000 - лишь бы железа хватило
По моим исследованием VPN с 2мя ядрами CPU и 4GB RAM за который я плачу 8$ в месяц могут уместиться +-4000 игроков и npc суммарно (т.к. последние тоже отправляют команды которые шлют пакеты игрокам об изменении мира)
5000 игроков тянул сервер с двумя ядрами еще 15 лет назад, когда была популярна L2
И мир был поделен на локации, чтобы немного уменьшить количество трафика, дополнительно ограничивая видимость игроков. Тем не менее на крупных ивентах, в одной локации могло взаимодействовать достаточно приличное количество игроков, правда у каждого могли быть свои "лаги", которые наблюдались примерно при 200+ игроков в пределах видимости.
в моей реализации видимость не ограничивается
и у меня нет и 5000 игроков. и бросать все ради оптимизации наносекунд с udp протоколом я не готов
а по поводу что было 15 лет назад свечку не держал мне было тогда столько же (не верится что тогда были такие онлайн). А вот Fallout Online: Requiem того же года движок держит не более 500 человек т.к. работает в одном потоке
а вот что я делю на потоки и выполняю параллельно - вы можете увидеть в следующей статье
и у меня нет и 5000 игроков. и бросать все ради оптимизации наносекунд с udp протоколом я не готов
Мы говорим не про оптимизации вашего конкретного частного случая, а о технологии в целом.
а по поводу что было 15 лет назад свечку не держал мне было тогда столько же (не верится что тогда были такие онлайн)
То есть? онлайн в 2000 одновременно играющих достигался еще в прошлом веке.
А если взять Lineage2, то на официальном российском сервере было около 15-16 шардов, каждый по 4-5 тысяч онлайна (официальный лимит одновременно игроков онлайн был 5000, хотя сервер держал больше, но для достижения идеальной экономики ограничили, чтобы всем игрокам хватало квестовых мобов и локаций. я уж молчу сколько их было на оригинальном корейском.
и вы в курсе что UPD пакеты могут не по порядку приходить и теряться по дороге ? Т.к. у меня создается впечатление что вы сами не понимаете о чем пишите
некоторые пакеты TCP тоже могут приходить не по порядку. Или теряться по дороге, вызывая ретрайны.
TCP гарантирует, что все придет в правильном порядке. Все отправленные пакеты нумеруются
И udp из коробки не будет повторно пересылать потеряные пакеты и нумеровать. А все танцы с бубнами с учетом возможности масштабировония, отсутствия игроков, таймингов о которых я писал выше, с паузами между командами в реалиях - бессмысленно.
Нужно не стремиться сделать идеальный продукт , а быть реалистом , решать реальные проблемы, а не которые могут быть (или не быть с учетом архитектуры и мощности железа) если там когда то будет 50.000 игроков....да если у меня будет хотя бы половина уже буду в "золоте купаться"
Паузы между командами (которые даже в realtime играх есть) движения (например, в которое обычно udp делают) обычно в сотни и тысячи раз больше (пусть даже минимум из статьи - 17мс. , что способен уловить ваш глаз) чем выйгрыш который вы получите от использования udp (0.01 мс. за пакет который еще может не дойти). Вот в видо стриминге там да, действительно потоковая передача и это нужно
Так что не стоит слепо использовать все что советуют, а нужно разбираться где и в каких числовых показателях плюс и какие могут быть после проблемы (например забивка канала пакетами, часть которых будет проигнорирована сервером или как в вашей статье сказано в переводе на русский - необходимостью писать свой протокол над udp)
если под обработкой ответа перед отправкой вы подразумеваете танцы с бубнами над пакетами которые составляют протокол websocket - да ping их будет включать, но это время как показала практика ничтожно что им можно пренебречь
я считаю скорость обработки команд игрока (например скорость расчета поиска кратчайшего пути когда игрок отправляет координату куда хочет идти), но это в пинг не включается (у меня в админ панели есть своя статистика для этого - я ее называю RPS игрового сервера и на каждую механику она считается отдельно http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=)
на сайте есть доступ в админ панель для чтения если интересно
Создание сервера для онлайн ММО игр на PHP и Unity ч. 11 — FPS, Ping, паузы между командами, интерполяция и экстраполяция