Разница между DatagramSocket и DatagramChannel

Question

В этом семестре в университете мы должны писать сетевые игры (на языке java) в командах из 4. Я вызвался поработать над сетевым кодом для моей команды.

Читая о сети Java, кажется, есть два метода UDP сети:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html Это стандартный сокет UDP, который может отправлять пакеты на любой IP-адрес любого порта.

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/DatagramChannel.html Это своего рода канальная система, построенная поверх сокета udp. Я не совсем уверен, что он предлагает, кроме возможности подключения только к одному клиенту, что не очень полезно в этом случае.

Это единственные варианты? Что лучше всего использовать для многопользовательской игры в реальном времени с 4-8 игроками?

Answer 1

Вы не задаете первый вопрос первым. Первый вопрос: какая дисциплина сообщений наиболее подходит для этой игры?

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

В масштабе 4-8 игроков вы можете подключиться к веб-сервисам и разослать мыльные сообщения. Это позаботится обо всей сериализации данных для вас. Черт, вы даже можете использовать JMS.

Что касается вашего буквального вопроса, каналы являются частью nio. Они поддерживают мультиплексное ожидание, а сокеты - нет. Если вам нужно спросить «есть ли пакет для меня на любом из этих портов?» Вы хотите каналы. Без них вам нужен поток на порт. Предполагая, конечно, что у вас есть более одного порта, на который вы получаете данные.

Answer 2

Игра в реальном времени, я не думаю, что веб-сервисы действительно подойдут для этого, не так ли?

Возможно, но игра в реальном времени проблематична независимо от того, какую технологию используют в Интернете:

• Если вы хотите поддержать игроков на другой стороне планеты, вам придется иметь дело с задержками в сети порядка 1/2 секунды или более.

• Если вы хотите поддержать игроков в следующем округе, вам придется иметь дело со случайными «зависаниями», вызванными потерями пакетов в результате перегрузки сети и т. Д.

• Если вы хотите поддерживать большое количество игроков, вам придется иметь дело с масштабированием, как использования локальных ресурсов, так и пропускной способности сети.

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

Answer 3

Ваш проект включает в себя центральный сервер или это клиент-клиент? Это может повлиять на то, какая техника подходит для связи.

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