Асинхронная сеть TCP будет лучшим вариантом для выделенного сервера, на котором одновременно могут играть до 32 игроков в C #?

Question

В настоящее время я планирую разработать выделенный сервер на C # для игры XNA, к которому одновременно смогут подключиться до 32 игроков.У меня был опыт работы в сети с System.Net, но мне раньше не приходилось иметь дело с довольно большим количеством игроков.

Я от всего сердца знаю, что создание и удаление потоков (особенно по одному для каждого игрока) не будет хорошей идеей, и я не уверен, стоит ли использовать ThreadPool из-за «ожидания в очереди»когда нет темы доступны "природа".Итак, я решил (в значительной степени, как мой единственный последний вариант) использовать Async для обработки большого количества клиентов.

Но я все еще не уверен, является ли это мудрым выбором, или я должен использовать что-то еще, чтобы удовлетворить свои требовательные потребности.

Прошу прощения, если этот вопрос звучит мрачно, но я довольно озадачен - помогите очень признателен!

Answer 1

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

Я, вероятно, недаже не беспокоиться о пуле потоков для 32 одновременно работающих пользователей.

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

Answer 2

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

Подход потоков является сильным, когда сервер ограничен ЦП.Он легко масштабируется до нескольких ядер или процессоров.

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

Answer 3

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