MulticastSocket для многопользовательской игры

Question

Я изучаю структуру для взаимодействия с сервером и клиентом в своей многопользовательской игре.

Я пришел к выводу, что UDP - лучший выбор из-за способа «снимать и забывать», который не блокирует приложение, если пакет потерян. Я также буду использовать TCP для отправки надежных пакетов, например, во время процедур входа в систему и обмена информацией, например, смены сервера, изменения карты, обновлений и т. Д. Он также будет запускать чат на базе IRC. (все команды на самом деле являются пользовательскими сообщениями в стиле IRC).

Мне было интересно, как лучше всего отправлять сообщения взаимодействия (перемещения, заклинания, объекты, действия и т. Д.) Между сервером и клиентами.

Прочитав некоторую документацию, я пришел в MulticastSocket.

Мой вопрос:

Лучше отправить непрерывный поток информации для всех клиентов, начиная поток для каждого игрока (как и я в TCP связи), где каждый DatagramSockets будет слушать очереди отправки каждого нового сообщение клиенту. Это будет означать, что все карты и все движения (предположительно, могут быть 50 игроков по всем картам) будут отправлены всем игрокам, и каждый пакет должен быть больше, чтобы содержать всю эту информацию. Или лучше использовать поток для каждой карты, активный, только если какой-либо игрок находится внутри этой конкретной карты, используя многоадресную связь, отправив сообщение только игрокам, которые находятся внутри этой карты, и прослушивает MulticastSocket.

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

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

Answer 1

Рассматривая свой сценарий выше, вам нужно решить, требуется ли вашему приложению абсолютно TCP-соединение, поскольку TCP-соединение требует одного потока на TCP-соединение, никаких исключений (кроме случаев использования nio).

Теперь целевой раздел UDP программы, у вас есть два основных варианта:

а) вы икру один поток для приема датаграмм пакетов для всех игроков.

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

ЗА:

• низкий ресурс использования
  
• Низкая программа (синхронизация) накладные расходы.

МИНУСЫ:

• Возможная сеть медленность (из-за массы пакетов, идущих к той же розетке)
• высокий шанс падения пакета (опять же из-за массы пакетов, идущих на то же гнездо)
• Последовательная обработка
• Отключить мероприятия грязно и сложно иметь дело с

b) Вы создаете один поток на игрока и слушаете на другом порту на одного игрока.

В этом случае все игроки получают свои собственные потоки обработчиков, которые могут обрабатывать данные напрямую или отправлять их в центральную очередь обработки. Таким образом, данные могут обрабатываться параллельно, что обеспечивает более быструю скорость обработки с более высоким использованием ресурсов. Синхронизация также потребует особого внимания, может потребоваться использование атоматики и блокировки чтения/записи для повторного входа. Запись обратно в сокет должна происходить, как правило, на другой «на нить игрока».

ПРОФИ:

• Parallel Processing
• Modular (есть весь код обработки на игрока в одном потоке, начните нить на плеере присоединиться)
• разъединители проще в обращении и не вызывают проблемы с другими игроками.
• Быстрый ответ сети, одновременный прием пакетов.

СВОД:

• Высокое потребление ресурсов (намного больше объектов)
• Высокая синхронизация накладных расходов
• Количество высокий поток (может быть больше, чем 2 ~ 4x нитей отношение игроков к)

В любом случае, используя TCP, вам необходимо need по крайней мере один поток на игрока. Вопрос в том, хотите ли вы использовать намного больше ресурсов для более плавного, более быстрого ответа с сервера.