Оптимизированная структура сервера

Мне было интересно в последнее время о том, как сделать оптимизированную структуру сервера, и я пришел к выводу, что я сильно не владею знаниями по этому вопросу.

Я буду делать это с C, C ++ или C #, с предпочтением для последнего.

Контекст:

У меня есть сервер, который может одновременно работать с более чем 3K клиентами.

Этот сервер является игровым сервером, поэтому он получает только ключевые входы от клиентов, для обеспечения безопасности.

Поэтому сервер выполняет каждую операцию с данными пользователя и отправляет достаточно информации клиенту, чтобы отобразить персональный графический интерфейс. (Сервер, конечно, консольное приложение, не поймите меня неправильно.)

Подходы:

1- 1 Клиент = 1 Логическая тема

(Нить выполняет расчет игрока)

Плюсы: каждый клиент запускает свой собственный серверный код, сервер более реагирует на запрос конкретного клиента.

Минусы: у меня нет страхования, что конкретный клиент будет повторять свой код 14 раз, в то время как другой повторил бы его 10 (так что два игрока, бок о бок, если бы это было для операции движения, могли стать 4 квадраты вдали, что не должно быть так, поскольку каждый игрок должен двигаться с такой же скоростью)

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

2- 1 Клиент = 1 Запись, основной логический цикл

(поток получает ключи, нажатые его клиентом)

Плюсы: поскольку логика находится в одном цикле, проблем с десинхронизацией больше нет.

Минусы: Итерирование ВСЕЙ логики игры в одном цикле, скорее всего, вызовет серьезную задержку, если операции станут расширенными.

Кроме того, если многие клиенты должны догнать все текущие обрабатываемые данные (внезапный пик соединений), это также вызовет дополнительную задержку, частичным решением будет извлечение этих данных в потоке записи.

3- 1 Клиент = 1 Entry Thread, X Логические потоки, 1 Логический синхронизатор потоков

(Вводный поток получает ключи, регистрирует клиент в соответствующих потоках (один для каждого вида действий (перемещение, получение пользовательских данных, битва и т. д.)). Эти потоки предоставляют информацию, когда они могут, и Синхронизатор логической нити гарантирует, что задачи, которые должны быть «упорядочены» вовремя, упорядочены.)

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

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

Вопрос:

Как я уже говорил ранее, я, конечно, не знаю знаний о сетевых сетях, потоках и параллелизмах, чтобы эффективно упорядочить структуру моей программы. Поэтому я спрашиваю об этом здесь:

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

Дополнительная информация

Может быть, немного информации об этой идее поможет.

Моя цель состоит в том, чтобы создать сервер, который будет использоваться для запуска простой RPG, которая должна иметь синхронизацию движения на карте (перемещение в старой школе с квадрата на квадрат), поэтапное пошаговое сражение (например, Dragon Quest , Final Fantasy, Pokemon) и обмен пользовательскими данными (просмотр профиля X, просмотр того, сколько монстров он убил, его гильдия и т. Д.).

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

Таким образом, в основном проблема заключается в том, что «иметь максимум клиентов на минимально мощном сервере, поэтому оптимизируя его как можно больше».

4 голоса | спросил Morgan Fouque 9 FriEurope/Moscow2016-12-09T18:54:38+03:00Europe/Moscow12bEurope/MoscowFri, 09 Dec 2016 18:54:38 +0300 2016, 18:54:38

1 ответ


1

У вас нет нити для каждого клиента - вы будете стрелять в ногу, пробивая кеш процессора больше по мере подключения большего количества игроков. Если вы не хотите запускать несколько серверных процессов на машину, то в идеале вы хотите, чтобы количество потоков соответствовало количеству ядер, чтобы уменьшить переключение контекста. Один поток должен быть достаточным для чтения во входных пакетах для всех подключенных плееров и обновления структур данных для логического потока (потоков) для работы.

ответил justinian 27 Jam1000000amFri, 27 Jan 2017 00:53:00 +030017 2017, 00:53:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132