Сервер C++ - в тему или не в тему?

Question

Я работаю над игровым сервером, написанным на C++, и я пытаюсь решить, сколько потоков использовать и какие задачи для потоковой передачи. Основной скелет сервера состоит из ввода/вывода клавиатуры и вывода на консоль, приема входящих подключений, отправки исходящих подключений и выполнения «мелочей» игры.

То, что я хотел бы знать, - это то, что нужно дать отдельной теме. Должны ли каждый соединитель иметь свою собственную нить? Я знаю, что это переменная, это зависит от проекта или около того, но я бы хотел, чтобы он поддерживал довольно приличное количество игроков (где-то в сотнях, если это возможно).

Answer 1

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

Это отнюдь не реализация be-all-end-all, но этого должно быть достаточно, чтобы вы начали. Звучит как классный проект. Удачи!

Answer 2

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

Теоретически, сотни потоков, вероятно, хорошо подходят для современных машин. Как я помню, реализация NPTL для Linux была проверена десятками тысяч потоков. Если это самый простой способ для вас реализовать, это может быть правильный ответ.

Однако высокопроизводительные веб-серверы и подобные устройства обычно используют управляемые событиями модели. Рассмотрим библиотеку, такую ​​как libevent. Я уверен, что существуют библиотеки C++ для той же цели.

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

Answer 3

Хорошим решением может быть использование Thread pool.

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

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

---

Создать больше потоков, чем у вас есть ядра процессора не является продуктивным, и добавлением слишком нити уменьшают выступления из-за время, необходимое для переключения между потоками.
К примеру, для составления большого проекта (это не совсем то же самое, но это справедливо для обоих случаях), это часто рекомендуется использовать не больше нити, чем количество ядер CPU + 1.

Answer 4

Если вы настроите подключений и использовать их таким образом, чтобы поток блокировал ожидание на IO, тогда вы должны иметь возможность обслуживать все соединения и клавиатуру в одном потоке. Вы можете не захотеть выводить консоль на тот же поток, как я видел случаи (по крайней мере на Windows), где скорость записи на консоль на самом деле является узким местом (то есть, если консольное окно минимизировано, процесс выполняется значительно быстрее).

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