Подходящий подход зависит от характера задач сервера, но создание нового потока для каждой пары игроков, вероятно, не лучшая идея. В основном давайте представим, что ваш сервер в основном выполняет:
Задачи, связанные с вводом / выводом. Другими словами, большую часть времени он ждет некоторого ввода-вывода
opertiton - сетевой ответ, запрос к базе данных или работа с диском. В
в этом случае вам, вероятно, понадобится асинхронная модель, когда все ваши
соединения обрабатываются в одном потоке. Было бы эффективно
потому что вы на самом деле не имеете ничего общего в своем собственном коде. Я полагаю
Скорее всего, у вас есть задачи, связанные с вводом / выводом. Например, вам просто нужно направлять сообщения между игроками и выталкивать \ извлекать некоторые данные из БД. Все перенаправленные сообщения будут иметь идентификатор игры (между слоями), поэтому вы никогда не пропустите ни одного из них, и они не будут пропущены. Взгляните на это видео , чтобы увидеть идеи и цели асинхронного подхода.
Задачи, связанные с процессором. Здесь сервер должен что-то вычислять, выполнять сложные алгоритмы или обрабатывать огромное количество данных. В этом случае вам, вероятно, понадобится многопоточность, но опять-таки поток на пару игроков может оказаться не самым подходящим подходом, потому что он плохо масштабируется и потребляет слишком много ресурсов. Если у вас есть тяжелые задачи процессора, попробуйте отправить их в очередь с набором фоновых рабочих. А затем отправлять сообщения асинхронно. Взгляните на реализацию производитель-потребитель с BlockingCollection .
У вас может быть комбинация из двух случаев, и, конечно, вы можете комбинировать подходы, описанные выше. Также см. Вопросы 1 , 2 , 3 . Попробуйте вернуться с конкретными вопросами. Надеюсь, это поможет.