6
\$\begingroup\$

My initial research showed the most people prefer to use UDP protocol and build a control code on top of it for multiplayer games. It seems like a good design at first, but I am wondering if it is really the best in the long run.

For example, what happens if your game goes from 64 players to 500, 1000, 20 000

Is the UDP port going to overflow and start dropping incoming packets? Is the overhead that you wrote for UDP-reliability going to be less optimal when you start using more bandwith? (I.e. the server will spend significant cycles managing features that may already be present at the hardware and network level that are built into TCP)

I am considering re-writing a server that initially used UDP+reliablity protocol and splitting it into two cluster servers to handle different regions as well as introducing a load balancer in the middle. The UDP design is starting to look a little more complicated and having a large number of NPCs and state synchronization that may have to take place is making me reconsider UDP.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

The UDP port is only going to overflow if your program cannot handle the number of incoming packets at least as fast as they are being sent to your PC. While TCP will lead to your program itself needing to inspect less packets (since you only get reliably ordered packets and the rest are discarded by the networking level) I do not believe that I have ever heard of a programming, or networking interface, to choke because of the number of packets to handle.

As for the complexity of a reliable-UDP based solution this should be solved using abstraction. At the game programming level you should not be able to notice if reliable-UPD or TCP is used. You should even be able to switch between the two without having to change any game code. Basically what you want from your networking interface is just to know for sure that it will arrive (in order).

Why not take a look at the excellent networking library lidgren, its a .NET library but even if you're not using .NET you should be able to learn a lot from it.

In general, make sure you're using the right techniques for the right reasons. Using a technique because everybody else uses it can lead to disaster. You should always try to understand the reason for a technique, only then you can make an informed decision.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .