What is the most appropriate way to write a multiplayer server?

Question

I am currently writing a server for a fast paced multiplayer game, which should be run in UDP (I read TCP was inappropriate due to the way it handles packet drops, in applications requiring timely delivered data, please correct me if TCP is more useful) The game is not mass multiplayer, and should be hosted primarily by the players themselves, probably on local dedicated servers. While I am pretty sure that the client needs to be in NIO, to avoid game lag from network problems, I do not know how to write the server yet. Here is a list of possibilities I considered:

Using separate thread for each player with a socket bound to each
Using one single socket to loop through every player
- Doing the same, but with NIO
using one socket to broadcast messages to all clients simultaneously
using one socket for receiving, and one for sending on a separate thread

Which of these is the most appropriate approach to handling time critical data with a relatively low number of clients? (no more than 16)

Can I ask about that downvote? I have attempted to put in as much research effort as possible, and I do not see where this has failed. — Kravaros
What exactly is your problem with the way TCP handles packet drops? NB multicast isn't the same thing as broadcast, and multicast sockets are used to receive multicasts: you don't need a multicast socket to send one. — user207421
@EJP No further packets are received until dropped packet arrives, which is counterproductive if data becomes obsolete in matter of milliseconds. Say a theoretical packet with ship position is dropped, you are better off receiving the next one and moving on instead of waiting for the old one. — Kravaros

Malt Malt · Accepted Answer · 2015-02-02T22:53:20

For 16 clients, unless your hardware sucks REALLY badly, or you do some outrageous processing, you'll be fine performance-wise either way you go. That means that you can write it any way it makes it simpler for you to write and maintain.

A few words about your options though:

Using separate thread for each player with a socket bound to each

This approach makes more sense for a low number of TCP sockets. If you're using UDP, you only have one socket, so there's no need for that. It is however useful to have a thread per client if your game requires some parallel processing per-client.

Using one single socket to loop through every player

This is probably the easiest option, unless your game requires really special. As I've said earlier, you should be fine performance-wise. So if it makes writing the code easier do it. Avoid premature optimizations.

using one socket for receiving, and one for sending on a separate thread

Unless you have a good reason for doing this, I'd avoid this idea. It might (needlessly) complicate things network-wise since the clients will be sending packets to port X, and getting replies from port Y. NAT will be a serious issue.

using one socket to broadcast messages to all clients simultaneously

First of all, that would only work in one direction - from the server to the clients. Second, that would only work inside a LAN since routers don't forward broadcast packets. If you're fine with both limitations and find yourself designing a system in which the server sends some packets to all players (at least to those in the same network), that might not be a bad idea. As far as performance goes, unless you're sending a large number of packets, you'll probably won't notice a difference between sending each player a separate copy, and sending a broadcast.

What is the most appropriate way to write a multiplayer server?

2 Answers