Difference between DatagramSocket and DatagramChannel

For this semester in university, we have to write networked games (in java) in teams of 4. I have volunteered to work on the networking code for my team.

Reading up on java networking, it seems there are two UDP methods of networking:

https://docs.oracle.com/javase/1.5.0/docs/api/java/net/DatagramSocket.html. This is a standard looking UDP socket, which can send packets to any IP address of any port.

https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/DatagramChannel.html. This is some sort of channel system, built on top of a udp socket. I'm not entirely sure what it 开发者_如何学JAVAoffers, except the ability to only connect to one client, which isn't very useful in this case.

Are these the only options? Which is the best to use for a realtime multiplayer game with 4-8 players?

You're not asking the first question first. The first question is: what messaging discipline is most appropriate for this game?

For a small number of users, UDP is entirely more trouble than it is worth. You've got to worry about lost packets, you've got to come up with some way to package data into small packets, yada, yada, yada.

At the 4-8 player scale, you could interconnect with web services and send soap message around. That takes care of all the data serialization for you. Heck, you could even use JMS.

As for your literal question, channels are part of nio. They support multiplexed-wait, which Sockets do not. If you need to ask 'is there a packet for me on any of these ports?' you want channels. Without them, you need a thread-per-port. Assuming, of course, that you have more than one port on which you are receiving data.

Does your design include a central server or is it client-client? That could affect which technique is appropriate for the comms.

Are you allowed to use third-party libraries? If so, I've always found JGroups to be very good for doing reliable multicasting. It's easy to learn and highly configurable. (Whether or not it's appropriate performance-wise for a real-time game I'm not sure, but I've used it in the past to push around a lot of data and never had a performance problem.)

The game is realtime, I don't think webservices would really be suitable for that would they?

Possibly, but realtime gaming is problematic no matter what internet-based technology use:

• If you want to support players on the other side of the planet, you will have to deal with network latencies of the order of 1/2 second or more.

• If you want to support players in the next county, you are going to need to deal with occasional "freezes" caused by packet losses resulting from network congestion, etc.

• If you want to support large numbers of players, then you have to deal with scaling, both of local resource usage and of network bandwidth.

So, while your choice of network transport is important, it is only one part of the problem. It is probably more important to design the application level (game) protocols to minimize the impact of network latencies and freezes / packet losses on the "player experience". Or just limit the game to use on a LAN.