Я заметил что в статьях где пишут : используй udp взамен tcp для игр тк он быстрый - нигде не приводят сравнение скорости.
Это как знаете сказать - покупайте мазеррати , а не ладу калину т.к. она быстрее
Я не спорю с этими высказываниями. В моих экспераментах выхлоп от использования udp был настолько ничтожен (около 0.01мс выйгрыш скорости который меркнул из за потери пакетов, а проблемм целая куча)
Возможно я буду использовать его когда начну делать 3D игры.
Да, статьи в англоязычном интернете есть и проекты на ютубе есть и сервисы с api. Но в рф почему-то в публичном поле никто своих сервисов с api не создает, а проекты собственных серверов онлайн игр на ютубе (которые сосредотачиваются на статьях вроде udp при этом имея просадки в сотни мс. из за неграмотной архитектуры) часто оказываются провальными (есть видео I hate this game в моей первой статье https://habr.com/ru/articles/669996/ )
Websocket сервер слушает соединения из вне и если временный ключ пользователя (который дан ему после ввода логина и пароля по http) валиден - установит соединение.
Есть прототип разрабатываемой игры где работает все о чем пишу в статьях
я считаю скорость обработки команд игрока (например скорость расчета поиска кратчайшего пути когда игрок отправляет координату куда хочет идти), но это в пинг не включается (у меня в админ панели есть своя статистика для этого - я ее называю RPS игрового сервера и на каждую механику она считается отдельно http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=)
на сайте есть доступ в админ панель для чтения если интересно
если под обработкой ответа перед отправкой вы подразумеваете танцы с бубнами над пакетами которые составляют протокол websocket - да ping их будет включать, но это время как показала практика ничтожно что им можно пренебречь
если постоянное TCP (на базе него работает и WebSocket) соединение установлено (которое после рукопожатия создается) то сервер может слать запросы не дожидаясь никаких данных от клиента - UDP в этом случае не нужно, но UDP может слать запросы без рукопожатия и установки соединения постоянного если знает куда (там и заголовков меньше но гарантированности доставки пакетов и очередности нет - я отказался от нее тк экономия трафика пока не стоит в приоритетах, а выигрыш в скорости как капля в море на фоне времени затраченного на расчета игровых механик и физики, хотя они составляют сотые доли миллисекунды)
Постараюсь ответить (хотя могу не совсем понять вопроса). Что касательно отличия 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 соединения из коробки затруднительно
я полагаю что в прыжках при расчетах физики в отдельных кадрах просадки будут выдавать FPS ниже чем 60/120 и которые вы будите улавливать, хотя средний FPS останется хорошим.
Плавность добивается в клиенте т.к. свое дело сервер сделал, но переподключение требует времени. Этот переход я сгладил, но еще не опубликовал статью про экстрополяцию. В ней будет это видео и переход на тайминге 1:16 уже плавный:
Заложено и реализовано. Есть сервер который обсчитывает физику и взаимодействует с websocket сервером . Физически они находятся на одной машине только это 2 разных процесса работающие на отдельных ядрах процессора (в будущем к серверу обсчитывающему физику планирую подключить вычисления на GPU).
Чат пока не реализован но это уже клиент будет соединятся с дополнительным websocket сервером (тк к игре это относится косвенно)
1. есть скорость работы сервера websocket на прием и отправку пакетов - она указана по ссылки в виде диаграмм взятых с публичных тестов на hello world и составляет 2 000 000 запросов в секунду при работе как web сервер и достаточной пропускной способности - вы это называете RPS web сервера.
2. Есть команды которые пришли на обработку с websocket сервера игровому серверу (это не веб сервер и не websocket это вообще другой процесс и другая программа которая обменивается по шине данных), который представляет собой демона крутящегося в бесконечном цикле называемом кадры (FPS) и устанавливается от 60 до 1000 (и падает при большом количестве игроков) - он указан в самом верху выделенной на картинке области
В каждом кадре игрового сервера отрабатывают разные игровые механики (с картинке выше в выделенной области - это могут быть команд игроков Request в том числе и порожденные ими механики) у них есть разная скорость отработки которую можно охарактеризовать как RPS что означает сколько таких механик ИГРОВОЙ сервер может обработать в секунду если в теории будут только они , но тк в одном кадре не одна механика а целая куча (запускается внутри цикла еще один цикл который обрабатывает каждое живое существо и в нем еще один цикл который обрабатывает все навешанные механики на конкретное существо ) и целая куча существ то FPS сервера не равен RPS, а значительно ниже.
В теории если скорость самой быстрой игровой механики 0.001 мс то игровой сервер может обработать 1.000.000 этих механик в секунду и можно сказать что именно игрового сервера RPS равен 1М тк он не рассылает ни пакетов и ничего не знает о соединениях (как уже сказал это вообще другая программа)
websocket сервер - это не веб сервер который на каждый запрос что то должен отдавать и нельзя здесь применить как к веб серверу прицип запрос - ответ и высчитать время как с web сервером тк websocket сервер может не отдавать ничего или отдать когда игровой сервер пришлет ему новые данные, а игровой сервер в свою очередь так же не сразу обрабатывать поступившие к нему данные, а складывает их в кучу и, когда придет время игровой механики и ее очередь, рассчитает результат и вернет websocket серверу (за это время игрок может еще кучу команд отправить)
Если у вас есть свой вариант как вышеописанный функционал обозначит какими терминами указать мне на странице тестов - welcome
Данный сервис - это авторитарный сервер и с ним можно работать по API в разных движках (unity, unreal engine , godot и др). Тк сервер авторитарный в нем содержится все информация о коллайдерах, вычисляются все механики и он рассылает пакеты которые интерпретирует клиент (изменяет полоску жизней, двигает существ и тд). Сервер работает только с массивами данных.
Такие авторитарные сервера могут быть объединены в некий пул физических серверов и между ними можно переходить и в идеале это на клиенте не должно быть заметно что игрок разлогинелся в одном сервере и залогинелся в другом
вы начали с того что RPS называет кто как хочет. И меня принуждаете назвать как хотите вы. Мой смысл измерить скорость работы механики. PING у меня измеряет другой показатель. Пропускную способность канала - третий.
То что вы описываете про пользователей не RPS, а FPS (который у сервера свой, по умолчанию 1000 максимальный) он зависит от количества ядер, количества запуска механик игроков которые тратят время включенное в RPS.
Я не обязан назвать вашим языком то , над чем работаю сам. А то над чем работаю - не скрывая расписываю
ругать может каждый. а вот сделать что то свое - единицы. так что если вам не нравится то над чем я работаю - просто закройте эту статью и не тратьте свое время
Я заметил что в статьях где пишут : используй udp взамен tcp для игр тк он быстрый - нигде не приводят сравнение скорости.
Это как знаете сказать - покупайте мазеррати , а не ладу калину т.к. она быстрее
Я не спорю с этими высказываниями. В моих экспераментах выхлоп от использования udp был настолько ничтожен (около 0.01мс выйгрыш скорости который меркнул из за потери пакетов, а проблемм целая куча)
Возможно я буду использовать его когда начну делать 3D игры.
Да, статьи в англоязычном интернете есть и проекты на ютубе есть и сервисы с api. Но в рф почему-то в публичном поле никто своих сервисов с api не создает, а проекты собственных серверов онлайн игр на ютубе (которые сосредотачиваются на статьях вроде udp при этом имея просадки в сотни мс. из за неграмотной архитектуры) часто оказываются провальными (есть видео I hate this game в моей первой статье https://habr.com/ru/articles/669996/ )
И зачем эти танцы с бубнами ?) Я предлагаю свою реализацию проверки ping основанную не на технических больше решениях , а на логическом приеме
1.Keepalive держится примерно 10 секунд в стандарных настройках сервера
Websocket сервер слушает соединения из вне и если временный ключ пользователя (который дан ему после ввода логина и пароля по http) валиден - установит соединение.
Есть прототип разрабатываемой игры где работает все о чем пишу в статьях
http://my-fantasy.ru/articles/frontend/index/eyJpZCI6Mn0=
я считаю скорость обработки команд игрока (например скорость расчета поиска кратчайшего пути когда игрок отправляет координату куда хочет идти), но это в пинг не включается (у меня в админ панели есть своя статистика для этого - я ее называю RPS игрового сервера и на каждую механику она считается отдельно http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=)
на сайте есть доступ в админ панель для чтения если интересно
если под обработкой ответа перед отправкой вы подразумеваете танцы с бубнами над пакетами которые составляют протокол websocket - да ping их будет включать, но это время как показала практика ничтожно что им можно пренебречь
если постоянное TCP (на базе него работает и WebSocket) соединение установлено (которое после рукопожатия создается) то сервер может слать запросы не дожидаясь никаких данных от клиента - UDP в этом случае не нужно, но UDP может слать запросы без рукопожатия и установки соединения постоянного если знает куда (там и заголовков меньше но гарантированности доставки пакетов и очередности нет - я отказался от нее тк экономия трафика пока не стоит в приоритетах, а выигрыш в скорости как капля в море на фоне времени затраченного на расчета игровых механик и физики, хотя они составляют сотые доли миллисекунды)
Постараюсь ответить (хотя могу не совсем понять вопроса). Что касательно отличия 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 соединения из коробки затруднительно
я полагаю что в прыжках при расчетах физики в отдельных кадрах просадки будут выдавать FPS ниже чем 60/120 и которые вы будите улавливать, хотя средний FPS останется хорошим.
Про переход я ниже ответил с видео - это делается на клиенте визуальными средствами.
Я к тому что это реализовал уже.
Но там бой как комнаты с игроками (если я все правильно понял) , а я стремлюсь что бы все игроки могли встретится играя на разных серверах
Плавность добивается в клиенте т.к. свое дело сервер сделал, но переподключение требует времени. Этот переход я сгладил, но еще не опубликовал статью про экстрополяцию. В ней будет это видео и переход на тайминге 1:16 уже плавный:
У меня локация - это отдельный сервер всегда (это может процессом на текузей машина и на отдельном железе)
Заложено и реализовано. Есть сервер который обсчитывает физику и взаимодействует с websocket сервером . Физически они находятся на одной машине только это 2 разных процесса работающие на отдельных ядрах процессора (в будущем к серверу обсчитывающему физику планирую подключить вычисления на GPU).
Чат пока не реализован но это уже клиент будет соединятся с дополнительным websocket сервером (тк к игре это относится косвенно)
1. есть скорость работы сервера websocket на прием и отправку пакетов - она указана по ссылки в виде диаграмм взятых с публичных тестов на hello world и составляет 2 000 000 запросов в секунду при работе как web сервер и достаточной пропускной способности - вы это называете RPS web сервера.
2. Есть команды которые пришли на обработку с websocket сервера игровому серверу (это не веб сервер и не websocket это вообще другой процесс и другая программа которая обменивается по шине данных), который представляет собой демона крутящегося в бесконечном цикле называемом кадры (FPS) и устанавливается от 60 до 1000 (и падает при большом количестве игроков) - он указан в самом верху выделенной на картинке области
В каждом кадре игрового сервера отрабатывают разные игровые механики (с картинке выше в выделенной области - это могут быть команд игроков Request в том числе и порожденные ими механики) у них есть разная скорость отработки которую можно охарактеризовать как RPS что означает сколько таких механик ИГРОВОЙ сервер может обработать в секунду если в теории будут только они , но тк в одном кадре не одна механика а целая куча (запускается внутри цикла еще один цикл который обрабатывает каждое живое существо и в нем еще один цикл который обрабатывает все навешанные механики на конкретное существо ) и целая куча существ то FPS сервера не равен RPS, а значительно ниже.
В теории если скорость самой быстрой игровой механики 0.001 мс то игровой сервер может обработать 1.000.000 этих механик в секунду и можно сказать что именно игрового сервера RPS равен 1М тк он не рассылает ни пакетов и ничего не знает о соединениях (как уже сказал это вообще другая программа)
websocket сервер - это не веб сервер который на каждый запрос что то должен отдавать и нельзя здесь применить как к веб серверу прицип запрос - ответ и высчитать время как с web сервером тк websocket сервер может не отдавать ничего или отдать когда игровой сервер пришлет ему новые данные, а игровой сервер в свою очередь так же не сразу обрабатывать поступившие к нему данные, а складывает их в кучу и, когда придет время игровой механики и ее очередь, рассчитает результат и вернет websocket серверу (за это время игрок может еще кучу команд отправить)
Если у вас есть свой вариант как вышеописанный функционал обозначит какими терминами указать мне на странице тестов - welcome
вас не смущает что вы все это время думаете что у меня веб сервер ? Я не хочу с вами спорить и видно эта статья не для вас - просто пройдите мимо
Я не совсем понял ваш вопрос.
Данный сервис - это авторитарный сервер и с ним можно работать по API в разных движках (unity, unreal engine , godot и др). Тк сервер авторитарный в нем содержится все информация о коллайдерах, вычисляются все механики и он рассылает пакеты которые интерпретирует клиент (изменяет полоску жизней, двигает существ и тд). Сервер работает только с массивами данных.
Такие авторитарные сервера могут быть объединены в некий пул физических серверов и между ними можно переходить и в идеале это на клиенте не должно быть заметно что игрок разлогинелся в одном сервере и залогинелся в другом
если у вас есть опыт - напишите свои статьи. После уже можно судить по отзывам и критике людей
вы начали с того что RPS называет кто как хочет. И меня принуждаете назвать как хотите вы. Мой смысл измерить скорость работы механики. PING у меня измеряет другой показатель. Пропускную способность канала - третий.
То что вы описываете про пользователей не RPS, а FPS (который у сервера свой, по умолчанию 1000 максимальный) он зависит от количества ядер, количества запуска механик игроков которые тратят время включенное в RPS.
Я не обязан назвать вашим языком то , над чем работаю сам. А то над чем работаю - не скрывая расписываю
ругать может каждый. а вот сделать что то свое - единицы. так что если вам не нравится то над чем я работаю - просто закройте эту статью и не тратьте свое время