Это хороший многопоточный серверный дизайн?

Question

У меня есть сервер для клиент-серверной игры (в идеале это основа для небольшой MMO), и я пытаюсь определить наилучший способ организации всего. Вот краткий обзор того, что у меня есть:

[server start]
load/create game state
start game loop on new thread
start listening for udp packets on new thread
while not closing
  listen for new tcp connection
    create new tcp client
    start clients tcp listener on new thread
save game state
exit

[game loop]
  sleep n milliseconds // Should I sleep here or not?
  update game state
  send relevant udp packet updates to client
  every second
    remove timed out clients

[listen for udp]
  on receive, send to correct tcp client to process

[listen for tcp] (1 for each client)
  manage tcp packets

Является ли это справедливым проектом для управления состоянием игры, соединениями tcp и отправки / получения пакетов udp для обновлений состояния? Есть комментарии или проблемы?

Меня больше всего интересует лучший способ сделать игровой цикл. Я знаю, что у меня будут проблемы, если у меня будет большое количество клиентов, потому что я создаю новый поток для каждого нового клиента.

Answer 1

Похоже на хороший дизайн. На вашем месте я бы использовал существующую инфраструктуру nio, такую ​​как netty .

Просто Google java nio frameworks, и вы найдете несколько рамок с примерами и документацией.

Обновление

Спасибо, но я предпочитаю делать все самостоятельно. Это только для моего стороннего проекта, и большая часть его цели

imho, вы узнаете больше, используя существующую платформу, и сосредоточитесь на дизайне игры, а не будете делать все самостоятельно с самого начала.

В следующий раз вы узнаете, как разрабатывать игру, и это также облегчает разработку инфраструктуры ввода-вывода.

Answer 2

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

Вы ничего не сказали об объеме обмена сообщениями и количестве клиентов, но вы, возможно, захотите рассмотреть более естественный подход с точки зрения наличия одного потока, обрабатывающего сетевой ввод-вывод, и позволяющего ему жестко распределять входящие запросы. цикл и отображение АКТУАЛЬНОЙ работы (то есть запросов, которые вы не можете обработать в узком цикле) в пул потоков. IIRC, при такой настройке ограничивающим фактором будет максимальное количество TCP-соединений, которые вы можете одновременно ожидать ввода в одном потоке.

Для большего удовольствия сравните это с решением на языке с более легкими нитями, как в Erlang.

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

Существует определенная стоимость создания потока, в основном для каждого потока .

Answer 3

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