для сравнения передача из потока (условно процесса) 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 из коробки не будет повторно пересылать потеряные пакеты и нумеровать. А все танцы с бубнами с учетом возможности масштабировония, отсутствия игроков, таймингов о которых я писал выше, с паузами между командами в реалиях - бессмысленно.
Нужно не стремиться сделать идеальный продукт , а быть реалистом , решать реальные проблемы, а не которые могут быть (или не быть с учетом архитектуры и мощности железа) если там когда то будет 50.000 игроков....да если у меня будет хотя бы половина уже буду в "золоте купаться"
Вы же не предложили никакой конкретики , кроме переименования в "сложность алгоритма" которая выражается в O(n) , когда в моих метриках я хочу показать скорость в мс. на конкретном железе .
Так или иначе если я буду сидеть над идеальными названиями , то разработка не закончится никогда.
"...Websocket и игровой сервер" - написано на странице. А сервер может быть написан на php (открывать сокет, слушать порт), по ссылке есть публичные тесты приложений
В своем проекте я волен называть вещи как они мне кажутся верным , расшифровывая что я имею в виду - не докторскую защищаю а делаю игру , что бы зацикливаться на научнрй терминалогии.
Вы спросили метрики - я вам их ответил. Сейчас дискутируете не над показателями, а над тем как я из называю
и вы в курсе что UPD пакеты могут не по порядку приходить и теряться по дороге ? Т.к. у меня создается впечатление что вы сами не понимаете о чем пишите
Мне известна разница между ними которую я изложил в другой статье. Скорость это главный показатель (и в вашей статье именно о ней) . Вы не можете быть уверены что чьято игра медленная только потому , что она использует tcp, а не udp
Паузы между командами (которые даже в realtime играх есть) движения (например, в которое обычно udp делают) обычно в сотни и тысячи раз больше (пусть даже минимум из статьи - 17мс. , что способен уловить ваш глаз) чем выйгрыш который вы получите от использования udp (0.01 мс. за пакет который еще может не дойти). Вот в видо стриминге там да, действительно потоковая передача и это нужно
Так что не стоит слепо использовать все что советуют, а нужно разбираться где и в каких числовых показателях плюс и какие могут быть после проблемы (например забивка канала пакетами, часть которых будет проигнорирована сервером или как в вашей статье сказано в переводе на русский - необходимостью писать свой протокол над 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 такую систему надо писать а это усложняет и сам код и порог вхождения в проект и как следствие вызовет кучу ошибок
И udp из коробки не будет повторно пересылать потеряные пакеты и нумеровать. А все танцы с бубнами с учетом возможности масштабировония, отсутствия игроков, таймингов о которых я писал выше, с паузами между командами в реалиях - бессмысленно.
Нужно не стремиться сделать идеальный продукт , а быть реалистом , решать реальные проблемы, а не которые могут быть (или не быть с учетом архитектуры и мощности железа) если там когда то будет 50.000 игроков....да если у меня будет хотя бы половина уже буду в "золоте купаться"
Вы же не предложили никакой конкретики , кроме переименования в "сложность алгоритма" которая выражается в O(n) , когда в моих метриках я хочу показать скорость в мс. на конкретном железе .
Так или иначе если я буду сидеть над идеальными названиями , то разработка не закончится никогда.
И RPS это не имя собственное (во всяком случае в моем проекте), а сокращение Requests Per Second, что в переводе означает Запросов В Секунду
Там где у меня запросы (к игровому серверу, с websocket серверу и в т.ч. к Http серверу) использую это сокращение
Почему неявной?) Вот игру делаю - все о чем пишу в ней реализовано
"...Websocket и игровой сервер" - написано на странице. А сервер может быть написан на php (открывать сокет, слушать порт), по ссылке есть публичные тесты приложений
В своем проекте я волен называть вещи как они мне кажутся верным , расшифровывая что я имею в виду - не докторскую защищаю а делаю игру , что бы зацикливаться на научнрй терминалогии.
Вы спросили метрики - я вам их ответил. Сейчас дискутируете не над показателями, а над тем как я из называю
TCP гарантирует, что все придет в правильном порядке. Все отправленные пакеты нумеруются
Если у меня будет 50.000 у меня будут другие ппоблеммы и другие деньги
Плюс проект масштабируемый и каждая локация это отдельный сервер в тч физический может быть.
Боюсь вы плаваете в понятии потоков , процессов и сессий tcp тк то что вы пишите - чепуха
Пакеты tcp могут отправляться асинхронно и сервер не блокируется в случае если пользователь "залагает"
и вы в курсе что UPD пакеты могут не по порядку приходить и теряться по дороге ? Т.к. у меня создается впечатление что вы сами не понимаете о чем пишите
если вы уверены что я не прав - вы можете как я в цифрах написать какой выигрыш будет при использовании UDP ?
про какие потоки выделенные для tcp соединения вы говорите ?
А с tcp нельзя сделать нормальную "отзывчатую" игру по вашему? :)
Мне известна разница между ними которую я изложил в другой статье. Скорость это главный показатель (и в вашей статье именно о ней) . Вы не можете быть уверены что чьято игра медленная только потому , что она использует tcp, а не udp
Паузы между командами (которые даже в realtime играх есть) движения (например, в которое обычно udp делают) обычно в сотни и тысячи раз больше (пусть даже минимум из статьи - 17мс. , что способен уловить ваш глаз) чем выйгрыш который вы получите от использования udp (0.01 мс. за пакет который еще может не дойти). Вот в видо стриминге там да, действительно потоковая передача и это нужно
Так что не стоит слепо использовать все что советуют, а нужно разбираться где и в каких числовых показателях плюс и какие могут быть после проблемы (например забивка канала пакетами, часть которых будет проигнорирована сервером или как в вашей статье сказано в переводе на русский - необходимостью писать свой протокол над udp)