大学这学期，我们要以4人小组为单位编写联网游戏（用java），我自告奋勇要为自己的小组编写联网代码。
看了一下java联网的资料，好像有两种UDP联网方式。
https:/docs.oracle.comjavase1.5.0docsapijavanetDatagramSocket.html。.这是一个看起来很标准的UDP套接字，它可以向任何端口的任何IP地址发送数据包。
https:/docs.oracle.comjavase1.5.0docsapijavaniochannelsDatagramChannel.html。.这是某种通道系统，建立在udp套接字之上。我不完全清楚它提供了什么，除了只能连接到一个客户端的能力，这在这种情况下不是很有用。
这些是唯一的选择吗？4-8人的实时多人游戏用哪个好？
你没有先问第一个问题。第一个问题是：什么消息纪律最适合这个游戏？
对于少量的用户来说，UDP完全是得不偿失的麻烦。你得担心丢包，你得想办法把数据打包成小包，呀呀呀。
在4-8个玩家的规模上，你可以用web服务互联，然后到处发送soap消息。这样就可以解决所有的数据序列化问题。Heck，你甚至可以使用JMS。
至于你的文字问题，通道是nio的一部分。它们支持多路复用等待，而Socket不支持。如果你需要问 "这些端口上有我的数据包吗？"你需要通道。如果没有通道，你需要每个端口都有一个线程。当然，前提是你有不止一个端口在接收数据。
你的设计是否包括一个中央服务器，或者是客户端-客户端？这可能会影响到哪种技术适合通信。
你是否允许使用第三方库？如果允许，我总是发现 JGroups 是非常好的做可靠的多播。它很容易学习，而且可配置性很高。(性能上是否适合实时游戏我不清楚，但我过去用它推送过很多数据，从未出现过性能问题)。
游戏是实时的，我觉得webservices真的不适合吧？
有可能，但实时游戏无论使用什么基于互联网的技术都是有问题的。
如果你想支持地球另一端的玩家 你将不得不处理12秒或更多的网络延迟。
如果你想支持隔壁县的玩家，你就需要处理因网络拥堵等造成的数据包丢失而导致的偶尔 "冻结"。
如果你想支持大量的玩家，那么你就必须处理本地资源使用和网络带宽的扩展问题。
所以，虽然你对网络传输的选择很重要，但这只是问题的一部分。 更重要的可能是在设计应用层（游戏）协议时，尽量减少网络延迟和冻结数据包丢失对 "玩家体验 "的影响。 或者干脆把游戏限制在局域网上使用。