This may seem like a broad question, but bear with me. I'm using Java to design a 2d multiplayer side scroller type game. I hear that UDP sockets are preferred for realtime/action games, so that's what I assume I will be using. My question is, what's a good design for the logic of a network system in Java? For example, should the server be multithreaded (one thread per client) or not? How do we do NAT hole-punching (or do we even need to)? That sort of thing.

Thanks in advance for any advice.

If you control the server and can give it a public IP address, then you don't need NAT hole punching.

There is only a single UDP socket bound to the incoming port, so multi-threading would be entirely useless. You could have one thread that keeps reading from the UDP socket, or you could just poll/drain the socket each time through your main loop; your choice.

If you control the server and can give it a public IP address, then you don't need NAT hole punching.

There is only a single UDP socket bound to the incoming port, so multi-threading would be entirely useless. You could have one thread that keeps reading from the UDP socket, or you could just poll/drain the socket each time through your main loop; your choice.

Thanks for the reply. What if I allow the players to host the games themselves? Do I make sure they know to use port forwarding, or is there something I can do to ensure that there is no NAT trouble?

Also, I kind of wanted to use the poll/drain method in my main loop, but I couldn't figure out how to read the socket until it's empty.

What if I allow the players to host the games themselves? Do I make sure they know to use port forwarding, or is there something I can do to ensure that there is no NAT trouble?

Port forwarding will work.

You can also use an existing STUN and TURN server, and implement those protocols in your client-host and client-clients. (There may be Java implementations already) Google seems to indicate ice4j: https://github.com/jitsi/ice4j#readme

Or, you can actually implement NAT punch-through yourself. This is conceptually easy, but as you start worrying about all kinds of maybe-kind-of-sort-of-working routers and firewalls, going from 80% to 95% is a hard uphill battle.

poll/drain method in my main loop, but I couldn't figure out how to read the socket until it's empty

In C there are two options:

1) Set the socket as nonblocking. Then read until you get the "would block" error -- that means it's empty.
2) Use select() with a 0 timeout. (Not NULL -- but a timeval with the value 0) passing in only the socket. If select() says nothing is ready, the socket is empty.

Option 1 is (slightly) more efficient than option 2.

I presume Java has similar affordances in the base socket interface. If not, you'll have to go with the "nio" library.
(Although a quick check of the docs seem to indicate that you have to associate a non-blocking "channel" with the socket for that to work, or specify a very short non-zero timeout in setSoTimeout() -- you might have to experiment with that.)
http://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocket.html