Jump to content
NoWinFate

Рефакторинг сервера.

Recommended Posts

Я около 4х часов просмотрел код сервера и впечатление так себе...

Скажу честно, за такой код на С++, как в пиратии, обычно пристреливают на месте. По крайней мере - Я.

Попробую отрефакторить этот сервер чисто по фану, ну и частично его перенести на более удобную платформу для разработки - dotnet. Клиент рефакторить не буду (только минимум)

План таков

  • Сначала все это переведем на VS2022, C++ 20, чтобы была возможность комфортной работы.
  • Оптимизируем солюшен (может на х64 портировать?😵)
  • Затем исправляем сетевую часть для того, чтобы можно было хоть в каком-то виде смотреть что за пакеты приходят на сервер. Тот бинарный протокол который сейчас есть хорош, но несет в себе проблемы с границами и размером параметров (это только на первый взгляд). А, я еще магическое число 0.618 нашел в сетевом коде... Это просто абзац.
  • Третьим этапом перепиливаем гейт на dotnet (C#). Наверняка текущий больше 2-3к коннектов не тянет в принципе.
  • Потом поиграемся с хранением итемов (если честно хранение ресурсов в сериализованный строке, дикая дичь какая-то, и наверняка с дюпами постоянная головная боль)
  • Ну и шестой - с геймсервера по кускам попробуем перенести функционал (надеюсь, за полгода управлюсь)

 

P.S. Асинхронщина, многопоточность, архитектура, вот это все.. не переключайтесь. Может даже будут стримы... .

P.P.S. Разработка открытая, репозиторий тут https://gitlab.com/nowinfate/corsairs-online-public

  • Like 6
  • Thanks 1

Share this post


Link to post
Share on other sites

А почему STL 20? Вроде нету там чего-то того что необходимо, думаю 14 там за глаза, не надо гнаться за цифрой, больше проблем будет.
Рекомендую начать с адаптации исходного кода под CMake.
Мы переписывали Gate, Group, Account базируясь на том же lidbc, могу сказать что если его чуть подшаманить (семфор и мьютексы перекинуть), то работать можно, не советую переписывать всё глобально, там очень много китайщины от которой не знаешь чего ожидать.

Рекомендую обратить внимание на наше опенсурсное решение клея между lua и cpp https://github.com/Alex2772/cpp_lua_glue, что-то типо sol2, но хеадер онли и с дикой абстракцией с шаблонами. Используем у себя клиенте самые последние коммиты, дорабатываем часто.

Желаю удачи, надеюсь хоть кто-то на этом форуме потратит своё собственное время в пользу комьюнити.

  • Thanks 1

Share this post


Link to post
Share on other sites

Кому-то разрабатывать на 9-ти летней студии, когда есть более лучшие инструменты - норма. Инструменты должны быть современными. Мне нужны лямбды, auto, стандартизированная либа для 20х, а не кастрированное вот это все что там есть.

 

Часть кода на дотнет хочу попробовать перенести(у него больше возможностей и проще разработка), поэтому cmake не в тему. В студии (Rider'е) разработку таких проектов вести гораздо проще.

С луа в проекте беда... думаю вот это затащить https://github.com/kunitoki/LuaBridge3 - стильно, модно, современно, со всякими рантаймчеками и кастами. А главное, с приведением типов можно не париться на шаблонах сделано.

 

Сервер перевел на VS2022, C++20 (выкинул BTI по пути, сорян, если кому-то было нужно)

Клиент перевел на VS2022, C++20 (добавил заголовочные файлы DirectX 8.1 в исходники + либы, теперь клиент компилируется из коробки, без танцев)

После тестирования планирую залить все одним комитом.

В клиенте осталось только импорт либ при сборке пофиксить...

 

P.S. Пользуясь случаем, передаю привет человеку, который код клиента засрал goto'шками, причем таким образом, что кроме древнего компилятора этот код ничто не скомпилит. Парень, юзай return. Он работает! Верняк говорю!

 

Цитата

Желаю удачи, надеюсь хоть кто-то на этом форуме потратит своё собственное время в пользу комьюнити.

Пасиб!

  • Thanks 1
  • Haha 1

Share this post


Link to post
Share on other sites
13 часов назад, NoWinFate сказал:

Кому-то разрабатывать на 9-ти летней студии, когда есть более лучшие инструменты - норма. Инструменты должны быть современными. Мне нужны лямбды, auto, стандартизированная либа для 20х, а не кастрированное вот это все что там есть.

 

Часть кода на дотнет хочу попробовать перенести(у него больше возможностей и проще разработка), поэтому cmake не в тему. В студии (Rider'е) разработку таких проектов вести гораздо проще.

С луа в проекте беда... думаю вот это затащить https://github.com/kunitoki/LuaBridge3 - стильно, модно, современно, со всякими рантаймчеками и кастами. А главное, с приведением типов можно не париться на шаблонах сделано.

 

Сервер перевел на VS2022, C++20 (выкинул BTI по пути, сорян, если кому-то было нужно)

Клиент перевел на VS2022, C++20 (добавил заголовочные файлы DirectX 8.1 в исходники + либы, теперь клиент компилируется из коробки, без танцев)

После тестирования планирую залить все одним комитом.

В клиенте осталось только импорт либ при сборке пофиксить...

 

P.S. Пользуясь случаем, передаю привет человеку, который код клиента засрал goto'шками, причем таким образом, что кроме древнего компилятора этот код ничто не скомпилит. Парень, юзай return. Он работает! Верняк говорю!

 

Пасиб!

У тебя есть опыт работы с кроссплатформенными приложениями? Линукс хотя бы. Каждый новый стандарт сразу не выходит стабильным под все компиляторы, мы у себя в проекте используем 17 стандарт и абсолютно себе ни в чем не отказываем. Функции реализованные в STL не сразу адаптируются и под все платформы тоже. К примеру filesystem под MacOS отсутствует. Баги тоже не сразу исправляются, к примеру в MSVC sizeof(std::vector<int>) между debug и release под 17 стандартом имеет разные показатели, а в mingw, clang и gcc всё ок. Адаптация под gcc старого формата 6-8 тоже не обходится без танцев с бубнем и поиска аналогов в других STL функциях

А если потащишь какую-то готовую либу с STL'ем, скомпилированную где-то там, под каким-то другим компилятором и когда появятся неизвестные крашики ещё больше появится отвращения к STL) Готовые библиотеки собранные под STL и имеющие API методы использующие в аргументах этот STL как-нибудь std::string на разных компиляторов разных версиях будет обрабатывать регистры по разному. По этому смотри осторожней с готовыми библиотеками где есть зависимость от STL, лучше тащи в проект как исходники и собирай сам, а соберётся ли она на каком-то gcc6-8? или MinGW, уже будет вопросом и новым квестом))


Я не пытаюсь вызвать какой-то холивар в чатике, просто когда вижу что разработчики бегут за цифрой не смотря на возможные баги и проблемы STL, хочется предупредить о возможных проблемах.
P.s никто не мешает работать в VS2022 и использовать 14, 17 стандарт) А ещё больше советую обратить внимание на IDE CLion или хотя бы модуль Resharper в студии, очень сильно поможет, автоматический рефактор исходного кода хорошо поможет)

Друг мой, goto это мелочи)) после трёх лет рефактора всего этого китайского гавна меня уже ничего удивляет)) Как захочешь перевести на mingw или gcc, сразу увидишь много интересного)) using namespace std в header'e, диффы между #define max / #define min с std::max / std::min, call jack в ассерте, копирование структур во рендере/фрейм (MindPower3D рендер эффектов). Это только начало 😀

image.png

image.png

Edited by Kst
  • Thanks 1

Share this post


Link to post
Share on other sites

У меня вообще 18+ опыта, из них лет 6 кроссплатформы, но не на С++, а на дотнете. Сервер под линукс гарантировано не соберется, там к винде приколочено гвоздями все намертво. Если все вот это выдирать - достаточно трудно, долго и больно. 

Я думаю, что под gcc & mingw & clang это добро не соберется гарантировано, а ошибок будет больше 10к+. Мне хватило ошибок обычного компилятора от MS, который достаточно хорошо стандарты плюсов держит. Да, без resharper тут никуда, это вообще по умолчанию должно стоять. Раньше Visual Assist использовал, но решарпер больше понравился.

Ну меня тоже не удивляет этот китайский код, я даже могу примерно назвать сколько человек его писало, потому что код судя по всему, ревью не проходил в той команде - работает и ладно. Просто жопа горит с многих моментов. using namespace std  - это я выпили намертво, как и мого других опасных конструкций, в том числе и с итераторами. А, впилил нормальную строку соединения dsn в конфигах, а порнографию с шифрованием пароля выкинул. Сервера, как ни странно, завелись и начали работать. С клиентом еще борюсь)

 

CLion не хочу использовать, потому что планирую частично сервер на дотнет перевести, а CLion такие солюшены не поддерживает. Только студия и райдер. Да и тулы для разработки какие-нибудь надо добавить, например по управлению модами, по редактированию итемов, правке ДБ, какая-нить панель для отслеживания серверов. Не на С++ же их писать - это долго и больно (про QT я знаю, но связываться с ним не хочу). Для этого отлично новый MAUI подойдет под Blazor накидать можно что-нибудь, чтобы кроссплатформено работало.

 

P.S. Сегодня клиент выложу, как добью 

 

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
Цитата

string mOSStringSimple = "Unknown Windwos Ver";

Просто девиз клиента xDDDD

 

https://gitlab.com/alexxst.st/corsairs-online-public

Чтобы проверить клиент, отключайте WPE, которую делал какой-то анальный клоун (я могу лучше, да).

Версия Release пока не исправлялась (только Debug)

 

сервера и клиент https://disk.yandex.ru/d/z0TtNWp3w-IRBw

 

  • Like 1

Share this post


Link to post
Share on other sites

Привет, @NoWinFate!

 

Предлагаю хотя бы немного уважать других разработчиков. Не у всех есть 18+ лет опыта разработки, но, тем не менее, они пытались хоть что-то сделать и поделиться этим с сообществом. Кроме того, в частности команда Corsairs Online где-то нашла исходники версии 1.3x (с которыми ты сейчас работаешь), сделала на их основе много интересных фичей с точки зрения геймплея и закрыла ряд известных уязвимостей, после чего они выложили это все в открытый доступ.

 

Ранее я упоминал, что качество исходного кода низкое. Тебя никто не заставляет заниматься его рефакторингом, поэтому видеть комментарии про "горящую жопу" или "анального клоуна", как минимум, странно.

 

ИМХО, с твоей стороны было бы более конструктивно давать комментарии относительно исходного кода, а не его авторов: почему такое-то решение плохое и как нужно сделать правильно. Лично мне было бы интересно почитать именно такие комментарии от опытного разработчика, а не в духе: "я могу лучше".

  • Like 3

Share this post


Link to post
Share on other sites
Цитата

Предлагаю хотя бы немного уважать других разработчиков. Не у всех есть 18+ лет опыта разработки, но, тем не менее, они пытались хоть что-то сделать и поделиться этим с сообществом. Кроме того, в частности команда Corsairs Online где-то нашла исходники версии 1.3x (с которыми ты сейчас работаешь), сделала на их основе много интересных фичей с точки зрения геймплея и закрыла ряд известных уязвимостей, после чего они выложили это все в открытый доступ.

Разве то что я сказал касается геймплея? Геймплей мне как раз очень нравится, замечательная игрушка, с интересной прокачкой. Именно благодаря этому я и решил привести сервер в нормальное состояние. Эта игрушка с душой.

 

Цитата

Ранее я упоминал, что качество исходного кода низкое. Тебя никто не заставляет заниматься его рефакторингом, поэтому видеть комментарии про "горящую жопу" или "анального клоуна", как минимум, странно.

С клоуном может и перегнул. Но. Желание это все отрефакторить никак не связано с тем, что испытываешь, когда это все рефакторишь. Совершенно не связанные друг с другом вещи. Комментарии про горящую жопу еще будут - она у всех горит, когда видишь определенные места.

 

Цитата

ИМХО, с твоей стороны было бы более конструктивно давать комментарии относительно исходного кода, а не его авторов: почему такое-то решение плохое и как нужно сделать правильно. Лично мне было бы интересно почитать именно такие комментарии от опытного разработчика, а не в духе: "я могу лучше".

Это только начало - приведение проекта в стадию, когда он может хотя бы по человечески запускаться, билдится и стартовать. Я собираюсь по всем сомнительным моментам отдельно пройтись подробными комментариями почему так не надо и как надо. Есть несколько тем:

  1. Сетевая часть
    1. Внутренняя логика парсинга пакетов, сетевых вызовов и т.д.
    2. Протокол
      1. Передача параметров, контроль границ, вывод содержимого, формат
      2. Пул команд, буферов, подсчет ссылок, reader's & writer's
      3. Поддержка нескольких протоколов, легаси и т.д.
    3. Шифрование
      1. Защита от повторной пересылки пакетов
      2. Защита от просмотра пакетов
      3. Защита от DDOS
    4. Сетевое общение серверов
      1. Варианты топологии
      2. Варианты технологий обмена
  2. Логирование
    1. Текстовые логи
    2. Игровые события
  3. База данных
    1. Оптимизация
    2. ORМ для работы
    3. Хранение ресурсов, шмоток, индексы, статистика, ключи и т.д.
  4. Работа со шмотками (транзакционность, как избавиться от дюпа)
  5. Работа с гильдиями и группами
  6. Чат
  7. Локализация в игре
  8. Магия 
  9. Карты, перемещение
  10. Работа с Lua

С какой начать?

 

P.S. Нужно чтобы кто-нибудь посмотрел клиент и добавил необходимые ресурсы, да и вообще запустил и посмотрел, насколько он хорошо работает. Потому что он глючит периодически (возможно в процессе рефакторинга могло что-то перестать инициализироваться, так как оно по ошибке инициализировалось)

  • Thanks 1

Share this post


Link to post
Share on other sites

Привет. А зачем писать новый гейт на шарпе? Он нативно будет работать медленнее плюсов. Если уж и решитесь переносить всё это дело и обновлять, не имеет ли больше смысла переписать на модернизированном с++?

  • Thanks 1

Share this post


Link to post
Share on other sites

 

1 час назад, champ сказал:

Привет. А зачем писать новый гейт на шарпе? Он нативно будет работать медленнее плюсов. Если уж и решитесь переносить всё это дело и обновлять, не имеет ли больше смысла переписать на модернизированном с++?

Привет. Тут ответ на целую статью тянет)

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

Share this post


Link to post
Share on other sites
Цитата

Привет. А зачем писать новый гейт на шарпе? Он нативно будет работать медленнее плюсов. Если уж и решитесь переносить всё это дело и обновлять, не имеет ли больше смысла переписать на модернизированном с++?

С одной стороны компиляторы для 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# реализовываются при высокой скорости работы.

  • Thanks 1

Share this post


Link to post
Share on other sites
21 минуту назад, NoWinFate сказал:

С одной стороны компиляторы для 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# реализовываются при высокой скорости работы.

свои небольшие пять копеек вставлю:
1. libdbc - по идеи 3rdparty library, которая должна быть и тут и там. При доработке сетевой части клиента - отдельно дорабатывать C# сервер.. Иметь C++ и C# разраба (если ты сам не делаешь и то и то) в штате в таком случае глупо, унификация кода экономит деньги и время.

2. Non boost asio - https://think-async.com/Asio/
3. Мы перенести libdbc на linux и уже давно оттестировали. Всего 35 #ifdef _WIN32 во всём libdbc (включая udp сокет), при этом 8-15 - это отключить дебильный WSA от WinAPI. Буквально фулл день с тестами и последующие мелкие фиксы в процессе работы.

Такой текст в защиту C# может написать только тот кто работал с dotnet долгое время и доверяет этой библиотеке. Тут осуждать считаю глупо, каждый Д**чет как он хочет ))

  • Thanks 1

Share this post


Link to post
Share on other sites

Ну и по поводу DDos, защищать его на серверной стороне нынче глупо, ИМХО.

Шаблонные TCP фильтры отобьют 90% атак различных стрессеров, остальные 10% нужно вкладывать в специфичный софт на стороне роутера и логику самого микросервиса коим наша пиратия и является (Gate, Group, Account, Game).

Чтобы банально каждое новое подключение не вызывать конструктор на фулл класс клиента и закрывать общий пул мьютексом, а при большом количестве подключений распределять нагрузку между 2 и более первыми точками входа (Gate) через какой-нибудь load-balancer.

 

Рекомендую посмотреть очень интересный ролик про микросервисную архитектуру World Of Tanks 

 

К слову мы в своё время переписали все сервера ( почти)) Гейм остался ) и запихнули их в докер и дальше в кубер с настройкой авто-скейлинга. Любой трафик просто распределиться между всем. Останется только 1, переписать гейм сервер чтобы не 1 карта - 1 гейм, а по координатам, с автозапуском если в эту локацию кто-нибудь заходит. И сервера готовы выдержать десятки тысяч клиентов. P.s на любом языке


Но давать + dotnet'у за отражение DDos атак, такое себе))

Edited by Kst
  • Thanks 1

Share this post


Link to post
Share on other sites
Цитата

1. libdbc - по идеи 3rdparty library, которая должна быть и тут и там. При доработке сетевой части клиента - отдельно дорабатывать C# сервер.. Иметь C++ и C# разраба (если ты сам не делаешь и то и то) в штате в таком случае глупо, унификация кода экономит деньги и время.

Ну такой себе аргумент. С++ разраб разберется с С# за 1-2 дня, а вот наоборот - это может быть проблема. 

 

Цитата

3. Мы перенести libdbc на linux и уже давно оттестировали. Всего 35 #ifdef _WIN32 во всём libdbc (включая udp сокет), при этом 8-15 - это отключить дебильный WSA от WinAPI. Буквально фулл день с тестами и последующие мелкие фиксы в процессе работы.

У каждого свое видение на то, как оно должно быть

 

Цитата

Такой текст в защиту C# может написать только тот кто работал с dotnet долгое время и доверяет этой библиотеке. Тут осуждать считаю глупо, каждый Д**чет как он хочет ))

Можно подставить любой язык - Java, Scala, Kotlin, golang и т.д. Вы с другими системами работали? Проблемы которые они успешно решаются в С++, в других системах просто не существуют. Хм.. доверяете ли вы платформе enterprise уровня на которой работают миллионы критичных сервисов? Ну да, доверяю. Доверяю JVM, доверяю golang, дотнету тоже доверяю. Почему нет то?)

 

Цитата

К слову мы в своё время переписали все сервера ( почти)) Гейм остался ) и запихнули их в докер и дальше в кубер с настройкой авто-скейлинга. Любой трафик просто распределиться между всем. Останется только 1, переписать гейм сервер чтобы не 1 карта - 1 гейм, а по координатам, с автозапуском если в эту локацию кто-нибудь заходит. И сервера готовы выдержать десятки тысяч клиентов. P.s на любом языке

Ну молодцы. С сообществом, полагаю не поделились?)

 

Цитата

 

Рекомендую посмотреть очень интересный ролик про микросервисную архитектуру World Of Tanks 

Мне он ничего не даст, возможно кому-то из разработчиков что-то подскажет. Обычная схема скейлинга, с микросервисами и т.д. Сам могу про такое долго рассказывать. WorldOfTank отлично скейлится, потому что там игровой процесс ограничен картами, которые существуют, пока идет игра. А вот когда мир непрерывный это совершенно иная задача. В рабочее время я занимаюсь системой подобной этой 

Вот тут почитать можно https://networking.docs.improbable.io/welcome/spatialos-concepts/offloaded-and-zoned-servers/

А в свободное решил заняться корсарами. В них есть что-то ламповое)

 

Цитата

Но давать + dotnet'у за отражение DDos атак, такое себе))

 Даже не знаю, как этот вывод получился. Выдержать DDOS = отразить DDOS. Это не ко мне, это к Вам.

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
Цитата

Ну такой себе аргумент. С++ разраб разберется с С# за 1-2 дня, а вот наоборот - это может быть проблема. 

C# прост, да согласен C++ войдет в шарп быстро, а поймет ли он функциональность dotnet'a так, чтобы поддерживать на равне с плюсами не могу даже догадываться, т.к не работал. Если вы считаете что он прост и плюсовик легко за 1-2 дня разберётся, спорит не буду, поверю на слово. Но для меня это было бы странно) Основная кодовая база C++, а сервер на C#. Надо понимать, что тогда нужно повторять остальной код предназначенный для обеих сторон с C++ на C#.  Мне кажется переводить сервер на C# из-за одного dotnet'a это серьёзный шаг) Имейте ввиду что за собой нужно тянуть odbc, libdbc, common. Последующая доработка может усложнить работу) А всё ещё усложнится в GameServer'e, где есть LUA, который может с сетью работать.

Мне кажется вы не видите множество других проблем, рекомендую хорошо подумать. Сделаете, поймёте что придётся много дорабатывать, закончится свободное время и бросите проект.

Имели мы опыт, когда приглашали C++ разраба специально на работу с серверами. Оказалось что человек хорошо знает Java и вообще раньше писал сервера на Java. Как только он меня не уговаривал переписать сервера на Java, аргументы типо быстрее, лучше, безопаснее да и вообще это круто отлетали быстро из-за простой бизнес модели о которой я говорил выше. Открывать вакансию в штате на должность, где у человека только 1 узконаправленная работа (сервер) - глупо, либо всё переписать на Java, либо придерживаться одной кодовой базы, чтобы доработка была проще. В соло весь проект не потащишь, а как начинаешь расширять команду появляется вопрос порога вхождения, требования и заработной платы. Брать C++ разраба с задачей идти разобраться с C#?

 

Цитата

Ну молодцы. С сообществом, полагаю не поделились?)

Думали над этим, но пока не собираемся.

 

Цитата

WorldOfTank отлично скейлится, потому что там игровой процесс ограничен картами, которые существуют, пока идет игра. А вот когда мир непрерывный это совершенно иная задача. В рабочее время я занимаюсь системой подобной этой 

Я бы не назвал основные города непрерывными, там нету караванов или других мероприятий. Только данжи, которые тоже нельзя назвать непрерывными. А даже если они и были, дамп слепка игрового мира и его загрузка с доп. логикой решит проблему непрерывности.

 

Edited by Kst
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...