Стратегия для простого, но эффективного UDP-сервера для игр (и других задач)
Я пытаюсь реализовать свою идею простого, но довольно эффективного многопоточного сервера, работающего на UDP. Основная цель — для игровых (подобных) приложений, но было бы хорошо, если бы их можно было использовать и в других целях.
Я хочу использовать этот API / технологии и т. Д.
- STD :: Thread для многопоточности, поскольку он является частью стандарта C ++, он должен быть ориентирован на будущее, и, насколько я понимаю, он прост и хорошо работает с C ++.
- BSDSock (Linux) & WinSock2 (Windows). Я бы создал один абстрактный класс называется Socket и для каждой платформы (Linux — BSD, Windows — WinSock) создает производный класс, реализующий собственный API. Тогда я бы использовал API, предоставляемый базовым классом Socket, а не нативный / платформенный API. Это позволило бы мне использовать один код для всего модуля сервер / клиент, и если я хочу сменить платформу, мне нужно было бы просто переключить тип сокета и все.
Что касается стратегия связи сервера и клиента, я подумал о чем-то вроде этого:
У каждой программы есть два сокета — один, который прослушивает указанный порт, и другой, который используется для отправки данных на сервер / другие клиенты. Оба сокета работают в разных потоках, так что я могу одновременно считывать и отправлять данные (вроде), так что ожидание данных не ухудшит мою производительность. Будет один главный сервер, и другие клиенты будут подключаться напрямую к этому серверу. Клиенты будут отправлять только свои данные и получать данные непосредственно с сервера.
Теперь у меня есть немного вопрос:
- Разумно ли использовать STD :: Thread? Я слышал, что это хорошо в Linux, но не так хорошо в Windows. Будет ли PThreads намного лучше?
- Любые другие интересные идеи о создании одного кода для многих платформ (в основном Linux&Windows)? Или мой достаточно хорош?
- Какие-нибудь другие идеи или советы о стратегии работы сервера / клиента? Я написал несколько простых сетевых приложений, но для этого не нужна была хорошая стратегия, поэтому я не уверен, что это лучше, чем простые идеи.
- Как часто я должен отправлять данные с клиента на сервер (и с сервера на клиент)? Я не хочу затопить сеть и заставить сервер загружаться на 100%?
Кроме того: он должен хорошо работать с 2-4 игроками одновременно, в настоящее время я не планирую использовать его с большим количеством игроков.
Решение
Интуитивно понятно, что с точки зрения многопоточности Linux + Pthread была бы хорошей комбинацией. На этой комбинации работает огромное количество критически важных систем. Тем не менее, когда мы переходим к std :: thread, наличие зависимой от платформы природы приятно иметь. Конечно, если в диалекте Windows есть некоторые неприятные запахи, MS исправит их в будущем. НО, если бы я был вами, я непременно выберу комбинацию Linux + std :: thread. Выбор Linux поверх Windows — это отдельная тема, и здесь нет необходимости комментировать (с точки зрения развития сервера). std :: thread предоставляет вам хороший набор функций, но обладает мощью pthreads.
Что касается UDP, у вас есть как плюсы, так и минусы. Но я бы сказал, что если вы собираетесь открыть свой сервер для общественности, вам следует подумать и о сетевых брандмауэрах. Если вы можете решить проблемы, присущие транспортному уровню UDP (переупорядочение пакетов, восстановление потерянных пакетов), сервер UDP в большинстве случаев имеет небольшой вес.
Решать, как часто вам нужно отправлять сообщения, зависит от вашей игры. Я не могу это комментировать.
Кроме того, более серьезно обращайте внимание на дополнительную безопасность передачи данных. Рано или поздно ваш сервер будет взломан. Это просто факт времени.
Другие решения
detector