Решил сделать свой асинхронный многопоточный сервер

Итак. Цель создать асинхронный многопоточный сервер для MMOFPS (онлайн шутер от первого лица) на C#.

Соответственно план такой:
1) Сервер должен быть асинхронный на сокетах
2) Выдерживать одновременно 2500-3500 подключений
3) Думаю использовать несколько потоков:
первый - слушать подключение новых клиентов или отключение существующих, периодически пинговать не отвалился ли клиент;
второй - принимать/отправять пакеты;
третий - серверная игровая логика. (может быть совместить со вторым?);
четвертый - работа с БД;
4) Масштабируемость сервера. Как и за счет чего осуществить?

Предполагаю не использовать Socket.BeginAccept, так как этот метод вроде как медленный, это так? Какие есть еще варианты?
Хотя на самом сайте майкрософта это как раз используется в примере https://msdn.microsoft.com/ru-... .110).aspx

Как избежать использования while(true){} ?

Прокомментируйте что я в плане написал правильно, а что нет.

В общем, помогайте)))

0

Сообщение от Sergio-X86 Прокомментируйте что я в плане написал правильно, а что нет. В общем, помогайте)))

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

0

Сообщение от Storm23 Помогаю - судя по вашим вопросам и планам, проект провальный, закрывайте.

Проект больше для учебной цели. Аналогично я начинал изучать C#, когда вообще ничего не понимал. Постепенно ставя себе задачи, и решая их, я достиг хорошего уровня в нем. Теперь решил сетевой частью заняться также ставя себе задачи. Поэтому прошу помочь мне в начинании.

0

Sergio-X86,
1) Определитесь какой сетевой протокол вы собираетесь использовать. Вы сходу взялись за TCP как я понимаю. Хотя обычно для таких задач используется UDP.
2) Разработайте протокол обмена. Он должен минимизировать траффик и в то же время передавать достаточно информации для однозначного позиционирования игрока.
3) Разработайте модель интерполирования. Как для движения игрока, так и для выстрелов. Для затравки почитайте например здесь https://habrahabr.ru/post/135306/ (первое что попалось в гугле, специально не отбирал)
4) Забудьте про 3500 игроков онлайн. Вообще. Навсегда. Это не реально в шутере. Настройтесь на 20-30 игроков максимум.
5) Забудьте пока про потоки. Потоки в последнюю очередь. Да и про БД тоже забудьте... Какое БД в шутере? БД годится максимум для того, что бы запоминать количество фрагов.
6) Ну а так, да, Socket.BeginAccept подходит

0

Класс SocketAsyncEventArgs
High Performance .NET Socket Server Using Async Winsock
C# SocketAsyncEventArgs High Performance Socket Code

0

Сообщение от Storm23 1) Определитесь какой сетевой протокол вы собираетесь использовать. Вы сходу взялись за TCP как я понимаю. Хотя обычно для таких задач используется UDP. 2) Разработайте протокол обмена. Он должен минимизировать траффик и в то же время передавать достаточно информации для однозначного позиционирования игрока. 3) Разработайте модель интерполирования. Как для движения игрока, так и для выстрелов. Для затравки почитайте например здесь https://habrahabr.ru/post/135306/ (первое что попалось в гугле, специально не отбирал) 4) Забудьте про 3500 игроков онлайн. Вообще. Навсегда. Это не реально в шутере. Настройтесь на 20-30 игроков максимум. 5) Забудьте пока про потоки. Потоки в последнюю очередь. Да и про БД тоже забудьте... Какое БД в шутере? БД годится максимум для того, что бы запоминать количество фрагов. 6) Ну а так, да, Socket.BeginAccept подходит

1) Да, мне нужен TCP чтобы гарантированно доставлять пакеты.
2) Протокол обмена я разработаю, есть реальный опыт работы с этим.
3) С этим тоже смогу разобраться, хорошая статья.
4) Шутер MMOFPS с "открытым" миром, так что нужно именно такое количество подключений. Ну и с прицелом на будущее использовать сервер для MMORPG. Я понимаю, что есть факторы, когда может в одном месте собраться и 7000 игроков, но уже второстепенная задача.
5) Ок. Разберусь сначала с коннектом/обменом информацией.

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

0

Не просто так делают залы по 18-20 человек, в современных MMOFPS используется и TCP, и UDP.
TCP для взаимодействия с UI, создание залов, чат.
UDP для передвижения по карте, стрельба.

Про 7000 можете забыть сразу, тем более на c#, необходимо будет поднять несколько серверов.
Про архитектуру MMORPG можете почитать на хабре, там есть ряд интересный статей, например от разработчиков Mail.Ru.

0

Сообщение от Sergio-X86 1) Да, мне нужен TCP чтобы гарантированно доставлять пакеты.

TCP для реализации игр в реальном времени НЕ подходит. Основная проблема в его гаранте доставки пакетов, что влечет за собой ужасную производительность. Довод: на основе UDP возможно реализовать эффективный TCP-аналог под конкретную задачу. Миксовать TCP и UDP - тоже плохая идея. И от системы предсказания действий наверное не избавиться.

Сообщение от Sergio-X86 2) Протокол обмена я разработаю, есть реальный опыт работы с этим.

Если был бы опыт в разработке многопользовательских сетевых игр, таких вопросов на форуме не было бы. Высокоуровневый протокол обмена сообщениями над UDP/TCP - основа производительности игры в реальном времени.
Пара неочевидных общих (будут варьироваться от задачи) вещей:
- Сообщение должно содержать размер, тип (опкод) и номер в очереди (или его аналог). Опкод - это целое число, уникальный идентификатор действия, которое было совершено.
- Сообщение должно влазить в размер пакета. Об игроке отправляется не все состояние, а только какое-то одно крошечное и определенное (текущая позиция например, три целых числа).
- Сообщение должно быть максимально маленького размера. Медленная и кривая стандартная двоичная сериализация здесь не подойдет. Вообще не подойдет что-угодно, связанное с рефлексией. Сообщение должно сериализоваться/десериализоваться очень быстро и при этом весить очень мало. Например есть такой тип base 128 varint, который меняет свой размер в зависимости от размера данных, которые в нем содержаться. Проще говоря в простом случае число 5 занимает 1 байт, а число 12345 - 2 байта. В сложном случае применяется например еще ZigZag кодирование - это когда -12345 тоже весит 2 байта.
- Текст по возможности лучше вообще не помещать в сообщения. В противном случае использовать ASCII или целые коды. Для чата лучше использовать отдельный чат-сервер и никак не валидировать на валидность сообщения.
- В сообщениях только информация о событиях и никакой графики, звука, текстов и подобной медиа.
- Сообщение, когда приходит, становится в очередь, а не сразу же в этот момент обрабатывается.
Пока думаю хватит. Этот список можно увеличивать до белого каления. Не говоря о способностях сервера выдерживать этот ддос.

Сообщение от Sergio-X86 Выдерживать одновременно 2500-3500 подключений

Это очень много. Логика сервера будет очень сложная - разработка игр основана на применении огромного числа хаков (далеко неочевидных) ради производительности.
Например, хорошая практика использовать компонентно-ориентированное программирование вместо ООП. Имеется ввиду никаких ссылок и наследования. Наследование - это операции над виртуальной таблицей типов, что плохо для производительности, особенно когда иерархия большая; с другой стороны композиция намного лучше наследования для реализации механик игры. Ссылки плохо влияют на производительность и эффективность размещения данных в памяти, лучше использовать указатели, а еще лучше использовать простое число ID и менеджер контента, который умеет искать объект по его ID. Довод: не будет в коде строк вида Player.Info.DetailInfo.SomeSpecificInfo.SomeValue.SomeValue2.SomeValue3...SomeValueN (пример утрирован, на самом деле все еще хуже получается, так как надо еще как минимум кастить к нужному типу), которые очень сильно просаживают производительность, учитывая что это еще и свойства, к которым долгое обращение.

Сообщение от Sergio-X86 Шутер MMOFPS с "открытым" миром, так что нужно именно такое количество подключений.

Сообщение от Sergio-X86 Думаю использовать несколько потоков

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

Сообщение от Sergio-X86 Предполагаю не использовать Socket.BeginAccept, так как этот метод вроде как медленный, это так? Какие есть еще варианты?

Откуда такая информация? При работе с удаленными ресурсами (сокеты, база данных, файлы...) лучше всегда использовать асинхронные вызовы и лучше те, которые представлены из коробки (так как они оптимизированы под эту задачу, чем городить свой медленный велосипед). Потому что это позволит процессору сделать какую-нибудь другую задачу, пока сокет ожидает входящую информацию.
Преждевременная оптимизация - дорога в ад. Нужно сперва написать прототип, который будет худо-бедно держать 5 пользователей и гонять 25 Гб траффика в час в виде JSON/XML, а потом уже пытаться его оптимизировать. К тому моменту будет уже список основных проблем и варианты их решения, основанные на интеграционных тестах, а не "построение несуществующего дома из несуществующих палок".

Сообщение от Sergio-X86 это подключение к серверу большого количества клиентов

Одновременное подключение? Лучше использовать очередь.

Сообщение от Sergio-X86 Как избежать использования while(true){} ?

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

Сообщение от Sergio-X86 Самая важная для меня задача, в которой я пока не компетентен

Это оценка собственных сил.

0

Спасибо всем за понятные развернутые ответы! Теперь более менее понятно в какую сторону двигаться. Если кто-нибудь допишет еще рекомендации буду только рад =)

0

напиши для начала крестики-нолики, чтоб была 100% стабильность всех действий игрока и очередность
считаешь себя крутым, хочется хардкора - крестики-нолики, но добавь drug&drop чтоб другой игрок мог видеть в реальном времени перемещение твоего крестика/нолика (без лагов по вине кода)
этих 2 задач более чем достаточно чтоб успокоится и либо стать экспертом, либо забить на сетевые игры в принципе

0

Сообщение от m0nax напиши для начала крестики-нолики, чтоб была 100% стабильность всех действий игрока и очередность считаешь себя крутым, хочется хардкора - крестики-нолики, но добавь drug&drop чтоб другой игрок мог видеть в реальном времени перемещение твоего крестика/нолика (без лагов по вине кода) этих 2 задач более чем достаточно чтоб успокоится и либо стать экспертом, либо забить на сетевые игры в принципе

На основе чужого сервера я недавно написал мультиплеерный tower defence. По сути сервер готовый, я лишь создал нужные мне структуры пакетов, прием/отправку данных, и серверную логику. Сервер ожидает пока игроки подключатся к лобби, потом для двоих кто нажал "поиск игры", создается собственно матч игрок против игрока (PVP), идет несколько волн крипов трех видов (2 по земле и 1 по воздуху), соответственно можно строить башни тоже трех видов, крипов и башни можно апгрейдить по 2 уровня вверх, при этом меняется их 3д моделька. На сервер рассчитывается передвижение крипов, проверяется расстояние от пушки до крипа которого можно атаковать, рассчитывается сколько снарядов вылетит при атаке, и какой снаряд добьет крипа (уничтожит на клиенте). Все изменения само собой сразу отображаются у обоих игроков. Сервер считает время раунда, считает количество начисленных очков за различные действия, количество отнимаемого у базы игрока HP. Извилистый путь тоже считается на сервере по ключевым точкам, прямым и кривым. Но дело в том, что сервер на C++, и он чужой. А мне нужен свой и на C#.
Еще, я в онлайн шутере в Стиме сделал полноценный режим с закладкой и разминированием бомбы как CS:GO, а также зомбимод + много доработок в готовых режимах деафматч и классическая контра. Поэтому с пакетами, и минимизацией траффика работать умею. Само собой с авторизацией клиента на сервере работал, в том числе с использованием PHP+MySQL. А вот в часть, где происходит подключение сокетов я не лез, так как все вполне неплохо работает.
Но мне свое надо, надо дальше расти, изучить и эту часть серверных технологий. И как-то C# больше по душе чем C++.

0