NoWinFate

Пока отлаживается гейт на .NET поделюсь тем, что планируется ввести на следующих шагах. Сейчас схема сервера представляет собой вот это: Через некоторое время я добавлю еще один компонент в систему и появится брокер сообщений - https://nats.io/. Казалось бы, зачем увеличивать сложность системы, добавляя еще один непонятный компонент? На самом деле этот компонент позволит отвязать сервисы друг от друга и убрать зависимости между ними. А также позволит легко добавить новые, при необходимости, не трогая при этом старые сервисы и не рестартуя их и т.д.. Т.е. получим такую схему: И здесь гейм-сервера коннектятся не только к брокеру сообщений, но и к гейту. Зачем? А затем, что данные с клиента необходимо передавать с минимальной задержкой, а брокер сообщения дает небольшой оверхед, по началу не заметный при нескольких сотнях игроков и очень заметный при тысячах интенсивных сообщений. Поэтому часть сообщений будет идти напрямую на клиент, а часть сообщений передаваться в брокер сообщений. В самом брокере сообщений сервисы будут открывать каналы - и принимать на эти каналы сообщения. Каждый канал может обслуживать сколько угодно сервисов - при высокой нагрузке, это позволяет систему горизонтально масштабировать. Также удобно конфигурировать игровые сервера. Достаточно в настройках каждого будет прописать адрес брокера сообщений и когда игровой сервер стартует, он будет посылать специальное сообщение, в ответ на которое, все подключенные гейты будут ему сообщать о себе: в итоге, не нужно парится с настройками и прописывать вручную каждый гейт. На конечной стадии получим что-то вроде: Групп будет разнесен на несколько сервисов - сервис чатов, сервис друзей\гильдий\патей, сервис аукционов и почты и еще что-нибудь. Будет удобно писать всякие утилиты по управлению пользователями\сервисами - достаточно подключиться к брокеру сообщений и отслеживать сообщения, которые там хоядт. например просматривать истории публичных чатов в режиме реального времени во всех серверах и транслировать их куда-то, отслеживать всех пользователей на карте не влезая напрямую в игровые сервера и т.д.

Можно. я сейчас добавляю как раз проект для работы с протоколом. Планировал его изначально сделать на F#, но на юнити он не прижился, поэтому если совместно разрабатывать, то на C# могу данный модуль реализовать, чтобы можно было его использовать одновременно и в юнити. Но, сразу предупреждаю - это будет реализация протокола не совместимого с изначальным. Изначальный игровой протокол - без разделителей параметров, а у меня параметры разделены байтами, в которых указывается тип данных параметра. В дальнейшем я планирую msgpack использовать, чтобы вообще уйти от ограничения на длину передаваемого параметра и динамически поджать команду, в зависимости от того, что передается.

К клиенту добавил отладочную консоль, которая в DEBUG режиме запускается. Немного поправил протокол и теперь у каждой команды есть метаинформация о том, какие параметры и какого типа в ней содержатся. Это предварительный шаг для реализации гейта, в противном случае есть риск много недель трахаться с бинарным протоколом, долбясь с каждый байт. И сразу же обнаружилось несколько проблем в клиенте, который иногда читает не те параметры, которые ему присылали... Ну, что, собственно и не удивительно с таким подходом к сетевому протоколу, когда на валидацию чтения параметров положили большой и толстый. Оверхед составил 1 байт на 1 параметр. Итог: трассировка общения клиента с сервером из состояния пиздеца пришло в годное состояние. УРА!

Предлагаю объединить усилия и стандартизировать протокол между клиентом-сервером, описав его в proto файле. Из этого файла можно сгенерировать и JSON и protobuf и msgpack - как кому больше нравиться. Самих команд только около 700+, учитывая еще и параметры, в районе 5-6к строк только описания команд получится.

Update: Выпилена нахуй старая система логирования. Добавлена новая, которая не жрет время на IO, т.к. логирование сделано в отдельном потоке и почти не сказывается на производительности, в отличие от старого способа. Выпилены нахуй все сборщики стектрейсов, обработки исключений и прочей мутотни, которая в x64 не работает, да и вообще является прошлым веком. Вместо этого добавлен единый механизм складывания дампов для серверов и клиента, в случае если произойдет падение. Следующий шаг, это переписывание гейта на .NET платформу, используя функциональный язык F#. Если развлекаться - то по полной. Если кто-то хочет стрим вот этого всего, то можно запилить)

Да, обновления есть, правда, позднее чем хотелось. Полностью переделан солюшен, все разрозненные проекты объединены в кучу. Все запускается в один клик из студии и все пути уже настроены - просто бери и запускай. Слиты все общие файлы для клиента и сервера. Просто пиздец сколько говна было вычещено Локализация единая для сервера и для клиента Временно убран бинарный формат ресурсов И сервер и клиент теперь работают на одинаковой версии LuaJIT Выпилен нахуй CaLua и прочая срань Добавлен LuaBridge и православный вызов lua из C++ и C++из луа. Правда пока только на клиенте, но и за сервером дело не станет Выкинуты все ненужные файлы Студия все таже VS2022 с С++23 Ветка https://gitlab.com/alexxst.st/corsairs-online-public/-/tree/upgrade?ref_type=heads Ближайшие планы Слить локальную ветку с IOCP движком Добиться стабильного поведения клиента и отрисовки всего контента (сейчас есть артефакты) Перевести протокол общения на msgpack Начать плавно переносить вот это все на .NET, начиная с GateServer

Понятно, судя по всему легаси для проекта, для шифрования там 3DES и ещё какой-то самопальный xor на максималках. Можно смело выкидывать, тем более реализаций вышеописанных функций - нет.

для 1.38 нужно добавить доп. слоты?

What is the function of these files? Why are they needed?

Есть изменения, переписан сетевой двиган на IOCP, обновлены плюсы до версии С++23, добавлен последний LUA JIT. Будет релиз в следующем месяце.

Ну такой себе аргумент. С++ разраб разберется с С# за 1-2 дня, а вот наоборот - это может быть проблема. У каждого свое видение на то, как оно должно быть Можно подставить любой язык - Java, Scala, Kotlin, golang и т.д. Вы с другими системами работали? Проблемы которые они успешно решаются в С++, в других системах просто не существуют. Хм.. доверяете ли вы платформе enterprise уровня на которой работают миллионы критичных сервисов? Ну да, доверяю. Доверяю JVM, доверяю golang, дотнету тоже доверяю. Почему нет то?) Ну молодцы. С сообществом, полагаю не поделились?) Мне он ничего не даст, возможно кому-то из разработчиков что-то подскажет. Обычная схема скейлинга, с микросервисами и т.д. Сам могу про такое долго рассказывать. WorldOfTank отлично скейлится, потому что там игровой процесс ограничен картами, которые существуют, пока идет игра. А вот когда мир непрерывный это совершенно иная задача. В рабочее время я занимаюсь системой подобной этой Вот тут почитать можно https://networking.docs.improbable.io/welcome/spatialos-concepts/offloaded-and-zoned-servers/ А в свободное решил заняться корсарами. В них есть что-то ламповое) Даже не знаю, как этот вывод получился. Выдержать DDOS = отразить DDOS. Это не ко мне, это к Вам.

С одной стороны компиляторы для C++ дают высоко оптимизированный код и вроде как плюсы должны быть быстрее. Но, в реальности все гораздо сильнее зависит от того, как, где, когда и на чем будет работать код. Начнем с типа задач - есть IO (Input\Output) задачи и есть CPU задачи. В IO задачах почти не важно, насколько быстрый код - все зависит от задержек ввода\вывода при обращениях к БД, сети, файлам. Выигрыш, который дает оптимизированный компилятор тут будет вообще не будет на уровне погрешности из-за ожидания операций ввода\вывода. Применяя С++, Delphi, Go, Ocaml, .NET, Java, Rust мы получим одинаковое время работы. Если берем CPU задачу, то здесь выполнение зависит от применяемых алгоритмов, архитектуры и т.д. Ок, при прочих равных С++ в числодробилках будет быстрым. Насколько быстрым? - Неизвестно. Нужно поводить замеры, по крайней мере при работе с векторами, матрицами С++ будет очень быстрым, позволяет отлично векторизовать эти операции и тут с ним сложно сравниться. Поэтому 3D игрушки\драйвера\библиотеки для работы с графикой\алгоритмы CV(computer vision ) и пишут на плюсах - огромное кол-во матриц, векторов, и прочего требуется перемножать друг с другом. Гейт - это типичное IO приложение и его основная задача перекладывать из одного сокета байты в другой, делая небольшие операции над ними. Основная операция, которая тут будет - это копирование байтов из одного источника в другой - эти операции одинаково быстро выполняются в любом языке. Казалось бы - почему его на плюсах не написать? Вот тут и начинаются сложности с С++ - когда начинаем писать реальное приложение. Оказывается, что в С++ нет системы пакетов (которые почти в любом языке есть в XXI веке), поэтому нужно тащить кучу исходников в свой код что добавляет проблем при компиляции, когда у одного заводится, у другого - нет. Например нормальный логгер. Когда доходим до сетевой части - все ещё интереснее. В C++ нет дефолтной либы boost не предлагать для работы с сетью, есть только стандартный API сокетов, который работает так себе. 3к сокетов это предел для текущего гейта(теоретический предел 5к). Чтобы была возможность держать больше сокетов, чтобы операции выполнялись быстрее (вот то самое, что обеспечит ускорение для работы гейта) нужно прикручивать IOCP в windows, в linux - epoll тащить. Ну или прикручивать libuv. Затем, хорошо бы прикрутить метрики которые бы показывали текущую ситуацию на гейте, например на основе прометея. Когда все эти кусочки собираем в гейте, то получаем кучу кода, написанную в разных стилях, по разному инициализирующуюся, и как следствие - трудно поддерживаемую и понимаемую. Чтобы это все перенести на linux, нужно ещё кучу времени потратить на компиляторы gcc & clang и обмазаться @ifdef в куче мест. Если берем дотнет (C#), то у нас куча вещей идет из коробки - автоматическая поддержка windows\linux\macos для которой и напрягаться не нужно. Быстрые сокеты, которые смогут и DDOS атаку выдержать и кучу клиентов, асинхронный ввод\вывод. Пакеты, которые ставятся из хранилища пакетов и в них уже есть почти вся необходимая функциональность и гораздо меньшее количество кода, который реализует ту же логику на плюсах (да и писать на C# гораздо быстрее чем на С++). Отсутствие всяких проблем с переполнениями буферов, порчей памяти, с неинициализированными значениями и т.д.. На порядки лучшая диагностическая информация. Я не говорю о медленных строках в С++ и медленном аллокаторе памяти из коробки. И еще один важный момент - код очень похож на С++ который в сообществе знают. Ну я не говорю уже о том, что многие вещи гораздо быстрее\лучше и безопаснее на C# реализовываются при высокой скорости работы.

Привет. Тут ответ на целую статью тянет) Вечером доберусь до компа и напишу про плюсы и минусы решений на разных языках.

Разве то что я сказал касается геймплея? Геймплей мне как раз очень нравится, замечательная игрушка, с интересной прокачкой. Именно благодаря этому я и решил привести сервер в нормальное состояние. Эта игрушка с душой. С клоуном может и перегнул. Но. Желание это все отрефакторить никак не связано с тем, что испытываешь, когда это все рефакторишь. Совершенно не связанные друг с другом вещи. Комментарии про горящую жопу еще будут - она у всех горит, когда видишь определенные места. Это только начало - приведение проекта в стадию, когда он может хотя бы по человечески запускаться, билдится и стартовать. Я собираюсь по всем сомнительным моментам отдельно пройтись подробными комментариями почему так не надо и как надо. Есть несколько тем: Сетевая часть Внутренняя логика парсинга пакетов, сетевых вызовов и т.д. Протокол Передача параметров, контроль границ, вывод содержимого, формат Пул команд, буферов, подсчет ссылок, reader's & writer's Поддержка нескольких протоколов, легаси и т.д. Шифрование Защита от повторной пересылки пакетов Защита от просмотра пакетов Защита от DDOS Сетевое общение серверов Варианты топологии Варианты технологий обмена Логирование Текстовые логи Игровые события База данных Оптимизация ORМ для работы Хранение ресурсов, шмоток, индексы, статистика, ключи и т.д. Работа со шмотками (транзакционность, как избавиться от дюпа) Работа с гильдиями и группами Чат Локализация в игре Магия Карты, перемещение Работа с Lua С какой начать? P.S. Нужно чтобы кто-нибудь посмотрел клиент и добавил необходимые ресурсы, да и вообще запустил и посмотрел, насколько он хорошо работает. Потому что он глючит периодически (возможно в процессе рефакторинга могло что-то перестать инициализироваться, так как оно по ошибке инициализировалось)

Просто девиз клиента xDDDD https://gitlab.com/alexxst.st/corsairs-online-public Чтобы проверить клиент, отключайте WPE, которую делал какой-то анальный клоун (я могу лучше, да). Версия Release пока не исправлялась (только Debug) сервера и клиент https://disk.yandex.ru/d/z0TtNWp3w-IRBw